Quando e come dovresti riscrivere la cronologia di Git?

Question

Accepted Answer

Git ti permette di **riscrivere la cronologia** — modificare, fare rebase, comprimere o rimuovere commit — per pulire i commit o risolvere problemi. È potente ma deve essere fatto con attenzione: riscrivere la cronologia **condivisa** causa seri problemi, quindi le regole attorno a ciò sono critiche. ## Modi per riscrivere la cronologia ```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 regola d'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. ``` ## Usi legittimi della riscrittura (locale) ```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 devi riscrivere la cronologia condivisa (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. ``` ## Perché è importante Comprendere quando e come riscrivere la cronologia di Git è una conoscenza importante a livello senior perché la riscrittura della cronologia è **potente ma pericolosa**, e comprendere le regole — soprattutto riguardo la cronologia condivisa — previene seri problemi mentre consente una pulizia legittima. Conoscere i **modi per riscrivere** (amend per l'ultimo commit, rebase interattivo per comprimere/rinominare/riordinare, rebase per una cronologia lineare, reset, filter-repo per cambiamenti su larga scala) e che tutti loro **cambiano gli hash dei commit** (creando nuovi commit) è la base. Più criticamente, comprendere la **regola d'oro — non riscrivere mai la cronologia condivisa/pushata** — è essenziale perché riscrivere cambia gli hash, causando la divergenza della tua cronologia da quella dei collaboratori (che hanno ancora i vecchi commit), portando a duplicati, conflitti e riconciliazioni dolorose; riscrivere la cronologia condivisa è un'interruzione seria che questa regola previene, con **revert** (un nuovo commit sicuro di annullamento) che è l'approccio corretto per i rami condivisi invece. Comprendere gli **usi legittimi locali** (pulire i commit WIP prima di una PR, emendare errori prima di pushare, fare rebase per rimanere lineare prima di condividere — tutto su commit locali e non pushati) chiarisce quando la riscrittura è appropriata e preziosa. Una sfumatura di sicurezza cruciale: se un **segreto è stato committato e pushato**, riscrivere la cronologia per rimuoverlo è insufficiente — il segreto è già esposto e deve essere **ruotato** (un punto di sicurezza importante nel mondo reale). Sapere come **gestire la rara riscrittura necessaria della cronologia condivisa** (coordinamento del team, `--force-with-lease` piuttosto che `--force`, tutti si risincronizzano) riflette un giudizio maturo. Poiché la riscrittura della cronologia è potente ma causa seri problemi quando usata male sulla cronologia condivisa, e poiché comprendere la regola d'oro, gli usi legittimi e le pratiche sicure è essenziale per usarla responsabilmente, comprendere quando e come riscrivere la cronologia di Git è una conoscenza importante a livello senior — un argomento dove comprendere le regole di sicurezza (soprattutto non riscrivere mai la cronologia condivisa) previene veri disastri di collaborazione, riflettendo il giudizio atteso per i ruoli senior che lavorano con Git nei team.