Pensamos em commits do Git como diffs, snapshots e/ou históricos?

Modelos mentais: diffs, snapshots, históricos

• Muitos argumentam que commits são conceitualmente snapshots: um estado completo do repositório (tree) mais ponteiros para os pais, formando um DAG.
• Outros pensam instintivamente em commits como diffs/mudanças, porque eles criam “uma mudança” e ferramentas como git show, rebase, cherry-pick e revisões apresentam ou operam sobre diffs.
• “Histórico” é descrito como um commit mais todos os seus ancestrais (o que outros sistemas chamam de branch); alguns acham a distinção “histórico vs snapshot” confusa, já que cada snapshot se liga a esse histórico.
• Vários sugerem uma visão dupla (ou tripla): commits como snapshots, diffs e partes do histórico, com o “modelo certo” dependendo da operação.

Implementação vs abstração

• Há forte discordância sobre se “como o Git implementa isso” é um bom modelo de ensino.
• Um lado: commits-como-snapshots e o armazenamento de objetos (trees, blobs, endereçamento por conteúdo) são essenciais para desenvolvedores evitarem confusão em merges/rebases.
• O outro lado: a implementação (incluindo packfiles e compressão delta) é uma otimização e muitas vezes distrai iniciantes; a interface é sobre estados ao longo do tempo, com diffs derivados sob demanda.
• Um debate mais amplo usa uma analogia do pedal do acelerador: alguns enfatizam abstrações intuitivas, enquanto outros argumentam que abstrações vazando e necessidades de depuração tornam útil conhecer a implementação real.

Rebases, merges e o DAG

• Rebase é descrito como “resetar para uma nova base + cherry-pick de cada commit”, conceitualmente aplicando diffs por commit via merges de 3 vias.
• Vários observam que pensar puramente em diffs durante rebases causa confusão, especialmente quando a ordem dos commits muda ou quando há merge commits envolvidos.
• Merge commits podem introduzir mudanças novas e arbitrárias (incluindo da resolução de conflitos) e podem quebrar parent working; “histórico de merge = histórico seguro” é apontado como inseguro.

Armazenamento e desempenho

• Esclarece-se que o modelo lógico do Git é snapshots; o armazenamento físico pode usar compressão delta (“deltas”) dentro de packfiles, mas isso é invisível para os usuários.
• As explicações detalham árvores copy-on-write, desduplicação pesada via hashes e por que isso continua rápido e eficiente em espaço mesmo com muitos commits.
• Alguns argumentam que chamar commits de “diffs” por causa dos deltas dos packfiles é enganoso; outros acham aceitável se “diff” for definido de forma ampla.

Ensino, usabilidade e outras ferramentas

• Vários dizem que o “modelo mental de diff” é a principal fonte de confusão no dia a dia e defendem ensinar snapshots primeiro, sempre.
• Outros relatam sucesso de longo prazo pensando em diffs, afirmando que raramente precisam do modelo de snapshot explicitamente.
• A interface e a terminologia do Git são amplamente criticadas por serem confusas e por estarem próximas demais dos detalhes internos; o Mercurial é frequentemente citado como tendo um modelo mais limpo e amigável ao usuário (embora hoje seja nichado).

Diffs e sua não unicidade

• Os comentários enfatizam que não existe um único diff canônico: algoritmos e opções (--word-diff, patience, histogram, hunks sensíveis à linguagem) mudam o que os usuários veem.
• Isso pode não coincidir com a forma como os autores conceituam suas edições, mas a maioria aceita “um diff, não o diff” para uso prático.