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

Postagem Anterior Próxima Postagem