呆恋小喵

谈谈 Git 代码回滚

本文讲述了如何使用 git rebase -i 及 git cherry-pick 实现代码回滚。代码回滚属于高危操作,建议慎用!

下载示例源文件

为什么会写这样一篇文章?其实是有一段历史的:在一次迭代中并行开发着 n 个需求,到提测之时各需求的代码陆陆续续被合并到了测试分支。生活本来很平静,但两天后测试的头目说“我们组发生了点状况,本次迭代的需求在规定时间内无法测完,但老板又强制要求了上线时间,我们把优先级较低的需求的代码从测试分支抽出去吧!”。当时真是心中一万只 XXX 飘过…

我们来模拟一下上述场景:迭代中并行开发着 3 个需求 feature1、feature2、feature3,在各自的开发分支上相安无事(假定测试分支为 master)。

其中 feature2 与 feature3 需要修改同一文件,我们故意制造了一个冲突:

提测时间到了,feature1 的代码被合并到了测试分支:

在 feature1 修复了 1 个 bug 后,feature2 也提测了:

而后 feature3 也提测了,在合并 feature3 的代码时,刚刚制造的冲突爆发了:

我们需要解决冲突后再合并代码:

在 feature3 提测后,我们又修复了几个 bug:

当然,feature2 虽已提测但并未进入测试,bug 的修复均是针对 feature1 与 feature3 的。

此时,feature2 的测试无法正常进行,需要将代码从测试分支上抽出…

以防万一,先将 feature2 分支备份:

git checkout feature2
git checkout -b feature2-copy

我们来查看一下 feature2-copy 分支的提交记录:

git log

我们需要回滚最新的 3 个提交(因为 3 个 feature 的开发分支均是从第一个提交的时间点上切出的),当然现实中针对某需求的提交绝不止 3 个。若是将提交逐一 revert 那么工作量感人,我们何不将 n 个 commit 合并为一个 commit 然后一同 revert 呢?

使用 git rebase -i 来合并 commit,需要拼接回滚至的 commit 的 hashcode:

git rebase -i e08ddaf558b9ad84422db5e4b620dcab97623fde

而后出现如下对话框:

我们需要将最新 2 次提交的 command 更改为 s:

修改后保存并退出进入如下对话框:

我们需要修改最初一次提交的 commit message:

修改后保存并退出,再次查看 feature2-copy 分支的提交记录:

3 次提交被成功合并,可喜可贺!接下来我们需要 revert 被合并的提交:

git revert e544464c3de69adef5ca7556001abebaf40b218b

保存并退出,再次查看 feature2-copy 分支的提交记录:

此时天真的我认为将 feature2-copy 合并到测试分支即可成功抽去 feature2 的代码,其实不然。正确的做法是使用 git cherry-pick 将 feature2-copy 分支上 revert 提交合并到测试分支上:

git checkout master
git cherry-pick b309f7944d2422d8fe647dca61bda518b192628f

此时,feature2 的代码成功从测试分支上抽离。

最后为大家推荐一枚 Git 图形化客户端:GitUp


作者:呆恋小喵

我的后花园:https://sunmengyuan.github.io/garden/

我的 github:https://github.com/sunmengyuan

原文链接:https://sunmengyuan.github.io/garden/2017/06/15/git-revert.html