乐趣区

如何使用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 的方式。
退出移动版