---

Git 撤销 Commit 操作指南：后悔药与时光机

在使用 Git 进行版本控制的过程中，提交（Commit）是我们记录项目状态、保存阶段性成果的关键步骤。每一次 git commit 都像是在项目时间线上打上一个快照，记录了特定时刻的代码和文件状态。然而，人非圣贤，孰能无过？在开发过程中，我们难免会遇到需要“撤销”某个提交的情况：可能是提交信息写错了，可能是漏提交了文件，可能是提交了不该提交的内容，又或者是发现某个历史提交引入了严重的 Bug。

幸运的是，Git 作为一款强大的版本控制工具，提供了多种灵活的方式来“撤销”或修改提交。但这并非简单的“Ctrl+Z”操作，不同的场景、不同的目的、以及提交是否已经被推送到共享仓库，都需要采用不同的 Git 命令和策略。理解这些不同的撤销方式及其背后的原理，是每一位 Git 使用者必备的技能。

本文将详细介绍 Git 中常用的撤销 Commit 操作，涵盖从最简单的修改最新提交，到撤销历史提交，再到如何在共享分支上安全地撤销提交等各种场景。我们将深入探讨 git commit --amend, git reset, git revert, git rebase -i 等命令的使用方法、适用场景、以及它们对项目历史的影响，帮助你像一位经验丰富的 Git 使用者那样，自如地在版本历史中穿梭和修正错误。

1. 理解 Git 中的“撤销”

首先，我们需要明确 Git 中的“撤销”通常不是真正意义上的“删除”历史。Git 的设计哲学是尽量保留历史记录，即使是错误的提交。很多撤销操作，尤其是在公共分支上进行的，实际上是通过添加新的提交来抵消或修正之前的错误提交，而不是直接抹去历史。只有在特定的、通常是本地的、尚未共享的情况下，我们才会真正“重写”历史。

在探讨具体的撤销命令之前，理解几个核心概念至关重要：

• HEAD: 指向当前分支的最新提交。几乎所有 Git 操作都围绕着 HEAD 展开。
• Commit Hash: 每个提交都有一个唯一的 SHA-1 哈希值，用于标识该提交。
• 工作目录 (Working Directory): 你当前在文件系统中看到的、正在编辑的文件区域。
• 暂存区 (Staging Area/Index): 一个介于工作目录和版本历史之间的区域，用于存放你准备提交的文件修改。git add 命令就是将修改从工作目录添加到暂存区。
• 本地仓库 vs. 远程仓库: 操作是只影响你本地的提交历史，还是会影响已经被推送到共享远程仓库的提交。这是选择撤销策略的关键因素。

接下来，我们将根据不同的需求和场景，详细介绍各种撤销 Commit 的方法。

2. 撤销最新一次本地 Commit

这是最常见也相对最安全的一种撤销场景：你刚刚进行了 git commit，但立即发现有问题。

2.1 修改最新提交信息或添加/删除文件 (git commit --amend)

场景:
* 你刚提交了，但提交信息写错了字或不够清晰。
* 你刚提交了，但发现漏掉了一个修改，或者不小心把一个不该提交的文件提交进去了。

方法: 使用 git commit --amend 命令。

原理: 这个命令会用一个新的提交替换当前的 HEAD 提交。新的提交会包含你当前暂存区（Index）中的内容，以及你提供的新提交信息（或者沿用旧的，如果你只修改了文件）。本质上，它是将暂存区的内容和当前提交的内容“合并”成一个新的提交，然后用这个新提交来替换掉旧的最新提交。旧的提交会被丢弃（但可以通过 git reflog 找回）。

使用步骤:

1. 修改提交信息:
   bash
git commit --amend
   执行此命令会打开一个文本编辑器，其中包含你上次提交的信息。修改后保存并关闭编辑器即可。

2. 添加/删除文件后再修改提交:

   • 如果你漏掉了一个文件或修改：先将该文件或修改添加到暂存区。
     bash
git add <被漏掉的文件>
git add <包含漏掉修改的文件>
   • 如果你想从上次提交中移除一个文件（该文件仍在你的工作目录）：
     bash
git reset HEAD <不想提交的文件> # 从暂存区移除该文件
# 此时，该文件虽然还在工作目录，但不会被包含在 amend 的新提交中
   • 如果你想完全删除一个文件（从工作目录和 Git 跟踪中）：
     bash
git rm <不想提交的文件> # 移除并添加到暂存区
   • 完成暂存区的修改后，执行：
     bash
git commit --amend
     这会用当前暂存区的内容（包含了你刚才添加/移除的文件修改）以及原有的提交信息（你可以修改）来替换掉上一次提交。

注意: git commit --amend 会改写历史，因为它替换了最新的提交。如果这个提交已经被推送到远程仓库，不要使用此命令，除非你清楚自己在做什么并且愿意强制推送 (git push --force)，但这通常在协作环境中不推荐。对于本地尚未推送的提交，amend 是一个非常方便且常用的修正工具。

2.2 撤销最新一次 Commit，保留修改 (git reset HEAD~1)

场景: 你刚提交了，但觉得这次提交完全是错的，不想保留这次提交记录，但希望保留这次提交所包含的所有修改，以便重新组织后再提交。

方法: 使用 git reset HEAD~1 命令。HEAD~1 表示 HEAD 指向的提交的父提交（也就是 HEAD 前面一个提交）。

原理: git reset 命令用于移动 HEAD 指针以及当前分支的指向。根据使用的选项，它还可以影响暂存区和工作目录。
* HEAD~1 是一个相对引用，表示当前 HEAD 的父提交。
* reset 命令会将当前分支指针移动到 HEAD~1。
* reset 命令默认使用 --mixed 模式。

git reset 的三种模式 (针对 git reset <target>):

• --soft:

  • 移动 HEAD 指针和当前分支到 <target> 提交。
  • 保留暂存区和工作目录的状态。也就是说，所有被撤销的提交所引入的修改，都会回到暂存区。
  • 命令示例: git reset --soft HEAD~1
  • 结果: 最新一次提交被撤销，修改回到暂存区，你可以直接 git commit 重新提交。

• --mixed (默认):

  • 移动 HEAD 指针和当前分支到 <target> 提交。
  • 重置暂存区以匹配 <target> 提交。
  • 保留工作目录的状态。也就是说，所有被撤销的提交所引入的修改，都会回到工作目录，成为未暂存的修改。
  • 命令示例: git reset HEAD~1 或 git reset --mixed HEAD~1
  • 结果: 最新一次提交被撤销，修改回到工作目录，你需要重新 git add 并 git commit。这是最常用的一种，因为你可以重新选择哪些修改要暂存。

• --hard:

  • 移动 HEAD 指针和当前分支到 <target> 提交。
  • 重置暂存区以匹配 <target> 提交。
  • 重置工作目录以匹配 <target> 提交。这意味着所有未提交的修改，以及被撤销提交所引入的修改，都会被永久丢弃！
  • 命令示例: git reset --hard HEAD~1
  • 结果: 最新一次提交被撤销，所有相关修改和未提交的修改都被丢弃。这是最危险的命令，请务必谨慎使用。

对于撤销最新一次提交并保留修改的场景，推荐使用 --soft 或 --mixed:

• 如果你想立即重新提交（也许只是修改了信息或少量内容），使用 git reset --soft HEAD~1，然后 git commit -m "新的提交信息"。
• 如果你想重新组织修改内容（添加/删除文件，修改代码），使用 git reset HEAD~1 (即 --mixed)，然后 git status 查看未暂存的修改，重新 git add 并 git commit。

示例:

“`bash

假设你刚提交了一个错误，提交信息是 “Fix bug A”

git log –oneline # 查看日志，确认最新的提交是你想要撤销的

撤销最新提交，保留修改在工作目录（未暂存）

git reset HEAD~1

git status # 此时会看到之前提交的修改显示为 Unstaged changes

现在你可以重新组织修改，比如修改文件，或者使用 git add 重新暂存部分或全部修改

git add . # 重新暂存所有修改
git commit -m “这次写对提交信息了，或者修改了内容” # 重新提交
“`

注意: git reset 同样会改写历史，因为它移动了分支指向，丢弃了旧的提交（虽然可通过 reflog 找回）。因此，不应用于已经被推送到共享仓库的提交。

2.3 撤销最新一次 Commit 并丢弃修改 (git reset --hard HEAD~1)

场景: 你刚提交了，但这次提交完全是错误的，并且你也不想要这次提交所包含的任何修改，想回到提交之前的干净状态。

方法: 使用 git reset --hard HEAD~1。

原理: 如前所述，--hard 模式会将分支、暂存区和工作目录全部重置到目标提交 (HEAD~1) 的状态。

使用步骤:

“`bash

假设你刚提交了一个错误，并且完全不想保留任何相关修改

git log –oneline # 查看日志，确认最新的提交是你想要撤销的

撤销最新提交，并丢弃所有相关修改和未提交的修改

git reset –hard HEAD~1

git status # 此时工作目录应该与 HEAD~1 提交完全一致，是干净的
“`

极度重要警告: git reset --hard 会永久丢失你工作目录和暂存区中所有未提交的修改以及被撤销提交所引入的修改。请务必在使用前确认你真的不想要这些修改了。

3. 撤销历史 Commit (尚未推送到共享仓库)

如果需要撤销的提交不是最新的，而是在历史记录中间（并且这些提交尚未被推送到共享仓库），情况会稍微复杂一些。主要的方法是使用交互式变基（Interactive Rebase）。

3.1 通过交互式变基丢弃历史 Commit (git rebase -i)

场景: 你在本地提交了一系列提交，但发现其中有某个（或某几个）提交是错误的、不必要的，或者你想合并（squash）几个提交，修改历史提交信息等。

方法: 使用 git rebase -i <commit-before-the-one-to-drop> 命令。

原理: 交互式变基允许你修改一系列提交。通过指定在变基编辑器中将某个提交的操作从 pick 改为 drop，可以达到丢弃该提交的目的。变基的本质是 Git 会从指定的 <commit-before-the-one-to-drop> 开始，逐个重新应用后续的提交。如果你标记为 drop，该提交就不会被重新应用，从而从历史中移除。

使用步骤:

1. 确定目标范围: 找到你想要撤销的提交，以及该提交的前一个提交的哈希值或相对引用。例如，如果你想丢弃倒数第3个提交，你需要对倒数第4个提交进行变基。HEAD~N 表示 HEAD 前面 N 个提交。如果你想修改从 HEAD 到 HEAD~5 之间的提交，你需要对 HEAD~6 进行变基。
   bash
# 查看最近的提交历史，找到你要操作的提交及其之前的那个提交
git log --oneline
   假设你想丢弃提交 C，你的历史是 A -- B -- C -- D -- E (HEAD)。你需要对 B 进行变基：
   bash
git rebase -i B的哈希值
   或者使用相对引用，对 HEAD~3 (即 B) 进行变基：
   bash
git rebase -i HEAD~3

2. 编辑变基指令: 执行命令后，会打开一个文本编辑器，显示类似这样的内容：
   “`
   pick C的提交信息
   pick D的提交信息
   pick E的提交信息

   Rebase <哈希值>..<哈希值> onto <哈希值> (3 commands)

   Commands:

   p, pick = use commit

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

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

   x, exec = run command (here)

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

   d, drop = discard commit

   l, label = label current HEAD with a name

   t, reset = reset HEAD to a label

   m, merge [-c |–[no-]ff] commit the result of a merge

   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），然后是提交哈希，最后是提交信息。
找到你想要丢弃的提交（例如 C 的那一行），将其左边的pick改为drop`。

   pick <B的哈希值> B的提交信息 # B 不在编辑器里，因为我们从 B 后面开始变基
drop <C的哈希值> C的提交信息
pick <D的哈希值> D的提交信息
pick <E的哈希值> E的提交信息

3. 保存并关闭编辑器: Git 会开始执行变基操作。它会从 B 开始，应用 D，然后应用 E。提交 C 因为被标记为 drop 而会被跳过。

4. 处理冲突 (如果发生): 如果在重新应用后续提交时（比如应用 D 或 E）与丢弃 C 引入的变更产生冲突，Git 会停下来让你解决冲突。解决冲突后，使用 git add <解决冲突的文件>，然后执行 git rebase --continue 继续变基。如果想中止变基，使用 git rebase --abort。

5. 完成: 变基成功完成后，你的历史就变成了 A -- B -- D' -- E'。提交 C 已经被移除。注意 D 和 E 可能因为父提交变化而产生新的哈希值，这里用 D' 和 E' 表示。

注意: 交互式变基会重写历史。因此，绝对不要对已经被推送到共享仓库的提交使用交互式变基来修改或删除提交，除非你能够强制推送且你的团队允许这样做（这通常只在特殊情况下或个人分支上进行）。在本地分支上修改未推送的提交则非常安全。

4. 撤销历史 Commit (已推送到共享仓库)

一旦提交被推送到共享仓库，通常就不应该使用 git reset 或 git rebase -i 来改写历史了。因为改写历史会让其他协作者的仓库历史与远程仓库不一致，导致他们拉取（pull）或推送（push）时出现问题，通常需要强制推送和复杂的协调工作。

在共享分支上，最安全和推荐的撤销历史提交的方法是使用 git revert。

4.1 通过创建新的撤销提交 (git revert)

场景: 你或你的团队成员不小心推送了一个包含错误或引入 Bug 的提交，现在需要撤销那个提交的修改，但同时保留所有后续的提交历史。

方法: 使用 git revert <commit-hash> 命令。

原理: git revert 不会删除或修改现有的提交。它会创建一个新的提交，这个新提交的内容是目标提交所引入的修改的反向操作。例如，如果目标提交添加了一行代码，revert 提交就会删除这一行；如果目标提交删除了一个文件，revert 提交就会重新创建这个文件（恢复到目标提交之前的内容）。这样，通过添加一个新的提交，就抵消了错误提交的影响，而整个历史记录（包括错误提交本身和所有后续提交）都被保留下来。

使用步骤:

1. 找到目标提交: 使用 git log --oneline 或其他方式找到你想要撤销的提交的哈希值。
   bash
git log --oneline
# 假设你想撤销提交 FAILED_COMMIT_HASH

2. 执行 Revert:
   bash
git revert FAILED_COMMIT_HASH
   执行此命令会打开一个文本编辑器，为你准备新撤销提交的提交信息（默认会包含原提交信息和 revert 说明）。确认或修改后保存并关闭编辑器。

3. 完成: Git 会创建一个新的提交，这个提交包含了撤销 FAILED_COMMIT_HASH 所需的所有修改。

撤销多个提交:

• 撤销一系列连续提交:
  bash
# 撤销 A, B, C 三个连续提交，从最老的 A 开始应用 revert
# 注意顺序是反向的，revert A B C 会先revert C，再revert B，再revert A
git revert A的哈希值..C的哈希值
  或者，如果你想从最新的 C 开始撤销到 A (但不包括 A 的父提交)，使用范围表示法：
  bash
# 撤销 C, B, A，顺序从 C 到 A
git revert C的哈希值..A的父提交的哈希值 # 注意是 A 的父提交
  更简单的，如果想撤销最近的 N 个提交：
  bash
git revert HEAD~N..HEAD # 撤销 HEAD~N, ..., HEAD
  默认情况下，git revert 每撤销一个提交都会创建一个新的提交。可以使用 -n 或 --no-commit 选项来阻止自动提交，将所有撤销的修改暂存起来，然后手动进行一次提交。

  bash
git revert -n HEAD~3..HEAD # 撤销最近3个提交，但不自动提交
git status # 查看所有撤销的修改都被暂存了
git commit -m "Revert last 3 commits" # 手动提交一次

• 撤销不连续的提交: 只需要多次执行 git revert <commit-hash> 命令即可。

优点: git revert 是在共享分支上撤销提交的首选方法，因为它不会改写历史，而是通过添加新的提交来抵消错误，对其他协作者非常友好。

缺点: 会在历史中留下“撤销提交”的记录，使得历史线看起来不那么“干净”。如果同一个修改被多次提交和撤销，历史可能会变得复杂。

5. 当操作失误时：git reflog 是你的救星

无论你使用了 git reset, git rebase 还是其他可能改写历史的命令，如果你发现不小心丢失了某个提交或者把仓库弄乱了，不要惊慌。Git 还有一个强大的安全网：git reflog。

原理: git reflog (Reference Logs) 记录了你的 HEAD 在本地仓库中移动过的所有地方。每一次提交、每一次变基、每一次重置、每一次合并等等操作，都会在 reflog 中留下记录。这意味着即使你通过 reset --hard 丢弃了提交，或者通过 rebase 重写了历史，只要这些操作发生在你本地仓库中，并且还没有被 Git 的垃圾回收机制清理掉，你就可以通过 reflog 找回丢失的提交。

使用方法:

1. 查看 Reflog:
   bash
git reflog
# 或者更详细的格式
git reflog show
   你会看到类似以下的输出：
   e77c413 (HEAD -> master) HEAD@{0}: commit: Add feature X
a1b2c3d HEAD@{1}: reset: moving to HEAD~1
f4e5d6c HEAD@{2}: commit: Fix bug B (ORIG_HEAD)
1a2b3c4 HEAD@{3}: commit: Implement feature Y
...
   每一行代表 HEAD 曾经到达的一个状态。HEAD@{n} 表示 HEAD 在 n 个操作之前所指向的提交。

2. 恢复丢失的提交/状态: 找到你想要恢复的那个状态对应的哈希值或 HEAD@{n} 引用。例如，如果你想回到执行 reset HEAD~1 (对应 HEAD@{1}) 之前的提交 (HEAD@{0}，也就是 e77c413)，可以使用 git reset --hard。
   bash
# 假设你想回到 HEAD@{0} 时的状态
git reset --hard HEAD@{0}
# 或者使用哈希值
git reset --hard e77c413
   执行此命令后，你的 HEAD 和当前分支就会被强制移动到 e77c413 这个提交，工作目录和暂存区也会被重置到那个状态。你就成功“撤销”了之前的 reset 操作。

注意: reflog 只保存在本地仓库，不会随着 git push 或 git fetch 传输。并且，旧的 reflog 条目会根据 Git 的配置被自动清理，所以 reflog 不是无限期有效的。但对于刚发生的操作失误，reflog 几乎总是能帮你找回丢失的内容。

6. 总结与最佳实践

Git 提供了多种撤销 Commit 的方法，每种方法都有其适用场景和潜在影响。正确选择和使用这些命令是高效、安全使用 Git 的关键。

• 修改最新的本地提交 (尚未推送):

  • 修改信息/添加漏掉的文件：git commit --amend (最常用)
  • 撤销提交，保留修改在暂存区：git reset --soft HEAD~1
  • 撤销提交，保留修改在工作目录：git reset HEAD~1 (默认，即 --mixed)
  • 撤销提交并丢弃所有修改：git reset --hard HEAD~1 (谨慎使用!)

• 撤销历史本地提交 (尚未推送):

  • 丢弃某个历史提交或重组历史：git rebase -i <commit-before-target>，在编辑器中将 pick 改为 drop。(会改写历史!)

• 撤销已推送到共享仓库的提交:

  • 创建新的撤销提交：git revert <commit-hash> (推荐! 安全，不改写历史)
  • 撤销一系列已推送的提交：git revert <commit-hash>... 或 git revert -n <commit-hash>... 然后手动提交。

• 操作失误后的救命稻草:

  • 使用 git reflog 查看 HEAD 的历史轨迹，并通过 git reset --hard <reflog-entry> 恢复到之前的状态。

重要原则和警告:

1. 永远不要在共享分支上使用 git reset 或 git rebase -i 来修改或删除已经被推送到远程仓库的提交，除非你明白强制推送的风险并且已与团队达成一致。这会给其他协作者带来麻烦。
2. 在共享分支上撤销已推送的提交，请优先使用 git revert，它通过新增提交来抵消影响，对协作友好。
3. 使用 git reset --hard 命令时要极其小心，它会永久删除你工作目录和暂存区中的修改。在执行前，务必确认你不再需要那些修改。
4. 学会使用 git status 和 git log 在执行撤销操作前检查当前状态和提交历史，确保你理解将要发生什么。
5. 理解工作目录、暂存区和提交历史之间的关系 对于理解 git reset 不同模式的行为至关重要。
6. 勤快地进行小而有意义的提交，这样即使需要撤销，影响范围也比较小，更容易处理。
7. git reflog 是你的安全网，记不住命令或搞砸了？先看看 reflog！

掌握这些 Git 撤销提交的技巧，能让你在代码版本控制中更加游刃有余，无论是修正个人的小失误，还是处理团队协作中的复杂情况，都能找到合适的解决方案。 Git 的强大在于它的灵活性，而理解这些灵活性背后的原理，是你成为 Git 高手的必经之路。

希望这篇详细的指南能帮助你更好地理解和使用 Git 的撤销 Commit 功能！

---