Entenda as diferenas entre os tipos de merge no Git: Fast forward X Three way

Pr-requisitos

• Conceitos bsicos sobre Git

Como todo sistema de controle de verso (VCS) o Git dispe de recursos de criao e unio de branches. Para mesclar uma branch na outra, voc pode considerar merge ou rebase. Nesse artigo ser apresentado o que um merge, as estratgias envolvidas fast forward e three way e o que so conflitos e quando podem ocorrer.

O que um merge?

Merge uma opo muito comum e til em repositrios que possuem mais de uma branch alm da principal. Se necessrio fundir uma branch em outra, o merge pode ser uma opo.

Vale lembrar que uma branch no Git, um ponteiro para um commit, que ser a ltima verso de tal ramificao. Por exemplo, considere a sequncia, a qual inicialmente existe um commit inicial "first commit" na branch principal.

Em seguida, um novo commit "setup" realizado.

Aps isso, um contribuidor Joo cria uma nova branch "login" a partir do commit setup. Isso significa que neste momento ambas as branches apontam para a mesma verso do repositrio e que possuem o mesmo histrico, porm so dois ramos totalmente independentes. Qualquer nova verso em uma branch no afetar a outra e vice-versa. Observe o resultado de um novo commit "creating login feature" na branch "login".

Note que o rtulo da branch login passou a referenciar este ltimo commit, mas o rtulo da branch master ainda est apontando para o commit "setup". Ou seja, a branch login est a um commit frente em relao a branch master.

E se Joo desejar integrar os commits feitos na branch login na branch master, como fazer isso? Uma das opes, atravs de merge.

Merge fast forward

Joo decide integrar a branch login na branch master. Para isso ele retorna para a branch master com o comando abaixo:

git checkout master

Em seguida executa o comando:

git merge login

Note que nessa situao, a nica tarefa necessria que o Git precisou realizar foi mover o rtulo da branch master para o commit "creating login feature". Por isso, o nome dessa estratgia fast forward (em portugus avano rpido), pois simplesmente uma alterao de ponteiro.

Merge three way

Agora considere que antes de Joo integrar a branch login na branch master, uma outra contribuidora Maria promoveu um novo commit "creating user feature" na branch master.

Nesse caso, uma tentativa de merge no ter o mesmo resultado do exemplo anterior. Isso porque um commit foi realizado na branch master aps a criao da branch login. Ento no basta mover o ponteiro, h duas verses que precisam ser combinadas, que so o "creating user feature", commit que s existe na branch master e "creating login feature", commit que s existe na branch login. Veja a seguir o resultado de um merge nessa situao.

Observe que foi gerado um novo commit "Merge". Tal commit foi gerado de forma automtica pelo Git, que uniu as alteraes envolvidas nos dois ramos em uma nova verso do repositrio. Veja tambm que este novo commit possui dois pais e o histrico do repositrio no mais linear. A estrutura que representa o histrico linear ou bifurcado no Git pode ser definida como DAG (Directed Acyclic Graph ou Grafo Acclico Dirigido).

Conflitos

No exemplo anterior, ao realizar um merge com a estratgia three way, o Git conseguiu gerar um commit de merge automaticamente, pois as alteraes que precisavam ser combinadas no conflitavam. Entretanto, as duas branches poderiam ter alterado as mesmas linhas de um mesmo arquivo e nesse caso, o Git no pode determinar automaticamente o que est correto e necessrio decises humanas.

Os conflitos afetam apenas o contribuidor que conduz a mesclagem, o resto da equipe no tem conhecimento do conflito. O Git marcar o arquivo como conflitante e interromper o processo de fuso. responsabilidade desse contribuidor resolver o conflito.

Por exemplo, imagine que Joao alm de ter criado um novo recurso login, tenha alterado a linha 4 de um arquivo global do sistema. Maria tambm, alm de ter criado o novo recurso de usurios, alterou a linha 4 desse mesmo arquivo. Qual alterao deve prevalecer no commit de merge, a alterao de Maria? Ou a alterao de Joo? O Git no pode determinar isso de forma automtica, Joo que realizou a mesclagem que ir avaliar. Talvez a alterao de Joo seja melhor, como ele tambm pode considerar que a alterao de Maria faa mais sentido ou ainda, a alterao de ambos se complete.

Vale destacar que conflitos s surgem em mesclagens com a estratgia three way. Merge fast forward nunca ir gerar um conflito, pois no h histrico divergente a ser combinado. somente mudana de ponteiro.

No fast forward

Considere novamente a seguinte situao:

Neste caso, quando foi executado um merge da branch login em direo a branch master, o Git assumiu a estratgia fast forward e moveu o rtulo da branch master para o commit "creating login feature". Porm, possvel forar a utilizao de uma estratgia three way, fazendo que o Git crie um commit de merge. Para isso basta incluir a opo --no-ff (no fast forward) no comando merge:

git merge --no-ff login

Note que esta era uma situao tpica de fast forward, porm com a opo --no-ff o Git foi forado a gerar um commit de merge. Isso pode ser til, ocasionalmente, caso voc precise marcar pontos de mesclagem no histrico. Voc s deve ter em mente que um histrico com muitos commits de merge pode torn-lo confuso e de difcil compreenso. J em situaes que o merge seria pela estratgia three way, voc no pode forar um fast forward.

Merge sem checkout, possvel?

Nos exemplos vistos, antes de uma ao de merge, foi realizado um checkout na branch master. Em todos os casos o objetivo era um s, incluir os commits exclusivos da branch login na branch master, que era a branch corrente com o checkout.

Neste contexto, uma pergunta que pode surgir sobre a possibilidade de fazer uma mesclagem entre duas branches, que no so a branch corrente. A resposta para esta dvida pode ser respondida pelo texto a seguir, retirado diretamente da fonte:

"...Voc no pode mesclar uma branch B na branch A sem fazer o checkout de A primeiro, caso isso resulte em uma mesclagem sem fast forward (three way). Isso ocorre porque uma cpia de trabalho necessria para resolver quaisquer conflitos em potencial. No entanto, no caso de mesclagens fast forward, isso possvel , porque tais mesclagens nunca podem resultar em conflitos, por definio..."

Concluso

Como vimos, um merge pode ser executado de duas formas: por estratgia fast forward ou three way. A primeira, quando possvel, ser a melhor opo pois mantm um histrico linear e est livre de resoluo de conflitos, pois envolve somente alterao de referncia. J a segunda, alm de gerar um histrico bifurcado, com commits adicionais de mesclagem, ainda est suscetvel a resoluo de conflitos. Esses commits adicionais podem prejudicar a leitura do histrico. Ao menos que voc utilize um --no-ff, o Git ir definir a estratgia de merge de acordo o histrico das duas branches envolvidas na mesclagem.

Quer aprender mais sobre esta ferramenta essencial para desenvolvedores de software? Aprenda no mais novo curso de Git - Bsico ao avanado