Git系列篇二:新参数 --rebase-merges 让 git rebase 完美变基更强大

2,524 阅读3分钟

前言

之前曾经分享过灵活运用 git rebase,让团队协作下的提交记录整洁些,使用 --preserve-merges 参数(简写-p),可以像剪刀一样咔嚓一下将整段分支历史基于最新 master 分支进行变基迁移,效果非常的赞。

然而,这是理想情况下的操作,比如你的分支是基于 master 的上一个节点进行开发且期间并没有和 master 进行互动,那么,就可以使用git rebase master -p这个命令进行完美变基。

问题来了

但是!我们常常碰到这样一个情况:有很多个特性分支基于同一个master节点同时开发,然后大家合并进test分支一起开始测试,这时候,其中一个特性分支需要先上线它先合进了master分支。

于是仍在测试中的其他分支表示这个场景非常尴尬,说好的好兄弟共同进退呢。。。

)

改族谱清理门户

事情已经发生了,test 分支表示不再认这个兄弟了,更不能忍受自己的提交历史里出现这段黑历史,于是祭出大招git rebase -i,要清理自己的提交历史。

历史是任人打扮的小姑娘

git rebase --interactive

简单的说,--interactive参数(简写-i)可以用来编辑提交历史,然而在2.17.0版本之前,这个命令配合--preserve-merges并不能做到完美的历史编辑,甚至在 git --help的文档里都直接的指出这个 bug 一直存在,而且存在了很多年-。-

新参数 --rebase-merges

就如PHP跳过了6直接来个7一样,-i -p的 bug 困扰了大家很多年,忍无可忍一忍再忍,总算一个新的参数--rebase-merges(简写-r)从2.18.0版本出现了,这个参数可以实现若干强大功能暂且不说我也不熟,总之,我们想要重改历史这件事现在可以做到了。

注意:此特性需要git版本2.18.0以上,最好是最新版本。

第一步:清理门户

在前文里,我们说过,要想完美的使用git rebase master -p来基于最新 master 分支进行变基,前提是两者之间不要出现互动交集。

如果出现了交集,比如提交历史里的某个特性分支先合并进 master上线了,那么,就要清理门户,移除当前测试分支里的黑历史。

使用命令:git rebase -i -r c82269475b9....1addb9f3f6fd进行历史编辑。

此处的 c82269475b9....1addb9f3f6fd 为当前测试分支的根节点(通常是 master 分支的上一个节点)

还记得上文里,先跑的分支曾经三次合并进 test 分支么?在此处,注释掉这三次合并动作。

清理门户之后,test 分支的历史里就和最新 master 没有交集了,可以进行下一步完美变基。

第二步:完美变基

这步简单,可以参考前文,使用git rebase master -p来基于最新 master 分支进行变基即可。

后语

变基这件事吧,其实挺违背版本控制的理念的,然而对有洁癖的开发者来说,头可断血可流发型不能乱,所以在沟通良好的团队或个人开发过程中,变基用的好,也未尝不是一件妙事儿。

原文来自阿星的博客: wanyaxing.com/blog/201901…