Git rebase和merge的表现

 前边讲过git的一大优势就是分支管理，分支管理离不开合并，前边已经讲过了merge的合并以及冲突解决，今天咱们就来讲讲rebase。

先来看看merge合并的过程：

本地仓库有个develop分支，我以develop分支为源，新建一个fromdevelop分支（分支名取名根据自己实际情况，我是为了方便大家区分），然后我这两个分支各自修改并commit。如下develop分支commit两次修改

zxdeMacBook-PRo:hswallpager zs$ git logcommit 35a4231eb23a50729a4cc2ebe80e207c39710506Author: zhangshun <hbzhangshun@126.com>Date:   Mon Feb 27 10:03:35 2017 +0800    develop branch second commitcommit 9506e73ca5a0223e7cc5af2e5ce9d702b0c696d8Author: zhangshun <hbzhangshun@126.com>Date:   Mon Feb 27 10:02:38 2017 +0800    develop branch first commit如下是fromdevelop分支两次修改：
zxdeMacBook-Pro:hswallpager zs$ git logcommit 6deb95d875165a57a512ddc8229e16db30b583abAuthor: zhangshun <hbzhangshun@126.com>Date:   Mon Feb 27 10:15:41 2017 +0800    fromdevelop branch second commitcommit e831462e2c8e0ffa6803aba7e9de237c129de8bcAuthor: zhangshun <hbzhangshun@126.com>Date:   Mon Feb 27 10:13:05 2017 +0800    fromdevelop branch first commit
然后我们使用merge合并到develop分支：
zxdeMacBook-Pro:hswallpager zs$ git checkout developSwitched to branch 'develop'zxdeMacBook-Pro:hswallpager zs$ git merge fromdevelopAuto-merging app/src/main/java/Activity.javaCONFLICT (content): Merge conflict in app/src/main/java/Activity.javaAutomatic merge failed; fix conflicts and then commit the result.zxdeMacBook-Pro:hswallpager zs$ git add .zxdeMacBook-Pro:hswallpager zs$ git commit -m "merge 合并方式"[develop 59a35b2] merge 合并方式zxdeMacBook-Pro:hswallpager zs$ git log --graph --pretty=oneline*   59a35b2dd146cbf1964e36879672912fd1a57fc0 merge 合并方式|/  | * 6deb95d875165a57a512ddc8229e16db30b583ab fromdevelop branch second commit| * e831462e2c8e0ffa6803aba7e9de237c129de8bc fromdevelop branch first commit* | 35a4231eb23a50729a4cc2ebe80e207c39710506 develop branch second commit* | 9506e73ca5a0223e7cc5af2e5ce9d702b0c696d8 develop branch first commit|/  
注意看上图的合并后的分支结构图，因为我们使用merge合并，我们fromdevelop的所有commit都已经加到了mster的分支log里。然后我们修改最后继续回到mster主线，产生冲突，然后解决冲突后生成一个新的commit记录及message为"merge 合并方式"。
接下来我们看看reabse合并方式：
同样我以develop为源，创建develop-02分支，同样每个都增加两个commit，修改后查看分支流图：
zxdeMacBook-Pro:hswallpager zs$ git log --graph --pretty=oneline* 1976db2eafe93ca1e374cdd87ee708220f42a991 develop branch second  commit rebase* b5dcd26e42c715831ca24810d3080fd25dd92346 develop branch first commit rebase* 4ebdf8f35ec97c73bb7050530b7093e0c16a0280 fromdevelop-02 branch second commit* 6d4f50ae6c73ee4603052ca0cf334c069f34c1c1 fromdevelop-02 branch first commit*   59a35b2dd146cbf1964e36879672912fd1a57fc0 merge 合并方式|/  | * 6deb95d875165a57a512ddc8229e16db30b583ab fromdevelop branch second commit| * e831462e2c8e0ffa6803aba7e9de237c129de8bc fromdevelop branch first commit* | 35a4231eb23a50729a4cc2ebe80e207c39710506 develop branch second commit* | 9506e73ca5a0223e7cc5af2e5ce9d702b0c696d8 develop branch first commit|/  
重点看上边最新的四条commit，是否已经看出区别，此时合并的流是相当干净的commit history，是线性的，而且修改冲突后，执行git add和git rebase --continue,不会有新的commit。
rebase和merge的差别主要是：
rebase更清晰，因为commit历史是线性的，但commit不一定按日期先后排，而是当前分支的commit总在后面。也就是上图的develop分支的commit在最后边显示。merge之后commit历史变得比较复杂，并且一定程度上反映了各个分支的信息，而且 commit按日期排序的。上述讲了git merge和git rebase在commit history上的表现。另外在解决冲突上的表现也略有不同，在rebase的过程中，也会遇到conflict，这时候，git会停止rebase，并提示先解决冲突，让后git add 到索引区，这时候跟merge不同，你无需在执行git commit而是执行git rebase  --continue,这样的话，git会继续apply余下的补丁。如果放弃rebase，只需要执行git rebase --abort。