git rebase 与 git merge

最近新换了工作，原来公司代码合并一直使用merge，新公司要求使用rebase，所以来研究一下他们的区别

首先盗2张图

现在在mywork分支，吧origin分支的代码合并merge过来，C7其实是根据C4，C6以及他们的共同祖先C2三个状态（也可以叫快照）生成的，

• 优点：可以保存真实的合并状态以及分支路径，过程清晰
• 缺点：会生成一个新的提交，因为不同分支都存在，会显得有些混乱

人数相对少一些的时候还是可以的，虽然有些乱还是可以看清，如果几十个人的话就麻烦，可以想想会什么样

当你在mywork分支并指向C6，origin分支产生了新的提交，
执行命令
git fetch origin
git rebase origin
就会得到上图的结果，rebase命令会把你的"mywork"分支里的每个提交(commit)取消掉，并且把它们临时 保存为补丁(patch)(这些补丁放到".git/rebase"目录中),然后把"mywork"分支更新 为最新的"origin"分支，最后把保存的这些补丁应用到"mywork"分支上。
然后C5，C6节点就没用了，以后也看不到了

• 优点：提交流程是单线的，看着更加清晰，不会产生新的提交（在没有冲突的情况下）
• 缺点：会丢失真实的分支合并过程，提交的时间点会发生变化（C5’, C6’的提交时间会跟真实的不一致）

在项目人员较多的情况下体检这种方法，看着清晰，不会出现一大堆merge提交

rebaese 解决冲突

在rebase的过程中，也许会出现冲突(conflict). 在这种情况，Git会停止rebase并会让你去解决 冲突；在解决完冲突后，用"git-add"命令去更新这些内容的索引(index), 然后，你无需执行 git-commit,只要执行:
$ git rebase --continue
这样git会继续应用(apply)余下的补丁。
在任何时候，你可以用–abort参数来终止rebase的行动，并且"mywork" 分支会回到rebase开始前的状态。
$ git rebase --abort