Recentemente, atendendo a inúmeros pedidos ao longo dos anos, eu escrevi um tutorial de Git e GitHub para iniciantes no assunto, já que é um requisito onipresente nas vagas de desenvolvimento tem alguns anos. Na primeira parte do tutorial, que você confere aqui, eu falei o que é, para que serve, preparamos o ambiente, criamos e clonamos o repositório e fizemos as primeiras alterações, stagings e commit, terminando com um push para a main. Podemos dizer que passamos por um ciclo completo. Não um ciclo profissional, mas completo.

Por que falo isso? Porque via de regra, em projetos profissionais, como aqueles que você vai vir a trabalhar em empresas, você não vai trabalhar na branch main e muito menos ficar commitando e fazendo push nela, não é assim que funciona já que a main é um espelho de produção e muitas vezes o commit nela dispara fluxos de CI/CD que colocam a nova versão online.

Então nessa lição nós vamos entrar mais a fundo em algumas práticas mais profissionais com Git e GitHub. Se preferir, você pode acompanhar pelo vídeo abaixo, tem o mesmo conteúdo.

Vamos lá!

#1 – Navegando pelos Commits

Uma vez que você tenha “pushado” seu primeiro commit, vale dar uma olhada na página do repositório no GitHub para ver o que houve.

Você vai notar na faixa cinza logo acima dos arquivos a mensagem do commit mais recente (“second commit”), o identificador do mesmo, há quanto tempo ele foi feito e a quantidade total de commits no projeto. Se você clicar na mensagem do commit, você vai para página com detalhes do mesmo, onde poderá ver os arquivos adicionados e alterados, com as adições em verde, remoções em vermelho e demais alterações em amarelo.

Agora se você clicar no número de commits, verá algo ainda mais interessante: a lista completa de commits do projeto.

Com essa lista você consegue ver as mensagens de commit, alterações feitas em cada momento do tempo, ver como estava o repositório naquele instante (Browse Repository) ou até mesmo voltar no tempo. Sim, se você precisar, por qualquer motivo, recuperar uma versão anterior do projeto, você pode usar o comando abaixo para fazê-lo, bastando ter o id do commit que você pode pegar na direita da listagem de commits.

git checkout <id_commit>

Esse comando vai restaurar na pasta do projeto a versão em específico que você forneceu, permitindo que você use ele, faça novas modificações a partir dela e muito mais. Apenas atenção ao fato de que você está trabalhando no passado, então se for fazer alterações, não é tão simples assim de juntar elas com a versão principal depois, o mais recomendado nesse caso é criar novas branches, o que vamos ver a seguir.

#2 – Branching e Merging

Uma das vantagens de se trabalhar com um ferramenta de controle de versão é a possibilidade de se duas ou mais pessoas trabalharem em paralelo no mesmo projeto. No entanto, quando Alice está trabalhando em uma feature A e Bob na feature B, as alterações de um podem acabar afetando o trabalho do outro, certo? Claro, com cada um trabalhando na sua máquina, este problema só vai aparecer quando forem juntar as alterações. Quando isso acontecer, eles precisam fazer o que chamamos de merge (fusão), mas já vamos chegar lá.

O problema aqui é que tanto Alice quanto Bob não deveriam estar trabalhando diretamente no espelho de produção, ou seja, na versão main. Isso porque enquanto eles tocam novas funcionalidades, pode ser que surja uma demanda urgente a ser resolvida na versão de produção, o que vai exigir um novo código e um novo deploy. Se eles ficarem mexendo na versão de produção, ela seria comprometida e possivelmente desestabilizada, algo que jamais pode acontecer. Neste caso, sempre que Alice e Bob forem incluir novas funcionalidades, eles devem primeiro criar uma nova branch da main.

Uma branch (ou ramificação) é uma cópia do projeto com vida própria, como se fosse uma nova linha do tempo a partir de um ponto qualquer, geralmente o mais recente. Cada desenvolvedor pode criar a sua própria branch e trabalhar nela independente dos demais, inclusive fazendo commits nesta branch. Mais pra frente, quando o seu trabalho tiver terminado, ele pode fazer o merge dela com outra existente, como a main por exemplo, a fim de juntar no histórico principal. A imagem abaixo ilustra isso.

Neste exemplo, temos a branch master (antigo nome da main) em verde, simbolizando a versão principal do projeto. Em determinado momento o dev azul criou uma branch a partir do primeiro commit da main (bolinha verde) para trabalhar em novos recursos, juntando seu trabalho à branch principal três commits mais à frente (bolinha verde de número 4). Note que ele próprio teve três commits também, sendo o primeiro de criação da branch e os demais de alterações que ele fez, mas tudo na sua branch alternativa. Durante esse período, um dev laranja também abriu outra branch no commit 3 da main, que viria a se fundir com ela novamente mais recentemente, ao final do grafo.

Via de regra, o Git é naturalmente inteligente para fazer o merge das alterações do dev azul à main e do dev laranja à main. Logo, o merge das alterações costuma ser automático e todo o histórico é mantido. Isso claro, desde que não existam conflitos. Quando alterações do dev azul e do laranja entram em conflito, já que o laranja só começou a trabalhar antes do azul mergear as alterações dele, é necessário fazer uma análise, de preferência com alguma ferramenta visual, e entender o código que fica, o código que sai ou fazer um meio-termo. Isso é o merge, que entraremos em detalhes mais à frente. Por ora, esse entendimento inicial já é o suficiente e vamos aprender agora como criar branches.

#3 – Usando branches

O primeiro passo para começarmos a usar branches, depois de entender o conceito (explicado anteriormente), é descobrir quais branches existem atualmente no projeto, o que pode ser feito com o comando abaixo.

git branch

Isso vai listar os nomes delas, um abaixo do outro, sendo que é esperado que liste somente “main” neste momento. Um asterisco ao lado do nome indica que ela é a branch atualmente selecionada na sua máquina.

Agora imagine que você vai iniciar o desenvolvimento de uma nova funcionalidade. O primeiro passo é criar uma nova branch, certo? Você faz isso com o comando abaixo.

git branch nome_branch
 
//ou
 
git switch -c nome_branch
 
//ou
 
git checkout -b nome_branch

Qualquer um dos três comandos cria uma nova linha do tempo a partir do último commit da branch atualmente selecionado, e você pode confirmar isso com o comando “git branch”. No entanto, o primeiro comando apenas cria mas não a disponibiliza para trabalharmos. Para realmente começarmos a fazer alterações independentes da main, em nossa nova branch, precisamos selecionar ela, com um dos comandos abaixo.

git switch nome_branch
 
//ou
 
git checkout nome_branch

Agora se você fizer novamente o comando para listar branches, vai ver as mesmas branches lá, mas a sinalização de branch selecionada vai estar ao lado da nova que você criou. A partir de então, todas alterações que você fizer e commitar, estarão pertencendo única e exclusivamente à branch nova e não à main. Experimente fazer alterações e rodar novamente os comandos para salvá-las.

//faça alterações no projeto
git add .
git commit -m "explique alterações"
 
//ou os dois juntos com:
 
git commit -am "explique alterações"

Agora se você rodar o comando para ver os commits (abaixo), você verá que na sua nova branch (a minha se chama nova_pagina) tem um commit a mais.

 git log --oneline

git push --set-upstream origin <nome_branch>

git pull

git checkout main

//ou

git switch main

git merge <nome_branch>

git branch -d nome_branch

git config --global core.editor "code --wait"