git merge和rebase的区别2：对远端分支的影响

上一篇中已经说明了 merge 和 rebase 会如何改变 commit 链路的结构，但有一些场景依然很模糊。

比如：如果远端分支有一些提交了，客户端也有一些提交了，客户端 fetch 到数据后，再 merge ，产生了新的 commit 节点，这也是我们知道的，那么客户端将变动 push 到远端，远端的 commit 结构会变成什么样呢？

我做了实验确认了一下，远端的分支就出现了分叉，再合并的情况。

我想，这是非常不好的。造成上述情况，仅仅是因为两个程序员都基于某个 commit 节点开发，尽管没有冲突，也会形成这样一个分叉的结构。

假如我们一个小组有 10 个成员，那么岂不是这个远程 commit 结构到处都分叉，然后又合并回去，这样看起来是不太友好的。

于是我又实验了一下 rebase
git pull --rebase
或者
git fetch
git rebase

我在远程分支上线 push 了两次提交，然后另一个本地分支，commit 两次提交，后执行git pull --rebase
来看看命令行的输出：

git pull --rebase
First, rewinding head to replay your work on top of it...
Applying: a5
Applying: a6

它apply了a5和a6（这两个就是我最近两次commit提交的备注）

再来看看commit的结构：

如上图所示，就是一个线性的结构。

但它有一个小毛病，我们就按着这个图来说。假如 b6 的提交实际上是比 a5 晚的，但它却排在了 a5 前面。也就是 commit 节点的顺序和时间顺序是不一致的。

但至少这样，远端的 commit 历史是线性的了。

至于选择 merge 和 rebase 应该是和团队实际情况考虑并选择。