本文讲述了如何使用 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...
我的 github:https://github.com/sunmengyuan
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。