用git rebase解决分支合并问题

2019-04-27, 948 Words, 2 Minutes

用git rebase解决分支合并问题

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

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

下面是我们的工作流:

  1. 在dev分支上开发功能
# co 代表 checkout
git co master && git co -b dev_branch
  1. 有高优先级的需求切换到新分支进行工作,例如bugfix分支
git co master && git co -b bugfix_branch
  1. 修改上线后回到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官方文档,翻译的很好。

参考链接:变基

(完)


Next:
Prev:

Toc