背景
最近我们组几个同事都投入到了一个新项目，互相之间的功能耦合比较紧密，因此，是打算从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和本地一致。