17

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

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

4

1 回答 1

23

注意：Git 2.0（2014 年第二季度）将通过提交 b814da8引入一个配置push.ff：

pull.ff::

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

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

初步答案（2012 年 10 月）

尝试一个：

git pull --ff

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

但请注意该--no-ff选项，如“了解 Git 工作流程”中所述

有了足够多的标志，你就可以强制 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创可贴、折断的二分法和怪罪之谜都是您将螺丝刀用作锤子的症状。

有关更多信息，请参阅：

于 2012-10-09T11:24:40.657 回答