使用Git中的Merge与Rebase与开源项目同步代码

jopen 5年前

基于开源项目的开发有两种主要工作模式。模式1是在从开源项目中拉出一个分支,在这个分支中开发新feature,完成后合并到upstream中。适用于本身是开源项目的developer。模式2是从开源项目中拉出分支后独立发展,但定期从upstream拉更新(如重要版本升级时)。无论是哪种,都会面临本地分支与upstream同步代码的问题。为此,git主要提供了两种方式:一种是merge, 一种是rebase。下面通过例子简单过一下它们的基本流程。

假设开源项目的git地址为git://xxx.org/xxx/project。早先从它上面拉出代码,作为git repository放在在本地的代码管理服务器上(比如gerrit服务器)。而在本地的开发机上有本地服务器上该项目git的clone。这样,在本地开发机上执行git remote -v结果类似于:
local   ssh://jzj@gerrit3.company.com:xxxxx/xxx/project (fetch)
local   ssh://jzj@gerrit3.company.com:xxxxx/xxx/project (push)

首先将开源项目git加入remote源列表,名称暂定为upstream。
$ git remote add upstream git://xxx.org/xxx/project
再将新加源的信息同步下来:
$ git fetch
然后git remote -v结果就变成:
upstream       git://xxx.org/xxx/project (fetch)    
upstream       git://xxx.org/xxx/project (push)                    
local   ssh://jzj@gerrit3.company.com:xxxxx/xxx/project (fetch)
local   ssh://jzj@gerrit3.company.com:xxxxx/xxx/project (push)
现在当前git已经与两个源关联上了。

接下来从upstream源新建分支,称为upstream,它与开源项目git中的代码一致:
$ git checkout remotes/upstream/master -b upstream
假设其中git log为:
Commit 2 from branch upstream  2015/1/3
Commit 1 from branch upstream  2015/1/1

再从local源拉出分支,称为topic,它包含本地改动(比如新加feature):
$ git checkout remotes/local/master -b topic
当然,如果将来要提交到到gerrit服务器上,这儿用repo start topic .。假设其中log为:
Commit 1 from branch topic 2015/1/2

Merge方式是把branch A在branch B上没有的commit合并成一个commit,然后打在branch B上。如果要让topic分支同步upstream中的改动,执行下面命令:
$ git checkout topic 
$ git merge upstream
如果想让 upstream同步topic改动,把上面命令中分支名的位置换下就行。如果有冲突的话会让你解决(通过git diff查看冲突),解决完了以后git add + git commit(或git commit -a)。完成后在topic分支的git log里看到的log有类似下面的结果:
Merge branch 'upstream' into topic
Commit 2 from branch upstream 2015/1/3
Commit 1 from branch topic 2015/1/2
Commit 1 from branch upstream 2015/1/1
两个branch中的commit以时间顺序排列,最顶上这个commit代表了这次merge的bundle commit。把它git reset掉的话所有原upstream上同步的改动都会消失。

Rebase方式是把branch A在branch B上没有的commit挨个在branch B上再重新打一遍。通过git rebase的文档,可以看到如果是git rebase upstream topic的话相当于git checkout topic + git rebase upstream。即把topic分支上的commit以upstream的HEAD为base重新打一遍,重复的commit会自动忽略。因此,如果是前面提到的工作模式1的话就用git rebase topic upstream,工作模式2的话就用git rebase upstream topic。一般为了避免whitespace带来的错误,会加上--ignore-whitespace参数:
$ git rebase upstream topic --ignore-whitespace
更细粒度的rebase控制请参见-i参数。

在rebase过程中可能出现冲突,出现冲突时先用git diff看冲突情况。比如是a.c的话,解决冲突后执行:
$ git add a.c
然后执行下面命令继续欢快地rebase:
$ git rebase --continue

完成后topic分支的git log里是类似于这样的:
Commit 1 from branch topic 2015/1/2
Commit 2 from branch upstream 2015/1/3
Commit 1 from branch upstream 2015/1/1
可以看到,这里不是按时间顺序的。topic分支的commit在上面,而upstream的commit在下面。如果是git rebase topic upstream的话顺序就是相反的。最后,如果还需要让upstream分支也同步topic分支的代码。可以到upstream分支做一次fast- forward merge:
</div>
$ git checkout upstream
$ git merge topic
妥妥的。

同步完了之后,该git push就git push,该repo upload就repo upload,将同步的代码更新到本地的代码管理服务器上。

总结一下,从工作方式来说,merge与rebase最大的差别就是前者是把所有要打的commit作为一整个commit打到目标分支上,后者是一个个重新打(但注意打上去后<SHA1>不同了,也就是说,虽然内容相同,但此commit已经不是原来那个了)。从结果来看,merge后log中 commit是按时间顺序的,最近的一个commit记录了这次merge操作。rebase后log中不是按时间顺序的,而是一个分支的commit在另一个分支的commit之后。总得来说,rebase比merge更灵活,更强大。但它的缺点是会改写历史。因此,不要对public的分支做 rebase,否则你会冒着被同事砍死的风险(因为他可能基于改写前的历史做了改动)。基本原则是,当从远端同步代码到本地时,用rebase。当本地完成feature开发,同步回远端时用merge。
</div> 来自:http://blog.csdn.net/jinzhuojun/article/details/43988599