手滑 Push？别慌，先懂原则
在开发的 “江湖” 中，谁还没个手滑的时候呢？我就有过这样的经历，有一次在紧急修复一个小 bug 后，脑子一懵，没仔细检查就直接push到了主分支。结果代码一上去，才发现还有几行调试用的console.log没删。当时我这心啊，“咯噔” 一下，就像坐过山车突然来了个大俯冲，别提多紧张了！我赶忙在团队群里疯狂 “呼叫”，让大家先别拉取最新代码。相信很多小伙伴也有过类似的尴尬时刻，比如不小心提交了测试数据、错误的配置文件，甚至是包含敏感信息的代码。
这种时候，要是掌握了git撤回已push代码的技巧，那可就相当于握住了 “救命稻草”。但在开始学习具体方法之前，一定要先牢记一条 “黄金原则”：对于已经push到远程仓库，尤其是多人协作的分支（像main、develop这些核心分支），绝对不能用 “删除历史” 的方式来撤回代码！这是为什么呢？想象一下，团队里的小伙伴们都已经拉取了你推送的代码，正开开心心地基于这个版本继续开发。结果你这边一个 “暴力删除历史” 的操作，就像一颗炸弹扔进了原本平静的湖面，所有人的代码都会陷入冲突的 “漩涡”。到时候，大家就得一个个手动解决冲突，那工作量，简直比重新写代码还让人崩溃！所以，记住这句口诀：能 “修补历史” 就不 “删除历史”，能 “温和撤回” 就不 “暴力操作”。遵循这个原则，我们再去探索撤回代码的具体方法，就能避免很多不必要的麻烦啦。
场景一：刚 Push 就发现错误（无人拉取）
快速回退，强制覆盖
在开发过程中，有时我们会在刚push完代码后，就立刻发现了错误，而此时幸运的是还没有人拉取这些代码。这种情况就像是你刚把一封信投入邮箱，就想起里面有个错别字，好在邮递员还没把信送走。在git里，我们可以采用一种比较直接的方法来解决这个问题。
假设你在本地进行了一系列的代码修改和提交，然后push到了远程仓库。但紧接着就发现，最后一次提交的代码里有个低级错误，比如把变量名拼写错了。这时候，我们先查看提交历史，使用命令git log，它会展示出类似下面这样的信息：
commit 6f32c9e282d1822d71827712686979695932901e (HEAD -> main, origin/main)
Author: Your Name <your_email@example.com>
Date: Mon Aug 14 15:32:12 2023 +0800
Update some code, but with a mistake
commit 3b45d6e282d1822d71827712686979695932901d
Author: Your Name <your_email@example.com>
Date: Mon Aug 14 15:25:12 2023 +0800
Add a new feature
从这里可以看到，最新的一次提交就是那个包含错误的提交。接下来，我们要做的是在本地回退到上一个正确的版本。使用git reset命令，git reset --hard HEAD^，这里的--hard参数表示不仅会将HEAD指针移动到上一个提交，还会把工作区和暂存区的内容也恢复到上一个版本的状态。也就是说，最后一次提交的那些错误代码会被彻底丢弃，就像你从来没有写过它们一样。
最后，我们要把本地回退后的状态强制push到远程仓库，覆盖掉之前错误的提交。使用命令git push --force origin main，这里的--force参数就是关键，它会让git忽略掉常规的检查，直接用本地的版本去覆盖远程仓库的内容。不过要特别注意，这个--force参数是个 “双刃剑”，如果在多人协作的项目中，有人已经拉取了远程仓库的代码，你再使用--force推送，就会导致其他人的代码和你的产生冲突，所以一定要在确定没人拉取代码的情况下再使用。
场景二：撤回中间某次 Push（保留后续提交）
反向提交，和谐共处
在实际开发中，更常见的一种情况是，你在一段时间前进行了一次错误的push，之后又陆续进行了多次正确的提交。这就好比你写了一篇文章，中间有一段内容写错了，但后面又接着写了很多新的内容。如果直接把整篇文章删除重写，显然不太现实，我们需要一种更精准的 “修复” 方法。
假设你在一个电商项目中负责商品详情页的开发。你在三天前提交了一个版本（我们记为版本 A），在这个版本中，你不小心把商品价格的显示逻辑写错了，导致价格显示异常。而在这之后，你又陆续提交了两个版本（版本 B 和版本 C），分别修复了页面的一些样式问题和添加了商品评论功能。现在你发现了版本 A 中的价格显示错误，需要撤回这个错误的提交，但同时要保留版本 B 和版本 C 的修改。
这时候，我们就可以使用git revert命令来生成一个反向提交，它就像是一个 “修复补丁”，能够抵消错误提交的影响，同时又不会破坏其他正常的提交。具体操作步骤如下：
首先，查看提交历史，找到需要撤回的错误提交的版本号。使用命令git log --oneline，它会以简洁的格式展示提交历史，类似于下面这样：
c7d8e9f (HEAD -> main) 提交C：添加商品评论功能
b0c1d2e 提交B：修复页面样式问题
a1b2c3d 提交A：错误的商品价格显示逻辑，需要撤回
9876543 更早的提交：初始化商品详情页基本结构
从这里我们可以看到，需要撤回的错误提交的版本号是a1b2c3d。2. 然后，执行git revert命令，生成反向提交。输入git revert a1b2c3d，这里的a1b2c3d就是上一步找到的错误提交的版本号。执行这个命令后，Git 会自动计算出如何反向操作，以抵消错误提交的影响。例如，如果错误提交是添加了一段错误的代码，那么反向提交就会删除这段代码；如果是修改了某个文件，反向提交就会把这个文件恢复到修改前的状态。3. 接下来，Git 会自动打开默认的文本编辑器（比如 Vim、Nano 等，如果你安装了 VS Code 并且配置为 Git 的默认编辑器，也会打开 VS Code），要求你输入这次反向提交的说明。这一步非常重要，因为一个清晰准确的提交说明可以让团队成员明白为什么要进行这次撤回操作。你可以输入类似于 “Revert ' 提交 A：错误的商品价格显示逻辑 '，修复价格显示错误” 这样的内容，然后保存并退出编辑器。4. 最后，将这个反向提交push到远程仓库。执行git push origin main，这里的main是你的分支名，如果你的项目使用的是其他分支名，需要相应地替换。因为这是一次正常的新增提交，所以不需要使用--force参数，这样就能保证远程仓库和本地仓库的状态一致，而且不会影响其他团队成员已经拉取的代码。
使用git revert命令生成反向提交有很多好处。首先，它不会删除任何历史提交记录，所有的操作都清晰可追溯，这对于团队协作和代码审查非常重要。其次，如果后续发现撤回操作有误，还可以再次使用git revert命令，对这个反向提交进行反向操作，就像 “负负得正” 一样，恢复原来的代码状态。所以，在多人协作的项目中，当需要撤回中间某次push时，git revert是一个非常安全、可靠的选择。
场景三：撤回已被他人修改的代码
分支处理，巧妙合并
当代码被他人基于错误提交进行修改后，情况就变得复杂起来。这就好比你画了一幅画，其中一部分画错了，而别人不知道，还在错误的部分上继续添加内容。在这种情况下，我们需要更加谨慎地处理，以避免影响他人的工作成果。
假设你在一个项目中负责前端页面的开发，你之前提交了一个版本（版本 A），其中有个函数的逻辑写错了。在你没有发现这个错误之前，你的同事基于版本 A 进行了新功能的开发，提交了版本 B 和版本 C，分别添加了新的页面元素和优化了页面交互。现在你发现了版本 A 中的错误，需要撤回这个错误提交，但又不能丢失同事在版本 B 和版本 C 中的修改。
为了解决这个问题，我们可以采用以下步骤：
创建临时分支：基于当前的主分支创建一个临时分支，专门用于处理这个错误的撤回。使用命令git checkout -b fix-bug-branch，这条命令会创建一个名为fix-bug-branch的临时分支，并自动切换到这个分支上。这个临时分支就像是一个 “隔离区”，我们可以在里面放心地处理错误，而不会影响到主分支和其他同事的工作。
“摘出” 错误提交：使用git cherry-pick命令，把错误提交（版本 A）“摘出来” 放到临时分支上。执行git cherry-pick -n a1b2c3d，这里的a1b2c3d是错误提交的版本号，-n参数表示只应用修改，不提交。这样，错误提交的代码就被复制到了临时分支上，我们可以在这个分支上对其进行修改，而不会影响到其他正常的提交。
修改错误代码并提交：在临时分支中，手动修改错误的代码。比如，将错误的函数逻辑改正，删除不必要的测试代码等。修改完成后，使用git add .命令将修改添加到暂存区，然后执行git commit -m "修复提交A中的XX问题"，这里的XX问题要具体描述错误的内容和修复的情况，方便后续查看和理解。
合并临时分支回主分支：回到主分支，使用git checkout main。然后将临时分支合并回主分支，使用命令git merge --no-ff fix-bug-branch -m "合并修复后的代码"，这里的--no-ff参数非常重要，它会禁用 “快进” 模式，强制生成一个新的合并提交。这样做的好处是，在分支历史中可以清晰地看到合并的记录，方便日后追溯和审查。
删除临时分支：最后，如果你确认临时分支已经不再需要，可以使用git branch -d fix-bug-branch命令将其删除。这个临时分支就像是一个完成使命的 “临时工”，任务完成后就可以让它 “下岗” 了。
在处理这种情况时，与团队成员的沟通至关重要。在开始撤回操作之前，最好先在团队群里告知大家，让他们暂停基于错误代码的开发，等你修复后再同步最新代码。这样可以大大减少代码冲突的概率，提高开发效率。同时，在提交说明中要详细描述撤回的原因和修改的内容，方便团队成员理解和审查。
特殊场景：撤回敏感信息
紧急操作，消除痕迹
在软件开发过程中，最让人头皮发麻的情况莫过于不小心把敏感信息，如数据库密码、API 密钥等，push到了远程仓库。尤其是在像 GitHub 这样的公共仓库，一旦这些敏感信息泄露，后果不堪设想，可能会导致数据泄露、安全漏洞被利用等严重问题。这就好比你把自家保险柜的密码写在纸条上，不小心弄丢了，那种焦急和懊悔的心情，相信经历过的人都懂。
如果真的不幸发生了这种情况，我们必须立刻采取行动，尽可能地消除敏感信息的痕迹。具体来说，可以按照以下步骤进行操作：
立即修改密码或密钥：一旦发现敏感信息被push，第一时间修改相关的密码或密钥，防止他人利用这些信息进行恶意操作。这就像是发现保险柜密码泄露后，赶紧更换新密码，把风险降到最低。
使用工具彻底删除敏感信息提交记录：
BFG Repo - Cleaner 工具：这是一个专门用于清理 Git 仓库中敏感信息的工具，它比git filter - branch更简单、更快速。首先，你需要安装 BFG Repo - Cleaner 工具。如果你的系统安装了 Homebrew（Mac 系统常用的包管理器），可以使用命令brew install bfg来安装；如果没有安装 Homebrew，也可以从 BFG 的下载.jar文件。安装完成后，假设你的项目仓库地址为github.com/username/myrepo，先克隆一个裸存储库，使用命令git clone --mirror https://github.com/username/myrepo.git，这会在当前目录下创建一个myrepo.git目录，这个目录是一个裸存储库，里面没有通常的工作目录文件。然后运行 BFG 来清除敏感信息，例如，如果你要删除mysecrets.txt这个包含敏感信息的文件，使用命令bfg --delete-files mysecrets.txt myrepo.git。最后，进入myrepo.git目录，执行git reflog expire --expire=now --all && git gc --prune=now --aggressive，这一步会清理存储库，删除所有旧提交，然后把清洗后的存储库推送回远端，使用命令git push --all。需要注意的是，这个操作会覆盖远端的 Git 历史，所以在推送之前，一定要确保其他人都已经拉取了最新的更改，否则可能会导致其他人的代码冲突。
git filter - repo 工具：这也是一个不错的选择，它是 Git 官方推荐的用于修改仓库历史的工具。首先，克隆仓库的裸版本，避免影响原仓库，使用命令git clone --mirror https://github.com/your/repo.git，然后进入克隆目录cd repo.git。如果你的系统没有安装git filter - repo，可以使用pip install git - filter - repo命令进行安装（前提是你的系统安装了 Python 和 pip）。安装完成后，使用git filter - repo --path path/to/sensitive/file --invert - paths命令来删除敏感文件，这里的path/to/sensitive/file是敏感文件的路径。最后，强制推送更新到远程仓库，使用命令git push origin --force --all，并且要通知所有协作者重新克隆仓库，以获取新的历史记录。
通知团队成员注意安全风险：在完成上述操作后，一定要及时通知团队成员，告知他们发生了敏感信息泄露的情况，提醒他们注意相关的安全风险，如避免使用旧的密码或密钥，检查是否有其他潜在的安全隐患等。同时，也可以借此机会加强团队的安全意识培训，制定更严格的代码提交规范，避免类似的情况再次发生。
总结回顾，安全第一
在git的使用过程中，撤回已push的代码是一项需要谨慎对待的操作。不同的场景需要采用不同的方法，我们一起回顾一下今天学到的主要内容：
如果是刚push就发现错误，且无人拉取代码，这种情况相对简单。我们可以使用git reset --hard HEAD^回退到上一个正确的版本，然后通过git push --force origin main强制覆盖远程仓库的错误提交。但要记住，--force参数是个 “雷区”，一定要确保没人拉取代码后再使用，不然就可能引发团队成员代码冲突的 “大爆炸”。
要是需要撤回中间某次push，同时保留后续提交，git revert命令就是我们的得力助手。通过找到错误提交的版本号，执行git revert <版本号>生成反向提交，再将其push到远程仓库。这样既能抵消错误提交的影响，又不会破坏其他正常的提交记录，就像给错误打了个 “补丁”，让代码继续健康 “运行”。
而当代码已被他人基于错误提交进行修改时，我们得采取更巧妙的方法。先创建一个临时分支，用git cherry - pick把错误提交 “摘” 到临时分支上进行修改，然后合并回主分支。这个过程就像是一场精密的手术，每一步都要小心翼翼，同时别忘了和团队成员及时沟通，避免大家在错误的道路上越走越远。
另外，对于不小心push了敏感信息这种极其危险的情况，我们要第一时间修改密码或密钥，然后利用BFG Repo - Cleaner或git filter - repo工具彻底删除敏感信息的提交记录，并及时通知团队成员注意安全风险。这就像是给项目穿上了一层 “防护服”，把安全隐患降到最低。
在多人协作的项目中，git操作就像一场团队舞蹈，每个人的动作都要协调一致。所以，在进行任何可能影响他人的操作之前，一定要三思而后行，多和团队成员沟通交流。同时，也要不断练习这些撤回代码的技巧，积累经验，这样在遇到问题时才能游刃有余地解决。希望大家在今后的开发过程中，都能熟练运用git，让代码管理变得轻松愉快！
