如何使用Git Rebase

咱们在平常开发中使用 Git 作分支合并的时候有两种方式：merge 和 rebase。merge 是最经常使用的，rebase 使用的没有 merge 这么多，那么 rebase 和 merge 有什么区别呢？何时使用 rebase？使用 rebase 的时候有什么注意事项呢？接下来我来介绍下这三个问题。

基础

首先咱们先了解下 merge 和 rebase 的运行机制有什么不一样。假设咱们有两个分支（master 和 feature）。feature 是基于 master 的 C1 节点创建的分支，而后开发人员分别在两个分支各自开发：

merge

如今咱们想要把 feature 分支开发的内容合并到 master，使用 merge 命令：

$ git checkout master
$ git merge feature

Git 会把 C2 和 C3 的内容合并一下产生一个新的修改 C4，把 C4 提交到 master 分支。那么 master 就有了全部最新的代码（红色是 master 分支线，蓝色是 feature 分支线）。

rebase

咱们回到仍是未合并以前的状态，看看使用 rebase 合并会有什么效果。使用 rebase 有两种用法，先看第一种：

$ git checkout master
$ git rebase feature

Git 把 C2 备份成 C2'，删除 C2，而后把 C2' 追加到 C3 后面，把 master 指向 C2'。看图上红线，成为了新的 master，这条线上一样有全部的最新代码，起到的做用也是合并了两个分支。那么和 merge 有什么区别呢？就是历史时间线的区别。merge 保留了你全部的操做记录，而 rebase 把提交的修改节点变成了线性的时间线。若是分支 merge 不少的话，时间线会错综复杂，这个时候 rebase 的好处就出现了，对人肉追溯比较友好。

咱们再看下合并两个分支 rebase 的第二种用法：

$ git checkout feature
$ git rebase master
$ git checkout master
$ git merge feature

前两条命令咱们先在 feature 上 rebase on master，产生的效果和第一种方法相似，只是把 feature 分支的改动追加到了 master 分支后面（红色是 master 分支线，蓝色是 feature 分支线）。

后两条命令是把 feature 分支 merge 到 master 分支。因为 Git 发现不须要合并代码，只须要移动头指针就能够了，因此快速移动（fast forward）头指针到最前面，master 分支这时就有全部最新代码，一样起到了合并分支的做用。

那么第一种和第二种有什么区别呢？直观的看就是时间线上 C2，C3 顺序的区别，对于咱们合并分支最终的意图是没有什么区别的。

注意点

若是你是一人开发，且只有本地仓库，那么上面 rebase 用哪一种问题都不会太大。可是若是你是多人协做且有远程仓库，那么区别就巨大了。由于你合并完分支以后还须要 push 到远程仓库供别人使用，当你使用第一种方法后，C2 被放到了 C3 后面，你本地的 master 时间线变成了 C1 - C3 - C2'，而远程仓库 master 的时间线是 C1 - C2。虽然 C2 和 C2' 是同样的，可是二者时间线历史彻底不同了，Git 认为你这是两个不同的分支，不容许你 push。这个时候只能用 $ git push --force 强迫提交，用本地的 master 覆盖远程仓库的 master。可是 master 分支别人还在用啊，他们也须要同步 master 分支。可是别人本地的 master 分支并不知道你 rebase 过了远程仓库的 master，因此当他们 pull master 的时候，变成了以下时间线：

其余人本地的 master 时间线上会出现两个 C2（C2 和 C2'），而后若是这人把上图的 master 再 push 到远程仓库，会带上上图全部的历史，多来几回之后整个仓库就没有办法看了。而第二种 rebase 的方法是把新的 commit 不断的追加到 master 后面，只要全部人在往 master 上合并代码的时候都遵循第二种方法，那么就不会产生极其混乱的时间线。

何时使用

按咱们上面看到的，在现实的开发过程当中，严格禁止在公共分支上 rebase on 其余分支（譬如不容许在 master 分支上直接运行 git rebase branchname）。使用 merge 是最保险的合并分支方式，若是你对时间线清晰度要求不是那么高的话。可是若是你对时间线的清晰程度有比较高的要求，那么在合并分支的时候按第二种方法 rebase 就能帮助造成清晰的线性时间线，可是 rebase 的坏处是丢失了一部分提交操做历史。

同步分支

除了合并不一样分支这种状况，还有一个十分常见的状况，多人在同一个分支上开发，如何保证同一条分支具备清晰的时间线。咱们假设有三我的在开发 feature 分支，一般开发习惯是：

1. checkout feature 分支到本地。
2. 开发，并把开发的内容提交到本地 feature。
3. 使用 pull 把远程仓库中的 feature 和本地 feature 同步（pull 的默认方式是把远程的代码和本地代码作 merge 操做）。
4. push 同步完的 feature 分支到远程仓库。

按上述步骤，咱们看下时间线示意图：
先是第1，第2步

用户1执行3，4步

用户2执行3，4步

用户3执行3，4步

由于 pull 默认是经过 merge 远程仓库和本地仓库实现同步的，因此每次 pull 都会多出一个提交记录。可是咱们能够经过指定参数来指定 pull 的时候使用 rebase 策略：$ git pull --rebase。让咱们看下每次执行第3步的时候使用 pull rebase 那么会是什么样子。

用户1执行3，4步

用户2执行3，4步

用户3执行3，4步

经过图示咱们看到，若是使用 pull 的 rebase 模式，那么多人协做同一个分支也能够作到时间线清晰。最后再经过以前提到的 rebase 方式把 feature 合并到 master 分支上。那么整个开发过程时间线就呈现出清晰的时间线。

总结

1. 和远程仓库同步当前分支的时候使用 pull --rebase 的方式。
2. 合并分支的使用 feature rebase on master，master merge feature 的方式。