Git Merge vs Rebase
Olá senhores e senhoras, hoje vou falar um pouco sobre as diferenças do git merge para o git rebase e onde considero melhor o uso de cada um destes comandos, mas já é importante mencionar que em ambos os casos, o objetivo é integrar código de duas branches diferentes.
Se tratando de versionamento de código, um fluxo de trabalho muito comum no desenvolvimento de softwares é o uso de feature branches, onde podemos, a partir do código da master, realizar novos desenvolvimentos, que ao final, devem ser integrados novamente à branch master para serem publicados.
Este post não tem o objetivo de se aprofundar nos fluxos de versionamento de código, mas se quiser conhecer um pouco mais sobre o assunto, recomendo a leitura deste post Ciclo de vida no desenvolvimento da Aberto.
Vamos imaginar um cenário onde criamos uma feature branch e após isso, novos commits são realizados na branch master:
Neste caso, os commits “e” e “f” da branch master foram realizados após a criação da feature branch.
Agora imaginemos que os commits “e” e “f” contenham alguma atualização importante para a feature branch, desta forma, sendo necessário trazer os novos commits da master para a feature branch.
É agora que vem a decisão. O que devo utilizar, git merge ou git rebase? Abaixo vou explicar como cada um deles funciona.
Git Rebase
Neste caso, o git irá remover temporariamente todos os commits(“c” e “d”) realizados na feature branch e irá aplicar os commits da master. Em seguida, os commits “c” e “d” são aplicados um a um. Caso exista algum conflito, dado que os commits da master foram trazidos, será necessário resolver o conflito e gerar um novo commit antes de prosseguir com o rebase (git rebase —continue).
Um ponto favorável ao rebase é que o gráfico de commits segue uma estrutura linear, como podemos ver na imagem abaixo.
Git Merge
No caso do merge, o git trará diretamente todos os commits da master para a feature branch e caso haja algum conflito, o mesmo deve ser resolvido no final do processo. Por fim, existindo conflito ou não, um commit de merge é adicionado, fechando a operação.
Diferente do rebase, a visualização do gráfico de commits após o merge fica um pouco mais confusa, conforme podemos ver na imagem abaixo.
Entendendo a complexidade de analisar commits não lineares
Para quem tem menos experiência analisando os logs de commit, pode não entender muito bem qual complexidade uma árvore não linear pode nos trazes, então trouxe um cenário onde isso fica mais claro.
Imaginemos que na nossa aplicação, temos uma função responsável por dizer se um número passado como parâmetro é impar ou não:
Como deve ter reparado, claro que este código não valida todos os números impares, mas para fins didáticos, vamos pensar neste método como uma feature que vai sendo incrementada aos poucos, portanto, a partir desta versão do código, criamos uma feature branch que inclui também o número 5 como um número impar:
Porém durante o desenvolvimento desta feature, a branch master recebeu um novo código que incluía também o número 3 como um número impar:
Agora vamos trazer o novo commit da branch master para a feature branch, a fim de termos o seguinte código final:
Ótimo, tendo este exemplo em vista, realizei este processo utilizando “rebase” em um teste e “merge” em outro, resultando nas seguintes visualizações:
Neste exemplo, podemos ver como fica fácil ler a história do desenvolvimento quando utilizamos rebase:
- Commit1: Numero é impar se for igual a 1
- Commit2: Número também é impar se for igual a 3
- Commit3: Número também é impar se for igual a 5
Já no caso do merge, a história fica um pouco mais confusa, visto que eu tenho um quarto commit unindo os 2 commits anteriores.
Portanto, rebase é sempre a melhor opção, certo?
Como dito anteriormente, o rebase nos trás o benefício de dar uma melhor visualização do histórico de commits, desta forma, eu considero favorável realizar rebase para trazer os commits da branch master para a feature branch e ao concluir o desenvolvimento, realizamos um merge para levar todo o desenvolvimento de volta para a branch master.
Porém nem tudo é bala de prata, e existem cenários onde o rebase não é bem vindo. Quando trabalhamos em grandes times ou em projetos open source, onde a comunicação é mais difícil, a recomendação é usar sempre merge. Isso se deve porque ao realizar um rebase, caso exista algum conflito no processo, temos que realizar commits intermediários, alterando a árvore original de commits e com isso, os demais membros do time, terão que sincronizar a nova árvore de commits. A forma mais comum de sincronizar a árvore de commits é deletando a branch localmente e dando um pull a partir do servidor remoto. Em pequenos times, a comunicação flui e os membros conseguem se organizar para realizar um rebase e todos atualizarem suas árvores de commit, mas imaginem em grandes times. Uma bagunça, não?
Espero ter ajudado a esclarecer sobre as diferenças do git merge e git rebase e caso tenham curtido o conteúdo, não esqueçam de bater palmas 👏👏👏.
