Fast-Forward Git Merge

Fast-Forward Git Merge

合并分支在Git中是一种十分常见的操作。在某些情况下，Git默认会尝试使用Fast-Forward模式进行分支合并操作。不用这种模式进行合并会有怎样的不同呢?

假设我在master分支上创建出一个主题分支speedup，在speedup上开发一段时间后（提交了3个commit，也就是那些白色圆圈），我决定收工并把它推送到我的远程仓库中去。而在此期间master分支里并没有任何的该动，还保持着建立speedup分支前的样子。情况如图所示

当项目维护被告知我的分支已经准备好去合并时，她可能使用git fetch再加git merge这样的常见方法将我的工作成果合并到源码树中去。作为主题分支根基的master分支由于自其被commit后没有任何的改动，Git将会使用Fast-Forward模式进行合并操作。这一系列的commits将以线性呈现，历史记录也将如图所示（左图）。

另一种的合并就是利用-no-ff选项（它代表“no fast-forward”）。在此情况下，历史记录看起来会有所不同（右图），这有个额外的commit（虚线圆）来强调这次合并。这个commit甚至会含有对被合并分支的准确描述。

在默认条件下，只要条件允许，Git就会使用fast-forward模式。但我们可以改变这种情况，通过恰当的配置no-fast-forward就会被设置为默认合并模式。

可能no-fast-forward最典型的应用就是使用GitHub上绿色的Merge按键。这个按键是pull请求工作流的一部分。当某人创建了一个pull请求时，这里有个可以合并更改的方法（无论GitHub是否认为这可以做到），只需点击在这个项目页面的按键。

不幸的是，截至目前，GitHub网页端将会执行合并仿佛你明确指定-no-ff。换言之，即使可以使用fast-forward，GitHub也不会这么做。一个可能的解释就是这么做可以标记一个pull请求。例如，一个工程commit的一部分（我挑选了 ESLint 作为案例, 这个工程没啥特别的）看起来可能像这样

看看这幅图，很明显这些分支可以使用fast-forward模式合并。哎，GitHub合并的方式将commit历史从线性连续改为一种看起来像铁路线的东西。

简言之，non fast-forward 合并保持了明确分支的概念，它或许会让commit历史变得复杂。它会产生非线性结果作为保持分支来源的代价（pull 请求，当使用GitHub时）。另一方面，fast-forward模式将变化保留在一种线性的历史记录中，这让使用其他工具变得简单（log,blame,bisect）。每个分支来源将变得不明显，虽然这并不是什么大问题如果工程在它的问题追踪器和commit信息之间授权严格的交叉引用。

你更喜欢哪种合并模式，是fast-forward还是非fast-forward呢？

注：因本人水平有限，翻译有出入地方希望读者能够批评指正

原文链接 http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html