git学习五（分支的衍合rebase）

http://git-scm.com/book/zh/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%9A%84%E8%A1%8D%E5%90%88

$ git checkout experiment

$ git rebase master

它的原理是回到两个分支最近的共同祖先，根据当前分支（也就是要进行衍合的分支 experiment）

后续的历次提交对象（这里只有一个 C3），生成一系列文件补丁，

然后以基底分支（也就是主干分支 master）最后一个提交对象（C4）为新的出发点，

逐个应用之前准备好的补丁文件，最后会生成一个新的合并提交对象（C3'），

从而改写 experiment 的提交历史，使它成为 master 分支的直接下游

1） rebase应用场景

一般我们使用衍合的目的，是想要得到一个能在远程分支上干净应用的补丁 — 比如某些项目你不是维护者，

但想帮点忙的话，最好用衍合：先在自己的一个分支里进行开发，当准备向主项目提交补丁的时候，

根据最新的 origin/master 进行一次衍合操作然后再提交，这样维护者就不需要做任何整合工作

（译注：实际上是把解决分支补丁同最新主干代码之间冲突的责任，化转为由提交补丁的人来解决。），

只需根据你提供的仓库地址作一次快进合并即git merge，或者直接采纳你提交的补丁。

2）git rebase [主分支] [特性分支] 

命令会先取出特性分支 server，然后在主分支 master 上重演：

git rebase master server

3） 执行准则

一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。

在进行衍合的时候，实际上抛弃了一些现存的提交对象而创造了一些类似但不同的新的提交对象。

如果你把原来分支中的提交对象发布出去，并且其他人更新下载后在其基础上开展工作，

而稍后你又用 git rebase 抛弃这些提交对象，把新的重演后的提交对象发布出去的话，

你的合作者就不得不重新合并他们的工作，这样当你再次从他们那里获取内容时，提交历史就会变得一团糟。

如果把衍合当成一种在推送之前清理提交历史的手段，而且仅仅衍合那些尚未公开的提交对象，就没问题。

如果衍合那些已经公开的提交对象，并且已经有人基于这些提交对象开展了后续开发工作的话，

就会出现叫人沮丧的麻烦。