Como o Git cherry-pick e revert usam merge de 3 vias

Artigo original ↗ Discussão no Hacker News ↗

Os comandos cherry-pick e revert do Git são revelados como usando merges completos de 3 vias por baixo dos panos, o que explica por que muitas vezes eles se comportam de forma mais robusta do que a aplicação simples de patches. A partir daí, desenvolvedores debatem fluxos de trabalho e modelos mentais mais amplos do Git — especialmente merge vs. rebase, merges squash e desenvolvimento baseado no trunk — e como essas escolhas afetam a clareza do histórico, a frequência de conflitos e a produtividade da equipe. Muitos argumentam que o poder do Git justifica sua complexidade, mas enfatizam boas ferramentas, tutoriais e compreensão da estrutura de grafo subjacente do Git como chaves para evitar erros dolorosos.

Reação geral ao artigo

  • Muitos acharam a explicação de cherry-pick/revert usando merge de 3 vias esclarecedora; ela confirmou a intuição de que essas operações são “mais espertas do que um patch simples”.
  • Alguns ficaram surpresos ao saber que cherry-pick é implementado como um merge de 3 vias e que rebase é essencialmente uma sequência de cherry-picks.
  • Alguns apontaram pequenos detalhes, por exemplo, linkar para a branch master em vez de hashes de commits específicos para maior estabilidade a longo prazo.

Complexidade do Git, modelos mentais e UX

  • Vários comentários reclamam que o Git parece excessivamente complexo, especialmente ao corrigir histórico ou resolver erros de outras pessoas.
  • Outros argumentam que o poder/complexidade é necessário para equipes grandes e distribuídas, e que os problemas muitas vezes vêm de modelos mentais fracos.
  • Diversos enfatizam entender o modelo subjacente de grafo/snapshot do Git (commits como árvores completas, não patches) em vez de memorizar comandos.
  • UIs visuais e tutoriais bons (visões de grafo, ferramentas de conflito, sites como learngitbranching e docs no estilo “plumber’s guide”) são vistos como muito úteis.

Merge vs rebase vs squash: filosofias concorrentes

  • Há uma forte divisão entre os campos do “sempre merge” e do “rebase para histórico linear”.
  • Defensores de merge:
    • Preferem commits de merge explícitos, nenhum rebasing (ou rebasing raro) e frequentemente fazem squash de branches de feature em um único commit.
    • Argumentam que merges são conceitualmente mais simples, os conflitos são mais fáceis e fazer rebase em branches compartilhadas é perigoso.
  • Defensores de rebase:
    • Fazem rebase de branches locais/de tópico com frequência para manter o histórico linear e fácil de bisectar; usam rebase interativo para criar commits limpos e atômicos.
    • Vêem merge squash como algo que esconde desenvolvimento bagunçado e reduz o valor do histórico.
  • Alguns observam trade-offs práticos: branches de longa duração tornam rebases dolorosos (conflitos repetidos), enquanto históricos bagunçados de feature branches tornam merges sem squash ruidosos.

Fluxos de trabalho e práticas de equipe

  • Desenvolvimento baseado no trunk, com branches de curta duração e feature flags, é elogiado, especialmente para SaaS.
  • Outros usam subconjuntos muito mínimos de comandos e evitam recursos avançados para não se complicar.
  • Há discordância sobre quanta estrutura times pequenos realmente precisam versus processo ficando excessivamente complicado por “segurança”.

Notas técnicas sobre merge de 3 vias e conflitos

  • Vários destacam merge.conflictStyle=diff3 / zdiff3 e ferramentas visuais de 3 vias como grandes auxiliares na resolução de conflitos.
  • A discussão esclarece que o merge de 3 vias precede o Git e não é associativo, o que pode gerar comportamentos surpreendentes; alguns especulam sobre esquemas de merge mais ricos (por exemplo, contextos “de quatro vias”).
  • Cherry-pick e rebase são enquadrados como formas de aplicar diffs usando merge de 3 vias, o que pode funcionar onde patches ingênuos no estilo git apply falhariam.