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 应该是和团队实际状况考虑并选择。