git rebase 和 git merger

& git merge

　　在上图中，每一个绿框均代表一个commit。除了c1，每一个commit都有一条有向边指向它在当前branch当中的上一个commit。

　　图中的项目，在c2之后就开了另外一个branch，名为experiment。在此之后，master下的修改被放到c4 commit中，experiment下的修改被放到c3 commit中。

 

`　　 如果我们使用merge合并两个分支

　　　　1 $ git checkout master
　　　　2 $ git merge experiment

                             

　　我们看到，merge所做的事情实际上是：

1. 1. 首先找到master和experiment中最新的commit的最近公共祖先，在这里就是c4和c3的最近公共祖先c2。
   2. 将experiment分支上在c2以后的所有commit合并成一个commit，并与master合并
   3. 如有合并冲突（两个分支修改了同一个文件），首先人工去除重复。
   4. 在master上产生合并后的新commit

 & git rebase

　　rebase所做的事情也是合并两个分支，但是它的方式略有不同。基于上例描述，rebase的工作流程是

1. 1. 首先找到master和experiment中最新的commit的最近公共祖先，在这里就是c4和c3的最近公共祖先c2。
   2. 将experiment分支上在c2以后的所有commit*全部移动到*master分支的最新commit之后，在这里就是把c3移动到c4以后。

                                                            

　　由于git的每一个commit都只存储相对上一个commit的变化（或者说是差值，delta）。我们通过移动c3到master，代表着在master上进行c3相应的修改。为了达成这一点，只需在experiment分支上rebase master

　　　　1 $ git checkout experiment
　　　　2 $ git rebase master

 

　　需要注意的是，rebase并不是直接将c3移动到master上，而是创建一个副本。我们可以通过实际操作发现这一点。在rebase前后，c3的hash code是不一样的。

　　rebase前的commit log是

　　　　* 1b4c6d6 (master) <- c4
　　　　| * 66c417b (experiment) <- c3
　　　　|/  
　　　　*   972628d

　　rebase后的commit log是

　　　　* d9eeb1a - (experiment) <- c3'
　　　　* 1b4c6d6 - (master) <- c4
　　　　* 972628d

　　可以发现c3的hash code从66c417b变到了d9eeb1a。

　　在这之后，我们只需要在master上进行一次前向合并(fast-forward merge)

　　　　$ git checkout master
　　　　$ git merge experiment

 

                                                              

　　rebase之后的commit log呈线性，更加清晰。此时如果experiment分支不再被需要，我们可以删除它。

　　　　$ git branch -d experiment

  & git rebase 使用

 　　永远不要rebase一个已经分享的分支（到非remote分支，比如rebase到master,develop,release分支上），也就是说永远不要rebase一个已经在中央库中存在的分支.只能rebase你自己使用的私有分支.

　　在执行git rebase之前，总是多问问你自己：“有没有其他人也需要这个分支来工作？”，如果答案是yes，那么你就需要思考必须使用一种非破坏性的方式来完成rebase一样的工作（就是需要合入别人的

工作成果），比如使用git revert命令。否则，如果这个branch没有别人来使用，那么很好，你可以非常安全地随心所欲地re-write history（注意rebase往往会重写历史，所有已经存在的commits虽然内容没

有改变，但是commit本身的hash都会改变!!!）