Git时间旅行：优雅地改写历史提交

Git 的提交历史就像一本日记本，每一页都盖上了时间的邮戳和作者的签名，不容篡改。

但总有些时候，我们会希望能悄悄擦掉一笔、修个错别字，甚至“重写历史”。

本篇文章就带你像时间旅行者一样，优雅、安全地掌握 Git 的历史修改技巧。

一、理解 Git 历史的本质

在学习如何“改写历史”之前，我们需要先弄明白 Git 是如何记录历史的，这能帮我们理解修改的原理。

哈希值即提交指纹

每个提交都有一个唯一的哈希（如 abc123），它由以下内容共同生成：

• 提交的内容（文件快照）
• 提交信息
• 作者及时间戳
• 父提交的哈希值

哪怕只改一个字，都会生成一个新的哈希，就像给历史换了个指纹。

改写原理：创建新提交链

Original: A---B---C ← main
Modified: A---B---C' ← main

重写后的提交（如 C'）会生成新的哈希，Git 会让分支指向新链条，而旧的 C 虽然仍存在于对象数据库中，但不再可达。

二、单人作战：安全修改指南

在个人分支开发阶段，你可以放心大胆地修改历史。

场景1：修改最近一次提交

开发时最常见的情况是“漏了个文件”或“写错了提交信息”。

对于这种情况我们可以用 --amend 进行修改：

# 补充漏掉的文件
git add forgotten_file.cpp
git commit --amend --no-edit  # 保留原提交信息

# 修改提交信息
git commit --amend -m "PROJ-123: 修复紧急bug"

修改后，提交哈希也会发生变化：

原历史：A---B---C
新历史：A---B---C'

场景2：修改更早的提交（开启时光机）

如果我们想回到几次提交之前进行修改，那么我们需要搭乘rebase时光机回到过去。

假设我们要修改最近的第二个提交，那我们可以进行如下操作：

# 修改最近3个提交
git rebase -i HEAD~3

执行命令后会打开一个编辑器，我们可以看到类似下方的提交列表：

pick a1b2c3 提交3
pick d4e5f6 提交2
pick g7h8i9 提交1

由于我们需要修改提交2，因此需要把提交2前的pick修改为edit。

然后按下ctrl+x退出，此时编辑器会询问是否保存修改，选择Y，最后按下Enter就回到了提交2。

接下来：

# 修改文件并暂存
git add .

# 修改该提交
git commit --amend

# 继续执行剩下的 rebase
git rebase --continue

结果：

原历史：A---B---C---D
新历史：A---B---C'---D'

三、多人协作：改历史时请三思

在多人协作的分支中修改历史的风险是很大的，因为你会影响别人的时间线。

修改历史后，你需要使用强制推送命令将自己的修改推送到远程：

git push --force origin main  # 操作危险，需谨慎

但是这可能带来以下问题：

1. 覆盖远程仓库历史，造成提交丢失；
2. 同事本地分支基于旧提交，出现冲突或悬空；
3. 自动化流程（CI/CD）可能失效或误触发。

总结

Git 改写历史的能力是一把利器，让我们可以维护整洁的提交记录、修复失误、统一风格。

但利器也是双刃剑，在协作开发中滥用可能带来巨大麻烦。

所以，我们每次准备推送一个改写的分支之前，最好先问自己三个问题：

1. 是否有其他人也在这个分支上工作？
2. 是否为原历史创建了备份？
3. 是否提前通知了团队成员？

希望本文对你有帮助～
本文首发于微信公众号《Linux在秋名山》，欢迎大家关注~