Quando e como você deve reescrever o histórico do Git?

Question

Accepted Answer

O Git permite que você **reescreva o histórico** — alterando, reorganizando (rebase), compactando ou removendo commits — para limpar commits ou corrigir problemas. É poderoso, mas deve ser feito com cuidado: reescrever histórico **compartilhado** causa problemas sérios, então as regras em torno disso são críticas. ## Maneiras de reescrever o histórico ```text git commit --amend → modify the most recent commit (message or content) git rebase -i → squash, reword, reorder, edit, drop commits (interactive) git rebase → replay commits onto another base (linear history) git reset → move the branch pointer (discard/uncommit) git filter-repo → rewrite MANY commits (remove a file/secret from all history) → All of these change commit HASHES (rewriting = creating new, different commits). ``` ## A regra de ouro ```text ⚠️ NEVER rewrite history that has been PUSHED/SHARED (that others may have): → rewriting changes commit hashes → your history DIVERGES from collaborators' → they'll have the old commits; pulls create duplicates/conflicts; chaos ensues → forces everyone to painfully reconcile → a serious disruption ✓ Rewrite ONLY local, unpushed commits (cleanup before sharing). ✗ On shared branches → use REVERT (a new undoing commit) instead, which is safe. ``` ## Usos legítimos de reescrita (local) ```text ✓ Clean up messy WIP commits before opening a PR (squash, reword) → clean history ✓ Fix a mistake in the last commit (amend) before pushing ✓ Keep a feature branch linear/up-to-date with main (rebase) before sharing ✓ Remove a SECRET accidentally committed (filter-repo) — though if it was PUSHED, the secret must be ROTATED (it's already exposed; rewriting alone isn't enough) ``` ## Se você precisar reescrever o histórico compartilhado (raro) ```text → COORDINATE with the whole team (everyone stops, re-syncs) → Force-push carefully: git push --force-with-lease (safer than --force — checks first) → Everyone must reset/re-clone to the rewritten history → Do this only when truly necessary (e.g. purging a leaked secret) and with agreement. ``` ## Por que isso importa Entender quando e como reescrever o histórico do Git é conhecimento importante de nível sênior porque reescrita de histórico é **poderosa mas perigosa**, e entender as regras — especialmente em relação ao histórico compartilhado — previne problemas sérios enquanto permite limpeza legítima. Conhecer as **maneiras de reescrever** (amend para o último commit, rebase interativo para compactação/reescrita/reordenação, rebase para histórico linear, reset, filter-repo para mudanças em larga escala) e que todas elas **alteram os hashes dos commits** (criando novos commits) é a base. Mais criticamente, entender a **regra de ouro — nunca reescrever histórico compartilhado/enviado** — é essencial porque reescrita muda os hashes, causando seu histórico a divergir do dos colaboradores (que ainda têm os commits antigos), levando a duplicatas, conflitos e reconciliação dolorosa; reescrever histórico compartilhado é uma séria disrupção que essa regra previne, com **revert** (um novo commit seguro de desfazimento) sendo a abordagem correta para branches compartilhados em vez disso. Entender os **usos locais legítimos** (limpeza de commits WIP antes de um PR, correção de erros antes de fazer push, rebase para manter linearidade antes de compartilhar — tudo em commits locais não enviados) clarifica quando reescrita é apropriada e valiosa. Uma nuance de segurança crucial: se um **segredo foi commitado e enviado**, reescrever o histórico para removê-lo é insuficiente — o segredo já está exposto e deve ser **rotacionado** (um ponto importante de segurança no mundo real). Saber como **lidar com a rara reescrita necessária de histórico compartilhado** (coordenação de time, `--force-with-lease` em vez de `--force`, todos resincronizando) reflete julgamento maduro. Como reescrita de histórico é poderosa mas causa problemas sérios quando mal usada em histórico compartilhado, e como entender a regra de ouro, usos legítimos e práticas seguras é essencial para usá-la responsavelmente, entender quando e como reescrever o histórico do Git é conhecimento importante de nível sênior — um tópico onde entender as regras de segurança (especialmente nunca reescrever histórico compartilhado) previne desastres reais de colaboração, refletindo o julgamento esperado para papéis sêniors trabalhando com Git em times.