---

Git Commit “删除” 教程：深入理解 Reset 与 Rebase 的区别

在 Git 的世界里，版本历史是一系列相互关联的提交 (Commit)。每个提交都记录了项目在特定时间点的快照，并指向其父提交，从而构建了一条历史链。然而，有时我们可能会因为各种原因需要“删除”或修改历史中的某个或某几个提交。这个“删除”并不是真正地从 Git 仓库中物理删除数据（至少不是立即删除），而是通过重写分支历史，使得特定的提交不再是可达的，从而在当前分支的视角下看起来像是被删除了。

修改 Git 历史是一项强大的能力，但也伴随着风险，尤其是在团队协作的环境中。理解何时以及如何安全地执行这些操作至关重要。本文将详细介绍两种主要用于修改（包括“删除”）提交的方法：git reset 和 git rebase -i，并深入探讨它们的原理、区别、适用场景以及潜在的风险。

为什么需要“删除” Commit？

在实际开发中，我们可能会遇到以下情况，需要考虑修改或“删除”提交：

1. 提交了敏感信息： 不小心将密码、密钥或其他敏感数据提交到了仓库。
2. 犯了错误且不想保留记录： 提交了一个完全错误或不必要的工作，希望完全抹掉这次提交的痕迹（在当前分支上）。
3. 提交历史过于零碎或混乱： 做了很多小的、不完整的提交，希望将它们合并 (squash) 或移除不必要的中间提交，以保持主分支历史的整洁。
4. 在错误的分支上提交： 将提交提交到了错误的分支，需要将其从当前分支移除。
5. 回退到之前的某个状态： 希望完全放弃当前以及后续的一些提交，回到历史上的一个节点。

重要警告：修改共享历史的危险性

在执行任何修改历史的操作之前，请务必明白：

• 修改历史会创建新的提交对象（使用 rebase）或移动分支指针（使用 reset），这会改变分支的 SHA-1 值。
• 如果在已经推送到远程仓库的共享分支上修改历史，这会导致本地分支和远程分支的历史 divergence（分歧）。 当你尝试再次推送到远程时，需要使用 git push --force 或 git push --force-with-lease。
• 强制推送会覆盖远程仓库的历史。 如果其他协作者已经在你修改后（但他们尚未拉取你的修改前）基于旧的远程历史提交了新的工作，你的强制推送会使得他们的历史变得不兼容。他们将不得不采取特殊措施（如 git pull --rebase 或重新克隆仓库）来修复他们本地仓库的历史。
• 因此，强烈建议： 绝对不要在主分支（如 main, master, develop 等）或任何其他团队成员正在积极使用的共享分支上未经协调地执行修改历史的操作！ 如果必须这样做，请务必提前与团队沟通，并确保所有成员都了解如何处理后续的同步问题。
• 在自己的私有分支或刚刚创建、尚未推送到远程的分支上进行历史修改相对安全。

安全替代方案：git revert

对于已经推送到共享仓库的提交，更安全的做法通常是使用 git revert 命令。git revert <commit> 会创建一个新的提交，该提交的作用是撤销指定提交引入的所有更改。这样做的好处是不会修改原有的历史，保留了历史的完整性，因此在共享环境中非常安全。然而，revert 并没有“删除”原有的提交，而是在历史中添加了一个“撤销”记录。本文主要关注的是修改历史以达到“删除”效果的方法，所以 revert 不在本文详细讨论之列，但务必记住这是处理共享历史问题的首选安全方案。

Git 是如何记录历史的？

在深入了解 reset 和 rebase 之前，快速回顾一下 Git 的基本概念：

• Commit (提交): 一个项目的快照，包含文件内容、作者信息、提交信息、时间戳以及一个或多个父提交的指针。
• SHA-1 Hash: 每个 Git 对象（包括提交）都有一个唯一的 40 位哈希值，作为其身份标识。
• Branch (分支): 一个指向某个提交的可变指针。例如，main 分支指针通常指向 main 分支上的最新提交。
• HEAD: 一个特殊的指针，指向你当前工作所在的分支或某个特定的提交。HEAD 通常指向当前分支的尖端 (tip)。
• Reflog (引用日志): Git 会记录 HEAD 和其他引用的移动历史。这是一个本地的日志，可以用来找回丢失的提交。即使你“删除”了提交，它们通常还会在 reflog 中保留一段时间（默认 90 天），让你有机会恢复。

理解这些概念有助于我们理解 reset 和 rebase 如何操作历史。

方法一：使用 git reset “删除” Commit

git reset 命令主要用于移动 HEAD 指针以及当前分支指针到一个指定的提交。它可以用来撤销本地的修改、取消暂存的文件，也可以用来回退到之前的某个提交，从而达到“删除”后续提交的效果。

git reset 有三种主要模式：--soft, --mixed, 和 --hard。它们的区别在于移动指针后如何处理工作区和暂存区：

1. git reset --soft <commit>:

   • 将 HEAD 指针和当前分支指针移动到指定的 <commit>。
   • 保留工作区的内容不变。
   • 保留暂存区 (index) 的内容不变。 这意味着从 <commit> 到原 HEAD 之间的所有变更都会被保留在暂存区，你可以重新提交它们。
   • 效果： 撤销了从 <commit> 之后的所有提交，但保留了这些提交引入的更改，并将这些更改标记为已暂存。

2. git reset --mixed <commit> (默认模式):

   • 将 HEAD 指针和当前分支指针移动到指定的 <commit>。
   • 保留工作区的内容不变。
   • 重置暂存区 (index)，使其与 <commit> 保持一致。 从 <commit> 到原 HEAD 之间的所有变更都会被保留在工作区，但不再处于暂存状态。你需要重新 git add 并 git commit。
   • 效果： 撤销了从 <commit> 之后的所有提交，保留了这些提交引入的更改，但需要重新暂存和提交。

3. git reset --hard <commit>:

   • 将 HEAD 指针和当前分支指针移动到指定的 <commit>。
   • 重置工作区的内容，使其与 <commit> 完全一致。 这会丢弃从 <commit> 到原 HEAD 之间的所有对文件的修改。
   • 重置暂存区 (index)，使其与 <commit> 保持一致。
   • 效果： 这是最彻底的回退方式。它会完全抹掉从 <commit> 之后的所有提交及其引入的更改。这是我们用来实现“删除”最近提交的主要模式。

使用 git reset --hard “删除”最近的 Commit

git reset --hard 是用于“删除”位于分支末端（最新提交）的提交最直接的方式。

假设你的分支历史如下：

A -- B -- C -- D -- E (HEAD, main)

你想“删除”提交 E 和 D，让分支回到提交 C 的状态。

你可以使用 git reset --hard 命令，指定你想要回到的目标提交。目标提交可以是其哈希值，也可以是相对于 HEAD 的相对引用。

• HEAD~n 表示 HEAD 指针向后移动 n 个提交。HEAD~1 是 HEAD 的父提交，HEAD~2 是 HEAD 的爷爷提交，依此类推。

要删除最新的两个提交 (E 和 D)，你需要回到提交 C，而 C 是 HEAD 的爷爷提交 (HEAD~2)。

步骤：

1. 确保工作区干净： 在执行 --hard reset 之前，强烈建议先提交或暂存 (stash) 你当前的修改，以免意外丢失。使用 git status 检查。
2. 执行 reset 命令：
   bash
git status # 检查工作区是否干净
git log --oneline # 查看当前历史，确定要回退到哪个提交
git reset --hard HEAD~2
# 或者使用 C 的完整或部分哈希值 (例如假设 C 的哈希值是 abcde)
# git reset --hard abcde
3. 检查结果：
   bash
git log --oneline # 查看新的历史
git status # 检查工作区和暂存区是否被重置

执行 git reset --hard HEAD~2 后，你的分支历史会变成：

A -- B -- C (HEAD, main)

提交 D 和 E 似乎被“删除”了。它们不再是 main 分支历史的一部分。工作区和暂存区也被重置到提交 C 的状态。

git reset --hard 的优点：

• 简单易懂，尤其是用于移除最近的提交。
• 直接有效，一步到位改变分支指针、暂存区和工作区。

git reset --hard 的缺点：

• 破坏性强： --hard 会永久丢失工作区和暂存区中未提交或未暂存的更改。
• 仅适用于移除分支末端的提交： 如果你想删除历史中间的某个提交，而保留它之后的提交，reset 就无能为力了，或者需要更复杂的手动操作。
• 改变分支历史： 与所有重写历史的操作一样，如果在共享分支上执行并强制推送，会影响协作者。

适用场景：

• 你在本地分支上刚提交了几个提交，但立即发现完全错了，希望完全回到之前的状态。
• 你需要放弃当前分支上的所有工作，快速回到远程仓库的最新状态（结合 git fetch 和 git reset --hard origin/your-branch）。
• 你需要清除工作区和暂存区的所有修改，回到 HEAD 提交的干净状态 (git reset --hard HEAD)。

方法二：使用 git rebase -i (交互式 Rebase) “删除” Commit

git rebase 命令的本意是重新应用一系列提交。它会先找到两个分支的共同祖先，然后将当前分支上独有的提交“提取”出来，接着将当前分支指向新的基底（base，可以是另一个分支的最新提交，也可以是历史中的某个提交），最后将之前提取的提交按照顺序重新应用到新的基底之上。

git rebase 的强大之处在于其交互式模式 (-i, interactive)。通过交互式模式，我们可以在重新应用提交的过程中修改提交列表，包括：

• 挑选 (pick) 哪些提交要保留。
• 删除 (drop) 哪些提交。
• 重新排序提交。
• 合并 (squash, fixup) 多个提交。
• 修改提交信息 (reword)。
• 编辑 (edit) 某个提交（可以在应用该提交时暂停 rebase 过程，进行修改或拆分）。

使用 git rebase -i “删除”历史中间或末端的 Commit

交互式 rebase 是删除历史中间提交的首选方法，也可以用来删除末端提交。

假设你的分支历史如下：

A -- B -- C -- D -- E -- F (HEAD, feature-branch)

你想“删除”提交 C 和 E。提交 C 在中间，提交 E 在末端附近。

你需要告诉 Git 你想对哪个范围的提交进行交互式 rebase。git rebase -i <base_commit> 命令会让你编辑从 <base_commit> 之后直到当前 HEAD 的所有提交。

要删除 C 和 E，我们需要编辑从 A 之后的提交。A 是 B 的父提交。我们可以指定 B 的哈希值作为 base_commit，或者使用相对引用，例如 HEAD~5（从 F 往回数 5 个提交到达 B）。

步骤：

1. 确定要 rebase 的范围： 你需要指定一个基底提交，该提交本身不会被编辑，但其之后的所有提交都会出现在交互式列表中。要删除 C 和 E，你的基底应该是 C 的父提交 B。假设 B 的哈希值是 bbbbb，或者你可以用 HEAD~5 来引用它。
2. 执行交互式 rebase 命令：
   bash
git log --oneline # 查看历史，确定基底提交 (这里是 B 或 HEAD~5)
git rebase -i HEAD~5
# 或者 git rebase -i bbbbb

3. 编辑提交列表： Git 会打开一个文本编辑器，显示从基底提交之后的所有提交列表。每一行代表一个提交，格式通常是 pick <commit_hash> <commit_message>。

   “`
   pick ccccc Commit message for C
   pick ddddd Commit message for D
   pick eeeee Commit message for E
   pick fffff Commit message for F

   Rebase bbbbb..fffff onto bbbbb (4 commands)

   Commands:

   p, pick = use commit

   r, reword = use commit, but edit the commit message

   e, edit = use commit, but stop for amending

   s, squash = use commit, but meld into previous commit

   f, fixup = like “squash”, but discard this commit’s log message

   x, exec = run command (the rest of the line) after checkout

   b, break = stop here (to break a series of commits)

   d, drop = discard the commit

   l, label = label the current HEAD with a name

   t, Tanner = like “label”, but warn if the label has already been used

   m, merge [-C | -C ] = merge the specified commit and stop for editing

   These lines can be re-ordered; they are executed from top to bottom.

   If you remove a line here THAT COMMIT WILL BE LOST.

   However, if you remove everything, the rebase will be aborted.

   “`

   要删除提交，只需将对应行的 pick 命令改为 drop，或者直接删除整行。

   根据我们的目标（删除 C 和 E），我们将文件修改为：

   “`
   drop ccccc Commit message for C # 或直接删除这一行
   pick ddddd Commit message for D
   drop eeeee Commit message for E # 或直接删除这一行
   pick fffff Commit message for F

   … (其他帮助信息不变)

   “`

   保存并关闭编辑器。

4. Rebase 过程执行： Git 会按照修改后的列表重新应用提交。它会基于基底提交 B，先应用 D，然后应用 F。

   • 可能发生冲突： 如果被删除的提交（C 或 E）或保留的提交 (D, F) 之间存在文件修改冲突，Git 会在 rebase 过程中暂停，提示你解决冲突。你需要手动编辑文件解决冲突，然后使用 git add <resolved-files> 暂存修改，最后使用 git rebase --continue 继续 rebase 过程。如果想放弃 rebase，可以使用 git rebase --abort。

5. 检查结果： Rebase 完成后，查看新的历史：

   bash
git log --oneline

   新的历史将是：

   A -- B -- D' -- F' (HEAD, feature-branch)

   注意，提交 D 和 F 的哈希值可能已经改变（变为 D’ 和 F’）。这是因为它们的父提交链发生了变化（它们现在直接基于 B，而不是之前的 C 或 E），Git 会创建新的提交对象。提交 C 和 E 不再是 feature-branch 历史的一部分。

git rebase -i 的优点：

• 灵活强大： 不仅可以删除提交，还可以重新排序、合并、拆分、修改提交信息等，是整理提交历史的利器。
• 可以删除历史中间的提交： 这是 reset 难以做到的。

git rebase -i 的缺点：

• 操作相对复杂： 需要理解交互式编辑器的指令，处理潜在的冲突。
• 改变所有后续提交的哈希值： 从基底提交到 HEAD 之间的所有保留的提交都会被重新创建，拥有新的哈希值。
• 改变分支历史： 与 reset 类似，如果在共享分支上执行并强制推送，会影响协作者。
• 可能引入冲突： 如果被删除的提交与保留的提交有相互关联的修改，解决冲突可能会比较棘手。

适用场景：

• 你需要从一段提交历史中移除一个或多个提交，无论它们在历史的哪个位置。
• 你需要合并多个零散的提交成一个有意义的大提交。
• 你需要修改某个历史提交的提交信息。
• 你需要重新排列提交的顺序。
• 在将功能分支合并到主分支之前，你需要清理功能分支的提交历史，使其更线性、更易读。

对比 git reset --hard 和 git rebase -i

特性	git reset --hard <commit>	git rebase -i <base_commit>
主要作用	移动 HEAD 和分支指针，重置工作区/暂存区	重新应用一系列提交到新的基底
“删除”方式	简单地截断历史，后续提交变得不可达	重新创建保留的提交，被 drop 的提交则被排除
适用位置	主要用于“删除”分支末端的提交	可以“删除”历史中间或末端的提交
复杂度	相对简单直接	相对复杂，需要编辑列表，可能处理冲突
对提交哈希的影响	保留被回退到的提交及其之前的提交的哈希值，后续提交被丢弃	从基底提交到 HEAD 之间保留的所有提交会创建新的哈希值
对工作区/暂存区	--hard 模式会彻底重置工作区和暂存区	整个过程在 Git 内部进行，最终工作区与新的 HEAD 一致，暂存区清空
潜在风险	数据丢失 (未提交/未暂存的工作)，修改共享历史	冲突解决，修改共享历史，操作失误可能导致混乱
何时使用	需要快速丢弃最近的几个提交并回到干净状态时	需要精细地修改一段提交历史（删除、合并、重排、编辑）时

Reflog：你的救命稻草

无论你使用 git reset --hard 还是 git rebase -i，“删除”的提交并不会立即从 Git 仓库中消失。它们只是变得不再是任何分支或标签的直接祖先，因此从正常的 git log 中看不到了。但是，Git 的 reflog (引用日志) 记录了 HEAD 和分支指针在本地仓库中的移动历史。

如果你不小心删除了错误的提交，或者想找回之前丢失的提交，可以使用 git reflog 来查看历史记录。

bash
git reflog

输出类似这样：

ffffff (HEAD -> main) HEAD@{0}: commit: Final commit
eeeeee HEAD@{1}: commit: Another feature
dddddd HEAD@{2}: commit: Implement part 2
cccccc HEAD@{3}: rebase -i (finish): returning to refs/heads/main
dddddd HEAD@{4}: rebase -i (drop): Commit message for C
bbbbbb HEAD@{5}: rebase -i (start): rolling back to bbbbb
aaaaaa HEAD@{6}: commit (initial): Initial commit

HEAD@{n} 表示 n 次操作之前的 HEAD 位置。你可以看到 reset 或 rebase 操作的记录。即使是那些被 drop 或被 reset --hard 移除的提交，其操作记录也会留在 reflog 中。

如果你想回到某个 reflog 条目指向的状态（例如，想找回在 HEAD@{1} 时的提交 eeeeee），你可以使用 git reset --hard 结合 reflog 引用：

“`bash
git reset –hard HEAD@{1}

或者使用你想恢复到的那个提交的哈希值（可以从 reflog 输出中找到）

git reset –hard eeeeee

“`

这将把 HEAD 和当前分支指针移动回指定的提交，工作区和暂存区也会恢复到那个状态。

重要提示： reflog 只保存在本地仓库中，不会推送到远程。而且 reflog 中的条目也会过期（默认 90 天），过期后 Git 会执行垃圾回收 (garbage collection)，此时提交才可能真正从仓库中被物理删除。

总结与最佳实践

• “删除”提交本质上是重写历史，使其在当前分支上不可见。
• git reset --hard 是删除分支末端提交的最快方式，但会丢失未提交/未暂存的工作，且无法处理历史中间的提交。
• git rebase -i 是修改（包括删除）一段历史中任意位置提交的强大工具，但操作更复杂，会改变后续提交的哈希值，并可能引入冲突。
• 在共享分支上，强烈建议不要使用 reset 或 rebase 来修改已经推送的提交。使用 git revert 是更安全的选择。
• 始终在修改历史前确认当前分支状态，最好先进行提交或暂存。
• 熟练使用 git log --oneline 来查看历史，确定要操作的提交或范围。
• 记住 git reflog 是你的后悔药，可以在操作失误后帮助你找回丢失的提交。
• 如果必须在共享分支上修改历史并强制推送，务必提前与团队沟通，并确保他们知道如何处理（通常是 git pull --rebase）。

修改 Git 历史是每个开发者都需要掌握的技能，但必须谨慎使用。理解 reset 和 rebase 的原理和区别，以及何时使用它们，是成为一个高效 Git 用户的重要一步。多在自己的本地实验仓库中练习，才能在需要时安全地应用这些强大的命令。

希望这篇详细的教程能帮助你理解 Git 中如何“删除”提交以及 git reset 和 git rebase 的不同之处。祝你在 Git 的世界里操作顺利！

---