¿Cuándo y cómo deberías reescribir el historial de Git?

Question

Accepted Answer

Git te permite **reescribir el historial** — enmendar, rebasear, aplastar o eliminar commits — para limpiar commits o arreglar problemas. Es poderoso pero debe hacerse con cuidado: reescribir historial **compartido** causa problemas graves, por lo que las reglas alrededor de esto son críticas. ## Formas de reescribir el historial ```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). ``` ## La regla de oro ```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 reescritura (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) ``` ## Si debes reescribir historial compartido (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 qué es importante Comprender cuándo y cómo reescribir el historial de Git es conocimiento importante de nivel senior porque la reescritura de historial es **poderosa pero peligrosa**, y comprender las reglas — especialmente alrededor del historial compartido — previene problemas graves mientras habilita limpieza legítima. Conocer las **formas de reescribir** (enmendar para el último commit, rebase interactivo para aplastamiento/reescritura de mensajes/reordenamiento, rebase para historial lineal, reset, filter-repo para cambios a gran escala) y que todas **cambian los hashes de commits** (creando nuevos commits) es la base. Más críticamente, comprender la **regla de oro — nunca reescribir historial compartido/pusheado** — es esencial porque reescribir cambia los hashes, causando que tu historial diverja del de los colaboradores (quienes aún tienen los commits antiguos), llevando a duplicados, conflictos y reconciliación dolorosa; reescribir historial compartido es una disrupción seria que esta regla previene, siendo **revert** (un nuevo commit seguro de deshacimiento) el enfoque correcto para ramas compartidas en su lugar. Comprender los **usos locales legítimos** (limpiar commits WIP antes de un PR, enmendar errores antes de pushear, rebasear para mantenerse lineal antes de compartir — todos en commits locales sin pushear) clarifica cuándo la reescritura es apropiada y valiosa. Un matiz de seguridad crucial: si un **secreto fue commiteado y pusheado**, reescribir el historial para eliminarlo es insuficiente — el secreto ya está expuesto y debe ser **rotado** (un punto de seguridad importante del mundo real). Saber cómo **manejar la rara reescritura necesaria de historial compartido** (coordinación de equipo, `--force-with-lease` en lugar de `--force`, que todos re-sincronicen) refleja juicio maduro. Dado que la reescritura de historial es poderosa pero causa problemas graves cuando se usa incorrectamente en historial compartido, y dado que comprender la regla de oro, usos legítimos y prácticas seguras es esencial para usarlo responsablemente, comprender cuándo y cómo reescribir el historial de Git es conocimiento importante de nivel senior — un tema donde comprender las reglas de seguridad (especialmente nunca reescribir historial compartido) previene desastres reales de colaboración, reflejando el juicio esperado para roles senior trabajando con Git en equipos.