DEV Community: Kauê Cavalcante

[Tutorial] Git + VS Code: como trabalhar com branches utilizando sua IDE

Kauê Cavalcante — Sat, 05 Mar 2022 22:47:29 +0000

Você faz parte da galera que não é muito chegada com o terminal? Ou simplesmente prefere ferramentas gráficas pois acha mais produtivo?

Se sua resposta for sim, então essa leitura é para você, pois hoje vamos aprender a utilizar as funcionalidades do git no Visual Studio Code. E mais: aprenderemos sobre branches.

Branches

Antes de começarmos, vamos responder o que são branches. Imagine que um branch seja uma linha do tempo dos seus commits, como na imagem a seguir:

Observe que no começo, temos um bloco com a palavra "Main" (Pode ser master em versões anteriores do git). Ela representa o nome dessa branch, que é a branch inicial dos projetos quando inicializamos o git em um projeto.

Agora, vamos supor que queremos adicionar uma nova funcionalidade no projeto, mas que por segurança, devemos fazer isso sem afetar o código principal? É para isso que usamos as branches. Elas servem para isolarmos nosso código criando ramificações a partir de um ponto, permitindo criamos códigos e testar diferentes cenários sem afetar o código da ramificação principal (main/master).

Operações git no Visual Studio Code

Vamos então criar um novo projeto e iniciar o versionamento com o git.

Ok! Se tentarmos o comando git status, veremos que ele nos informa em qual branch estamos.

Certo, mas chega de linha de comando e vamos abrir o VS Code. Aproveitemos e criemos também um arquivo de texto.

Como podemos ver, o git já reconheceu o arquivo e o classificou como untracked. Vamos aprender a mover este arquivo para nossa Staging Area. Basta clicar na aba Source Control (ou ctrl+shift+g) para ir para a parte de versionamento, e clicar no botão para fazer o stage (representando por um +). Veja a seguir:

Agora, vamos confirmar nossas alterações fazendo um commit. Primeiramente, vamos escrever uma mensagem para nosso commit e então clicar no botão para fazer o commit, como no GIF a seguir:

E pronto! Aprendemos a adicionar nossos arquivos na Staging Area e fazer commits usando somente o VSCode.

Criando uma nova branch

Ok, mas o assunto principal aqui são as branches, certo? Então vamos começar criando uma nova branch. No menu de ações da aba do git, podemos visualizar várias outras operações que podemos realizar no nosso repositório, porém iremos focar nas opções de 'Branch'.

Se passarmos o mouse em cima, veremos que o menu expande nos mostrando outras ações. Escolheremos a "Create branch" ou "Criar branch".

Agora, nosso esquema de branch ficará assim:

Perceba que além de criar a nova branch, o VS Code já nos moveu para a nova branch (na parte inferior esquerda do VS Code é possível ver o nome da branch atual). Agora, qualquer código produzido aqui não irá afetar a branch master.

O comando no terminal equivalente a esta operação seria:
git branch <nome da branch> seguido do comando git checkout <nome da branch>, ou simplesmente git checkout -b <nome da branch.

Assim como os commits precisam de uma mensagem, as branches precisam ser nomeadas.

Commit na nova branch

Vamos aproveitar que já estamos na nova branch e alterar o nosso arquivo, para então adicioná-lo na staging area e fazer o commit.

Com isso, nosso esquema se parecerá com isso:

Pronto. Agora, vamos voltar para a branch master e veremos o que acontece com o nosso arquivo. Observe:

O comando no terminal equivalente para esta operação é git checkout <nome da branch>.

Voltamos para a branch master e o nosso arquivo não está com as últimas alterações que fizemos agora a pouco. Isso acontece porque fizemos a alteração em outra branch e como dissemos anteriormente, as alterações feitas em uma branch não afetam as outras.

Merge entre branches

Vamos supor que aquela outra branch que criamos era uma branch com o propósito de implementarmos uma nova feature para o projeto ou uma correção de algum erro. Implementamos, testamos e concluímos que ela está pronta para ser adicionada na branch master, para fazer parte do projeto. Para isso, utilizamos a operação de merge.

Vamos fazer o merge da nossa branch criada com a branch merge:

Na linha de comando, primeiro precisaríamos fazer o git checkout para a branch que iríamos receber a outra branch com o merge (nesse caso, a master) e então usaríamos o comando git merge <nome da branch para mergear>.

Agora podemos ver que a alterações que tínhamos na outra branch, agora estão também na master.

Com isso, o nosso esquema ficará assim:

Conflitos de merge

Até aqui, mil maravilhas, certo? Mas nem tudo são apenas rosas, principalmente quando se trabalha em time. Vamos supor que você e algum colega alteraram o mesmo arquivo e fizeram o commit em branches diferentes. Como ficaria na hora do merge?

Nesse caso, teremos um conflito. Mas sem pânico, pois podemos resolvê-los. Vamos alterar o mesmo file.txt na master e na outra branch.

Beleza! Agora vamos voltar para a branch master e tentar fazer o merge para ver o que acontece:

E voalá! Temos um conflito. A parte boa disso é que podemos facilmente resolver estes conflitos já que o próprio VS Code nos diz onde está o conflito, o porquê de estar ocorrendo e de onde vem cada parte de código.

Ele também nos fornece algumas opções, como:

Aceitar a mudança atual
Aceitar a mudança da branch que está sendo mergeada
Aceitar ambas as mudanças
Comparar as mudanças

Vamos somente aceitar aqui ambas as mudanças, mas sinta-se livre para explorar as outras opções, que já são bem auto descritivas.

Prontinho! Conflitos resolvidos e commitados.

[Tutorial] Aprendendo sobre versionamento de código com Git

Kauê Cavalcante — Sun, 20 Feb 2022 14:29:10 +0000

O Git é uma ferramenta que não pode faltar no cinto de utilidades de um desenvolvedor, principalmente quando se produz código em grupo.

Segundo a própria Wikipédia: "Git é um sistema de controle de versões distribuído", ou seja, é ele quem irá auxiliar no gerenciamento das diferentes versões que um projeto pode ter e facilitar o time a integrar seus códigos sem o perigo de um sobrescrever o trabalho do outro.

Então se você quer aprender a utilizar esta poderosa ferramenta, continue descendo e aproveite a leitura!

Iniciando os conceitos básicos - `git init`

Vamos começar criando um novo diretório e iniciando o git no mesmo. Para iniciar o git no seu diretório, utilize o comando git init, como mostrado a seguir:

Perfeito! Agora com o diretório criado e o git inicializado, vamos entender alguns conceitos. Para isso, considere a imagem a seguir:

Essa é a representação do seu ambiente de desenvolvimento local. Nele você tem o seu diretório de trabalho (Working Directory), a Staging Area e o Local Repository. A Staging Area recebe este nome pois é justamente o local onde os arquivos irão ficar "se preparando" antes de irem para o Local Repository, que por sua vez, é o local de armazenamento onde o git gerencia as versões do seu código.

Verificando status - `git status`

Agora vamos abrir um editor de código e criar um novo arquivo.

Ótimo! Agora com nosso novo arquivo criado, vamos aprender nosso próximo comando git, o git status. Ele serve para nos dar um pequeno relatório sobre a situação dos arquivos no nosso diretório. Veja um exemplo:

Adicionando arquivos na Staging Area - `git add`

Como podemos ver na saída do comando anterior, temos um arquivo que não foi 'trackeado', ou seja, o git não está monitorando-o. Isso quer dizer que o git não irá guardar informações sobre as alterações desse arquivo. Para mudar isso, precisamos movê-lo para a Staging Area, onde ele ficará esperando para ser lançado numa versão do nosso projeto. Para fazer isso, utilizaremos o comando git add.

Podemos utilizar esse comando de duas formas: com o nome do(s) arquivo(s) específicos após o comando ou utilizando um '.' para sinalizar que queremos adicionar todos os arquivos com modificações. Veja a seguir:

Como você pode ver, o VS Code também detectou as alterações que fizemos. Agora, invés do 'U' ao lado do nosso arquivo, agora temos um 'A', sinalizando que o arquivo foi movido para a Staging Area.

Salvando nosso trabalho no Local Repository - `git commit`

O nosso arquivo na Staging Area está pronto para ser salvo no nosso Local Repository. Para isso, precisamos 'commitar' nosso código, isto é, salvar o estado dos arquivos da Staging Area no nosso Local Repository, gerando um commit que armazenará essas informações. Utilizaremos o comando git commit.

Se checarmos o status do git, veremos que a mensagem mudou:

Agora ele nos informa que temos arquivos a serem commitados e é exatamente o que faremos agora.

Todo commit precisa de uma mensagem. Geralmente ela deve ser uma pequena descrição do trabalho que foi commitado. Existem diversos padrões de commit e podemos falar deles em outro momento.

Como podemos ver também, ele nos retorna algumas informações a respeito do commit criado.

Perfeito, agora nosso trabalho está salvo no nosso Local Repository.

Removendo arquivos da Staging Area - `git restore`

Em algum momento, podemos querer remover alguma mudança que adicionamos na Staging Area. Para isso, podemos utilizar o comando git restore, que irá remover o arquivo da Staging Area. Para demonstrar isso, criaremos um novo arquivo.

Perfeito, agora temos um novo arquivo no nosso Working Directory. Vamos movê-lo para a Staging Area.

Note que o próprio git nos auxilia ao informar como podemos retirar algum arquivo da Staging Area. Precisaremos do comando git restore juntamente com a flag --staged.

Como podemos ver, após utilizar o comando, a mensagem exibida pelo git status é a mesma de quando criamos o arquivo, e caso verifiquemos o nosso arquivo no VS Code, ele continua o mesmo, a única diferença é que retornou ao status de untracked.

Lendo o histórico de commits - `git log`

Caso você queira verificar o histórico dos commits no seu projeto, você pode utilizar o comando git log. Ele exibirá uma lista com os commits, bem como algumas informações sobre cada um deles. Vamos lá testar:

Como você pode ver, temos informações como o nome do autor do commit, o hash (que é um código aleatório único para identificar aquele commit), a data de criação e sua mensagem.

No topo, podemos também ver a mensagem HEAD. Isso significa que esse commit foi o último a ser realizado, ou seja, está no topo (na cabeça) do histórico do nosso projeto.

Revertendo o último commit - `git reset`

Vamos supor que você commitou algum arquivo que não estivesse completo ou com alguns bugs e agora precisa desfazer seu último commit. Nessa situação, você pode utilizar o comando git reset. Para demonstrar o uso, vamos novamente adicionar o nosso novo arquivo na Staging Area e então fazer o commit:

Agora, se verificarmos o histórico, veremos que o novo commit está no topo:

Certo, agora é hora de desfazermos nosso último commit:

Como podemos ver, o nosso arquivo voltou ao seu estado de untracked, o que significa que o nosso commit foi desfeito. Para ter certeza, vamos checar o log:

Voalá! O nosso commit não está mais lá.

Renomeando commits - flag `--amend`

Vamos supor que na hora de nomear o seu commit você acabou digitando algo errado da qual não percebeu, como você faria para renomear seu último commit?

Felizmente, o git nos oferece essa opção também e de maneira bem simples. Tudo o que você precisará fazer é novamente utilizar o
git commit, mas dessa vez, com uma flag chamada --amend. Ela permitirá que você dê um novo nome para seu último commit. Vamos ver na prática.

Como podemos ver, o nosso último commit ainda está como antes. Vamos renomeá-lo:

Como podemos ver pelo git log, a mensagem do último commit foi editada com sucesso!

Removendo arquivos do git - `git rm`

Bom, mas e se quisermos remover de vez um arquivo do nosso sistema de versionamento? Simples: utilizamos o comano git rm.

Vamos remover o arquivo que commitamos:

Como podemos ver, na mensagem retornada pelo git status, o arquivo foi deletado. Para confirmar a remoção precisamos fazer o commit, assim salvando um novo state onde o arquivo é removido do versionamento. Como eu não desejo executar a remoção, vou somente reverter o processo utilizando o comando git restore --staged e em seguida o git restore para reverter as alterações e voltar ao estado inicial.

Salvando suas alterações sem commitar - `git stash`

O git nos oferece também a opção de salvarmos alterações no nosso código sem precisar fazer o commmit. O comando git stash nos permite salvar alterações de forma separada dos commits para utilizarmos em um momento futuro, caso desejemos.

Vamos começar modificando nosso arquivo já commitado:

Agora, com o arquivo alterado, vamos executar o stash:

Como podemos ver, inicialmente temos o git status nos informando que o arquivo havia sido alterado, em seguida, executamos o comando git stash push -m que nos permite associar uma mensagem ao nosso stash, assim como fazemos com os commits. Por fim, executamos novamente o git status e vemos que o diretório está limpo como se nada tivesse acontecido.

Vamos agora conferir a lista de stash para ter certeza de que nosso stash foi salvo. Utilizaremos o comando git stash list:

E aí está, o nosso stash salvo com sucesso. Agora vamos aplicar as alterações que salvamos nesse stash no nosso código novamente.

Prontinho, as alterações que havíamos salvo estão de volta no nosso diretório.

O git stash oferece outras opções como

git stash: para fazer o stash sem passar uma mensagem.
git stash show: para listar os arquivos modificados que foram salvos no último stash.
git stash pop: para remover em forma de pilha (do mais recente para o mais antigo).
git stash clear: para remover todos os stashs.

Etapas no desenvolvimento de software

Kauê Cavalcante — Sat, 05 Sep 2020 16:19:42 +0000

Juntamente com a ideia de se criar um novo software, vem a necessidade de se fazer um bom planejamento para garantir não só o seu sucesso do ponto de vista de visibilidade, mas também o seu sucesso no funcionamento.

Para isso, algumas etapas no desenvolvimento de software não inclui somente códigos e mais códigos, mas também bastante pesquisa e recebimento de feedbacks dos usuários, seja na fase de testes ou após o deploy da aplicação.

Hoje vou citar algumas das fases mais essenciais no desenvolvimento de um software.

Análise de sistema:

Inicialmente, é primordial haver uma análise do que se está prestes a ser criado, seja por meio de um texto descritivo ou usando algum outro sistema existente como referência.

Benchmarking:

O benchmarking é uma análise estratégica das melhores práticas usadas por empresas do mesmo setor que o seu. Não tenha medo de usar outros gigantes do seu setor como inspiração, afinal, se eles são tão grandes, é porque com certeza fizeram o melhor possível.

Entrevistas com o mercado e detecção de problemas:

Obter informações com o mercado é uma ótima maneira de reunir dados para análise complementar e evitar possíveis falhas futuras.

Criação de personas:

Personas são um perfil semificcional que representa o público ideal de seu produto. É diferente dos dados demográficos em uma análise de público-alvo, pois as personas são descritas de forma bem mais detalha para que o processo de adaptação do software aos usuários seja mais precisa.

Criação do mapa de empatia:

Criadas as personas, é hora de levantar alguns questionamentos para imaginar de forma mais profunda o contexto dos perfis das personas, como por exemplo: "O que o usuário pensa?", "O que usuário vê?"

Esquematização do Software:

Sitemap: listar as páginas de um site ou app e organizar seu conteúdo.

Fluxograma: diagrama que mostra as etapas do desenvolvimento.

Sketch, Figma, Adobe XD, etc: ferramentas focadas em estruturar a UI/UX do software.

Fase de prototipação:

Nessa fase, os desenvolvedores podem optar por desenvolver um protótipo de forma rápida e de baixo custo, para visualizar o produto com seus requisitos e funcionalidades básicas, ou uma simulação próxima do produto final.

Teste de usabilidade:

Com o protótipo pronto, é hora de realizar os primeiros testes, que podem ser feitos através de pesquisas qualitativas com o usuário, com distribuição do produto de forma privada e limitada (versões alfa e beta), monitorando suas interações.

Histórias de usuário:

Em metodologias ágeis, as histórias são essenciais para a definição de escopo. Uma história é uma forma de explicitar os requisitos e funcionalidades do sistema em questão. A partir da prototipação, o teste de usabilidade permite que a história seja formulada de forma precisa.

Validação do testes e TDD:

Feitos os primeiros testes e com as falhas relatadas, nada melhor do que automatizar a correção de possíveis bugs e tratamento de erros, para otimizar o código e deixar o funcionamento mais fluído. TDD (ou Test Driven Development), consiste em testar e refatorar em pequenos ciclos, onde você escreve o teste antes do código, faz o código passar e após isso, refatora.

Fase de deploy e QA:

Com os componentes prontos e devidamente integrados ao sistema ou importados de outro sistema, realiza-se o lançamento da aplicação.

A fase de QA (Quality Assurance ou Garantia de Qualidade) é, então, implementada, prevenindo problemas e erros que possam acontecer após o deploy.

Monitoramento de performance, manutenção, segurança, novas features:

O software, após desenvolvido e lançado, ainda precisa regularmente ter sua performance monitorada, otimização em momentos de downtime e desempenho em diferentes hardwares. Além disso, a implementação de novas funcionalidades é algo a se pensar conforme o app for ganhando notoriedade, a necessidade surgir e os pedidos dos usuários por novas funções forem chegando.

É preciso garantir ao usuário a melhor e mais segura infraestrutura possível de forma contínua.

DEV Community: Kauê Cavalcante

[Tutorial] Git + VS Code: como trabalhar com branches utilizando sua IDE

Branches

Operações git no Visual Studio Code

Criando uma nova branch

Commit na nova branch

Merge entre branches

Conflitos de merge

[Tutorial] Aprendendo sobre versionamento de código com Git

Iniciando os conceitos básicos - git init

Verificando status - git status

Adicionando arquivos na Staging Area - git add

Salvando nosso trabalho no Local Repository - git commit

Removendo arquivos da Staging Area - git restore

Lendo o histórico de commits - git log

Revertendo o último commit - git reset

Renomeando commits - flag --amend

Removendo arquivos do git - git rm

Salvando suas alterações sem commitar - git stash