新参数 --rebase-merges 让 git rebase 完美变基更强大

前言

之前曾经分享过 灵活运用 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 分支进行变基即可。

后语

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