背景

最近我们组几个同事都投入到了一个新项目，互相之间的功能耦合比较紧密，因此，是打算从master上新拉一个分支，可以理解为我们几个人的开发分支，以develop代替。

一开始，我们是打算像svn那样用的，几个人就把这个新分支develop当做唯一的主干分支，几个人互相快速提交/拉取，回到了用svn的快乐日子。

不过，大家用svn也知道，经常呢，我们为了保证代码不丢，会经常性地往分支提交，即使某个功能写了一半，一个功能，n次commit记录，且和同事的commit交错在一起；另外，我们提交的代码，有时候会导致同事那里跑不起来。

简而言之，就是commit有点碎；另外，可能阻塞其他同事。

我们组长提了另外一种思路，就是，每个人基于这个开发分支develop，再自己单独拉取一个分支出来，如develop-zhangsan，develop-lisi。每个人在自己的单独的分支上开发，开发了一个较为完整的功能后，再提一个pull request给develop，此时，可以对这个较完整的功能做代码review，review通过后，即合并到develop分支。但此时，怎么才是最佳实践呢，且能保证开发分支develop的提交历史成为优雅的一条线呢？

这里假设有张三、李四两个人，基于gitlab、github、gitee等进行开发，最终，主要有以下几个分支:

远程	本地
origin/master	master
origin/develop	develop
origin/develop-zhangsan	develop-zhangsan
origin/develop-lisi	develop-lisi

实战环境准备

我这边已经准备好了实战案例，已经把上面的几个分支都拉好了。

https://gitee.com/ckl111/git-rebase-test

假设我先在远程，把这几个分支先建好，我是在gitee操作的。

目前，zhangsan、lisi分支，是基于develop拉出来的，所以最新提交都是一样的。

模拟张三开发

大家看上图，张三来了一顿操作，切到了自己的分支，改了点东西，做了一次提交，不过提交还没推送到远端自己的分支。

模拟李四开发

修改、推送

李四也是个猛人啊，上来一顿cv，commit、push一气呵成。

远端状态

此时，可以看到，远端分支里，只有lisi这娃儿的分支状态有变化。此时，按照标准流程，李四需要在远程发起一个到develop的pull request。

发起pr

此时，是可以查看这次pr的内容，包括提交内容，文件修改差异。具体每个平台不一样，但是功能应该类似。

此时，假设经过代码review，认为没有问题，那么可以合并到develop去了。

合并后，develop的情况

可以看到，除了把lisi分支的commit拿过来了，还加了个表示本次合并的commit。

ok，李四的工作，第一阶段就算结束了。

模拟张三拉取李四代码

张三一看，李四这小伙子太快了，cv666。假设张三就依赖李四代码，此时，应该要把李四代码拉下来。

其实，这里有个操作上的问题，当前张三在自己的分支上，他现在需要做的是：拉取develop代码最新代码，然后将develop的代码合到自己这里来。

这个步骤的话，其实有些工具做得比较好，我用的intelj idea就有相关功能。这一步如果工具不趁手的话，非常要命。因为我们可能开发到一半，要去切换到其他分支，结果本分支有代码没提交，还得先提交或者stash，切过去到develop，pull最新代码。然后再切回来自己分支。

很累人。

这块回头我讲讲idea里面的实战操作，其他ide工具大家可以自行探索。

这次先只介绍命令行版本，我先用笨办法，切过去，pull，再切回来的方式吧。

模拟张三合并/rebase李四代码

要保证develop的commit保持线性，这里有个重点，我们要以rebase的方式去合并develop的代码，而不是merge的方式。

rebase呢，这里简单说下，

这里就是rebase的大体流程图，其实，我刚有个想法，最近拿起了以前的电视剧，新三国。里面吕布不就换了几位义父吗，这里的rebase，换的也是parent啊，感觉rebase也是相当神似。

当然了，忘了一点，进行rebase那些的commit，hashcode会发生变化，和以前不一样了。

我们这边实际操作，看看效果：

这里主要几个操作，

1 git rebase develop -------因为和lisi改了同一行，需要解决冲突
2 我这边习惯用小乌龟git，解决冲突
3 git add .
4 git rebase --continue

形象一点，也就是前面那个图，不过新的rebase后的commit的hash变了

模拟张三push代码到远端，远端发起pull request

push

pull req

远端develop log查看

可以看看，远程的develop分支，log是非常好看的。

第二轮开始

可以看到，第一轮已经差不多结束了，张三李四各提交了一次。假设现在轮到李四了，李四发现张三有push代码，就准备拉下来，就像之前的张三一样。

李四切换到develop，拉取最新develop代码，并rebase

然后，我们基于develop，进行rebase（也就是，以develop为base）。本来为了模拟效果，是应该先本地搞点提交，再rebase的，我搞忘了。不过不重要，过程和前面张三差不多。

李四修改代码、commit、push

李四远端发起pull request

检查远程develop分支的commit 记录

依然是漂亮的commit记录。

张三在此期间，已经做了修改、commit、push

张三这期间，暂时不依赖李四代码，就自己commit、push了（为啥push，怕代码丢嘛，多个备份）

张三切换到develop、拉取最新develop、rebase

张三此时终于准备合并李四的代码。

省略了张三这次解决了冲突的过程，我依然用了小乌龟。

张三此时的log情况

张三，由于rebase，导致自己本地之前的那次commit，被rebase了。rebase后，hashcode也变了。

此时，张三的本地分支，和张三远程分支之间，出现了分叉。

张三rebase后，面临分叉，强行push，覆盖远程分支

强制push后，张三远程分支的log

张三远程发起pull request

远程develop分支log，线性日志

总结

两轮实战结束。大家学会了没？

2点要点：

1、总是rebase的方式去合并develop分支

2、rebase的时候，就是会面临分叉的情况，此时强制push远程分支，让远程分支的log和本地一致。

标签：git,develop,迭代,rebase,李四,commit,代码,分支
来源： https://www.cnblogs.com/grey-wolf/p/16069910.html