Git撤回已Push的代码的方法大全

面试官问：Git 如何撤回已 Push 的代码？如果被问到，你能立刻给出答案吗？

在日常开发中，Git 几乎是每时每刻都在用的版本控制工具。但人总有手滑的时候——比如不小心把错误的代码 push 到了远程仓库，或者想回退到某个历史版本重新开始写。还有一种更常见的场景：你写了一个自认为很棒的优化方案，顺手 push 上了线，结果紧接着来了个紧急需求，而那个优化方案还没经过充分测试，不敢直接上线。为了承接新需求，只能先把刚 push 上去的优化方案撤下来。

假设当前分支的状态如下图所示，我们希望本地和远程仓库都恢复到 help文档提交 那个节点。

1. 基础的手动操作（比较笨，不推荐）

这个方法虽然不推荐，但如果你对 Git 不太熟悉，它可能是最容易理解的方式。前提是错误代码不多：找到你想要恢复的那个 commit，和当前 commit 做对比，然后手动删除差异代码。具体操作很简单，按住 Ctrl 选中两个 commit，然后点击 Compare Versions，就能通过对比把不需要的代码删掉。

在代码很简单的时候，这招确实挺管用。甚至删完后再 Compare 一下最新 commit 和目标 commit，能确保代码完全一致。但一旦代码复杂起来——尤其是涉及繁杂的配置文件——手动对比就成了噩梦，只能一遍又一遍地反复 Compare Version。显然，这种操作太笨拙了。好在 Git 提供了一套更优雅的流程。

接下来介绍的几种方法，才是真正值得掌握的。

2. git Revert Commit（推荐）

还是那个场景：第三次提交了错误代码，并且已经 push 到远程分支。想要撤回这部分代码，只需要在错误提交记录上右键，选择 Revert 即可。

Git 会自动生成一个 Revert 记录，可以看到它已经把第三次错误提交的代码回退了——本质上就是 Git 帮你手动做了一次逆向操作。接下来，只要把这次改动 push 到远程，回退就完成了。

Revert 相当于自动帮你做版本回退，并且会在历史中留下一次明确的改动记录，非常安全。这也是很多团队推荐的做法。 但它的一个小缺点在于：一次只能回退一个 commit。如果你需要撤回几十次甚至上百次的提交，一个个点过去不仅费时，还会留下大量 Revert 记录，在那些情况下就显得不那么优雅了。

3. 增加新分支（推荐撤回较多情况下使用）

如果真的需要回退到上百次提交之前的版本，最简单的办法是直接新建一个分支。在想要回到的那个 commit 上右键，点击 New Branch。

新建分支只增加了一个引用，既保留了原来分支的所有历史，又能安全地在目标版本上继续开发，同时不会产生乱七八糟的回退记录。不过，这个操作也要慎用——分支管理本来就是一门学问，分支建多了，管理成本反而会上升。

4. Reset Current Branch 到你想要恢复的commit记录（不太安全，慎用）

此时会弹出四个选项，这里以 Hard 为例。其他选项的含义仅供参考，因为实际使用中很少用到全部模式。

1. Soft：你之前写的代码不会改变，之前暂存过的文件依然在暂存区。
2. Mixed：你之前写的代码不会改变，但之前暂存过的文件不再暂存。
3. Hard：文件恢复到所选提交的状态，任何更改都会丢失。特别注意：如果你已经提交了，然后又在本地的未提交状态下改动了代码，选择 Hard 后，不但提交的内容会丢失，本地未提交的改动也会全部丢失。
4. Keep：文件恢复到所选提交的状态，但本地未提交的更改会保留。也就是说，已经提交的内容会丢失，但你在提交之后又修改且未提交的内容不会丢失。

选择 Hard 之后，本地仓库中错误提交的 commit 就被干掉了。但远程仓库依然是原来的样子，需要把当前状态同步上去——也就是把删除那几个 commit 的操作 push 到远程。注意，此时没有新的 commit 需要提交，所以必须使用 Force Push（强制推送）。

需要特别提醒的是：对于一些被保护的分支（比如 master），这种操作是不允许的，需要先检查仓库配置。这里示例用的不是 master 分支，所以没有保护限制。

可以看到，远程仓库中最新的 commit 只剩下了 help文档，之前那三个错误提交已经彻底消失。