用git rebase解决分支合并问题

git是一个版本控制工具，因为其强大的分支模型，被很多公司使用。

这篇短文是来解决我们工作流中遇到的一个问题，就是一个命令，可以直接看文章结尾。

下面是我们的工作流：

1. 在dev分支上开发功能

# co 代表 checkout
git co master && git co -b dev_branch

2. 有高优先级的需求切换到新分支进行工作，例如bugfix分支

git co master && git co -b bugfix_branch

3. 修改上线后回到dev分支继续工作

git co dev_branch

正常情况下这个工作流没有问题，上线的时候我们把分支名提供给op，他们合并master之后进行部署即可。

细心的读者可能注意到，上面工作流的前两步都先做了git co master，也即所有的分支都是基于master的。

然而，在开发过程中很容易忘了这一点，经常会在dev_branch上直接创建bugfix分支，导致bugfix分支带上还不能上线的dev分支的代码，引发问题。而发现这个问题通常需要执行git diff master，如果这个步骤忘了，同时又没有其他人给review，那就很危险了。

常在河边走哪有不湿鞋，昨天晚上像修复个bug，上线之前diff了下master，很尴尬的发现带上了其他开发分支的代码。所以先查看了reflog（下面为演示），确认分支的来源：

git reflog --date=local | grep dev_branch

输出如下：

2649155 HEAD@{Sat Apr 27 07:07:51 2019}: checkout: moving from dev_branch to bugfix_branch
2649155 HEAD@{Sat Apr 27 07:07:26 2019}: checkout: moving from master to dev_branch

根据reflog的输出，能断定bugfix_branch分支的来源是dev_branch。

以前没遇到过这种情况，有点懵。仔细想了下，git文档上好像有一章讲了rebase，有个例子涉及到三个分支的合并。

赶紧翻了下手册，手册上的例子与我们的情况基本一致，所以执行了这个命令就解决了。

git rebase --onto master dev_branch bugfix_branch

这个命令做的事是这样的：

1. 首先取出bugfix分支，并找到它在dev_branch(基底分支)和bugfix分支共同祖先之后的修改。

2. 然后在master上重放，改变bugfix分支的文件内容和提交历史。

执行完这个命令后，bugfix_branch中的dev分支的内容就没有了，可以通过diff master或git log来查看。

这时候可以上线bugfix分支了，然后再切换到dev分支继续之前的工作。

最后，这边文章主要是讲了rebase的一个有趣的应用，git学问很多，强烈推荐这本git官方文档，翻译的很好。

参考链接：变基

（完）