Resolvendo conflitos no Git

Conflitos de merge são comuns e muitas vezes o desenvolvedor não entende o que são. Este é um problema extremamente comum e, infelizmente, não se conhece uma boa maneira de evitá-lo.

Como surgem conflitos no merge

Vamos chamar seus desenvolvedores de Alice e Bob. Alice fez os commits 1-5, e Bob fez os commits A e X. Aqui está uma história plausível:

1. Bob faz o commit A.

2. Alice faz os commits 1-4, e faz push deles para o repositório central (remoto).

3. Bob tenta fazer push do A, mas não consegue, pois seu repositório está desatualizado.

   $ git push
    ! [rejected]        master -> master (non-fast-forward)
   

4. Então o Bob faz o que você disse para ele fazer: ele roda o pull primeiro. Entretanto, dá um conflito no merge porque o commit A e os commits 1-4 mexem no mesmo código.

   $ git pull
   Auto-merging file.txt
   CONFLICT (content): Merge conflict in file.txt
   Automatic merge failed; fix conflicts and then commit the result.
   

5. Bob vê as alterações das outras pessoas em sua cópia de trabalho, e não entende porque elas estão ali.

   $ git status
       both modified:   file.txt
   

6. Ele pensa que o Git está fazendo algo errado, quando na verdade, o Git está pedindo a ele para resolver um conflito no merge. Ele tenta pegar uma cópia nova do arquivo, mas recebe o erro:

   $ git checkout HEAD file.txt  
   error: path 'file.txt' is unmerged
   

7. Como isso não funcionou, ele tenta com -f:

   $ git checkout -f HEAD file.txt
   warning: path 'file.txt' is unmerged
   

8. Sucesso! Então ele faz o commit e push das suas alterações.

   $ git commit
   $ git push
   

Onde a coisa fica complicada

Existem muitas ferramentas git por aí. Sério. O Visual Studio e o Xcode vêm com integração com o Git, existem várias outras GUIs e até vários clientes de linha de comando. As pessoas também são desleixadas com a maneira que descrevem como usam o Git, e a maioria dos desenvolvedores não se sentem confortáveis o suficiente com o modo como o Git funciona além do "pull commit push"

Alguns pontos relevantes a cerca disso:

• A maioria dos desenvolvedores não sabem realmente como usar o Versionador de código, exceto por alguns comandos realmente simples (commit, push).

• Quando o Versionador de código não se comporta da maneira que os desenvolvedores esperam, eles recorrem a táticas como copiar e colar algum comando que não entendem muito bem para "consertar as coisas", adicionando o parâmetro -f ou simplesmente apagam o repositório e começam novamente com um nova cópia.

• Em equipes de desenvolvimento, muitas vezes apenas os desenvolvedores líderes realmente sabem o que está acontecendo no repositório.

Então na verdade isso é um problema de capacitação.

Acho que a principal lição aqui é que o Bob precisa aprender é que o git pull é só um git fetch e git merge, e que você pode obter conflitos de merge e precisa agir de maneira muito consciente e proposital ao resolver os merges. Isso se aplica mesmo quando não há conflitos relatados... mas não vamos quebrar a cabeça com isso por enquanto! 

A outra lição importante aqui é que os principais desenvolvedores precisam reservar um tempo para garantir que todos na equipe possam usar o controle de versão corretamente e entendam como pull, push, branch e merge estão todos relacionados. Esta é uma ótima oportunidade para um "Talk" (mini palestra com comes e bebes) e falar sobre como o Git funciona.

Referencia: https://stackoverflow.com/questions/28079546/how-can-i-tell-what-happened-in-a-git-commit-with-two-parents-that-did-not-merge