合并分支时使用 pull 和 no-ff 时快进

Question

我的工作流程中有许多短暂的分支，我希望将它们分开。所以，我打算使用git config --add merge.ff false。但是，当我进行拉动（我理解为 fetch+merge）时 - 然后我想要一个快进行为，以避免在这里不必要的额外提交。

这是一件好事吗？这可能吗？

Answer 1

注意：Git 2.0（2014 年第二季度）将引入 commit b814da8 配置 push.ff：

pull.ff::

默认情况下，Git 在合并作为当前提交的后代的提交时不会创建额外的合并提交。相反，当前分支的尖端是快进的。

• 当设置为 false 时，此变量告诉 Git 在这种情况下创建一个额外的合并提交（相当于从命令行提供 --no-ff 选项）。
• 当设置为 only 时，只允许这样的快进合并（相当于从命令行提供 --ff-only 选项）。

---

初步答案（2012 年 10 月）

试一试：

git pull --ff

它应该优先于您的合并配置设置。
它会将--ff 选项传递给 git pull 命令中的底层合并。

请注意 --no-ff 选项，如“Understanding the Git Workflow”中所述

有了足够多的标志，你就可以强制 Git 按照你认为应该的方式而不是它想要的方式行事。但这就像像锤子一样使用螺丝刀；它可以完成工作，但做得不好，需要更长的时间，并且会损坏螺丝刀。

考虑常见的 Git 工作流程是如何分崩离析的。

Create a branch off Master, 
do work, 
and merge it back into Master when you’re done

大多数情况下，它的行为与您预期的一样，因为 Master 在您分支后发生了变化。然后有一天你将一个特性分支合并到 Master 中，但 Master 并没有分叉。 Git 没有创建合并提交，而是将 Master 指向功能分支上的最新提交，或“快进”。 （图表）

不幸的是，您的功能分支包含检查点提交，频繁的提交会备份您的工作，但会捕获处于不稳定状态的代码。现在这些提交与 Master 的稳定提交没有区别。你很容易陷入灾难。

所以你添加了一条新规则：“当你在你的特性分支中合并时，使用–no-ff 来强制一个新的提交。”这样就完成了工作，然后您继续前进。

然后有一天，您在生产中发现了一个严重的错误，您需要追踪它是什么时候引入的。你运行bisect，但继续登陆检查点提交。你放弃并亲自调查。

您将错误范围缩小到单个文件。您运行 blame 以查看它在过去 48 小时内的变化。您知道这是不可能的，但 blame 报告该文件已在数周内没有被修改。
事实证明 blame 报告的是初始提交时的更改，而不是合并时的更改。您的第一次检查点提交数周前修改了此文件，但该更改已在今天合并。

no-ff 创可贴、二分法和怪罪之谜都是您将螺丝刀用作锤子的症状。

更多信息，请参见：

• “With dvcs/git, is a single commit preferred over multiple, small, thematic commits?”
• “git newbie question - Commit style: Commit all changed files at once or one at a time?”