我的工作流程中有许多短命分支，我希望它们能够分开。所以，我打算使用git config --add merge.ff false。但是，当我正在进行拉（我理解为fetch + merge）时 - 然后我想要一个快进行为，以避免不必要的额外提交。
这是一件好事吗？这可能吗？
答案 0 :(得分：16)
注意：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创可贴，破碎的二等分和责备之谜都是你用螺丝刀作为锤子的症状。
有关更多信息，请参阅：