您应该在何时以及如何重写Git历史?

Question

您应该在何时以及如何重写Git历史?

Accepted Answer

Git 允许您**重写历史** — 修改、变基、压缩或删除提交 — 以清理提交或修复问题。这很强大但必须小心进行：重写**共享**历史会导致严重问题，所以围绕它的规则至关重要。 ## 重写历史的方式 ```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). ``` ## 黄金法则 ```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. ``` ## 重写历史的合法使用（本地） ```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) ``` ## 如果您必须重写共享历史（罕见） ```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. ``` ## 为什么这很重要理解何时以及如何重写Git历史是重要的高级知识，因为历史重写**功能强大但危险**，理解规则 — 尤其是关于共享历史的规则 — 可以防止严重问题，同时启用合法的清理。知道**重写的方式**（对最后一个提交使用amend、对压缩/改写/重新排序使用交互式变基、对线性历史使用变基、reset、对大规模更改使用filter-repo）以及它们都**改变提交哈希**（创建新提交）是基础。最关键的是，理解**黄金法则 — 永远不要重写共享/推送的历史** — 是必不可少的，因为重写会改变哈希值，导致您的历史与协作者的历史发散（他们仍然有旧提交），导致重复、冲突和痛苦的协调；重写共享历史是一个严重的中断，此规则可以防止这种情况，**revert**（一个安全的新撤销提交）是共享分支的正确方法。理解**合法的本地使用**（在PR之前清理WIP提交、在推送前修正错误、在共享前变基以保持线性 — 都在本地、未推送的提交上）明确了何时重写是适当且有价值的。一个关键的安全细节：如果**机密信息被提交并推送**，重写历史来删除它是不够的 — 机密信息已经暴露，必须**轮换**（一个重要的现实世界安全要点）。了解如何**处理罕见的必要共享历史重写**（团队协调、`--force-with-lease`而不是`--force`、所有人重新同步）反映出成熟的判断力。由于历史重写功能强大但在滥用共享历史时会导致严重问题，而且由于理解黄金法则、合法使用和安全实践对负责任地使用它至关重要，理解何时以及如何重写Git历史是重要的高级知识 — 这是一个理解安全规则（尤其是永远不要重写共享历史）可以防止真实协作灾难的主题，反映了高级职位在团队中使用Git所期望的判断力。