使用 pull 命令时要快进（fast forward），合并分支时不要使用无快进模式（no-ff）。

Question

使用 pull 命令时要快进（fast forward），合并分支时不要使用无快进模式（no-ff）。

git

21

我在工作流中有许多短暂的分支，希望将它们分开。因此，我计划使用 git config --add merge.ff false。然而，当我执行拉取操作（我了解这是获取+合并），我希望出现快进行为，以避免不必要的额外提交。

这样做是否明智？是否可行？

- Vikash

注意：git config push.ff only将有助于Git 2.0。请参见下面我编辑的答案。 - VonC

@VonC 我想你是指 pull.ff 而不是 push.ff。此外，它在您的答案编辑中出现了一次。 - Kelvin

我知道这不太一样，但我相信 git pull --rebase 可以解决你的问题。 - Nick Roz

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- VonC · Accepted Answer

注意：Git 2.0（2014年第二季度）将引入commit b814da8一个名为push.ff的配置。

pull.ff::

默认情况下，当合并一个当前提交的后代时，Git不会创建额外的合并提交。相反，当前分支的尖端会被快进。如果将此变量设置为false，则告诉Git在这种情况下创建一个额外的合并提交（相当于从命令行中提供--no-ff选项）。如果将其设置为only，则只允许这样的快速转发合并（相当于从命令行中提供--ff-only选项）。

初始答案（2012年10月）

尝试a：

git pull --ff

它应优先考虑您的合并配置设置。
它将通过git pull命令中的底层合并传递--ff选项。
但要注意--no-ff选项，如“理解Git工作流程”所述。

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

考虑一下常见的Git工作流程如何失败。

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

大多数情况下，这种行为都符合您的期望，因为主干自分支以来发生了变化。然后有一天，您将一个特性分支合并到主干上，但主干没有分叉。Git不会创建一个新的合并提交，而是将主干指向特性分支上的最新提交，或者说“快进”（图表）。不幸的是，您的特性分支包含检查点提交，即频繁提交以备份工作，但捕获代码处于不稳定状态。现在，这些提交与主干的稳定提交无法区分。您可能很容易陷入灾难中。所以您添加了一个新规则：“当您合并特性分支时，请使用 -no-ff 强制创建一个新提交。” 这完成了工作，您继续前进。然后有一天，您在生产中发现了一个关键错误，并且需要追踪它是何时引入的。您运行bisect但总是落在检查点提交上。您放弃了并手动调查。您将错误缩小到单个文件。您运行blame以查看它在过去48小时内如何更改。您知道这是不可能的，但blame报告该文件几周内未被修改。事实证明，blame报告的是初始提交的更改时间，而不是合并的时间。您的第一个检查点提交几周前修改了此文件，但该更改今天才合并。 no-ff的临时措施，破坏的bisect和blame的神秘现象都表明您正在将螺丝刀用作锤子。

更多信息，请参见：