O escopo deste curso: conflitos dentro de um pull request aberto

O que você já sabe

"Git merging" mostrou o que é um conflito: os dois lados mudam as mesmas linhas de jeitos diferentes, e o Git se recusa a adivinhar. Também mostrou como ler e resolver um, editando os três marcadores (<<<<<<< HEAD, =======, >>>>>>> nome-da-branch) à mão até sumirem. "Pull requests" mostrou depois a camada que o GitHub põe em volta de um git merge comum: revisão, comentários, checagens obrigatórias e três estratégias no botão de merge. Nenhum dos dois cursos faz a pergunta para a qual este existe.

A pergunta que nenhum dos dois faz

O que acontece quando o conflito aparece numa branch que está num pull request aberto, já revisado e comentado, talvez já aprovado, e a main muda por baixo dela? Isso é diferente de um git merge sozinho no seu terminal, e diferente do caminho limpo que "Pull requests" percorreu. Tem ferramentas próprias: um editor de conflitos embutido na interface web do GitHub, um custo por consertar do jeito errado que só aparece quando há uma revisão em andamento, e uma diferença entre resolver como autor do PR e resolver revisando o trabalho de outra pessoa.

Um exemplo deste repositório

O db/seeds.rb deste repositório foi alterado por 48 commits na main, a maioria deles edições de catálogo e de cursos no mesmo arquivo compartilhado. É o tipo de arquivo que colide assim que duas pessoas, ou duas branches, mexem nele mais ou menos ao mesmo tempo. A contagem vem do git log deste repositório quando este curso foi revisado.

Por que isso importa mais com um PR no meio

Um conflito no seu terminal custa alguns minutos, e ninguém mais percebe. Um conflito dentro de um PR aberto tem plateia: alguém que já leu o diff, comentários presos a linhas específicas, talvez uma aprovação. Resolver sem cuidado pode desfazer em silêncio o retorno da revisão, e resolver bem pede ferramentas diferentes das de um merge solo.

Como este curso se organiza

Toda a mecânica de "Git merging" (os marcadores, git status, git diff, --ours/--theirs) é conhecimento que este curso supõe. Ela é citada pelo nome e não é ensinada de novo.

O que este curso cobre

1. O editor de conflitos web do GitHub: o que ele faz e o que não faz
2. Quando resolver localmente é a única opção, e como mandar o conserto de volta
3. O que um force-push faz com uma revisão em andamento
4. Revisando o pull request com conflito de outra pessoa
5. Mantendo PRs sem conflito: git rerere e branches pequenas
6. Juntando tudo: um conflito no db/seeds.rb deste repositório