我在工作流中有许多短暂的分支,希望将它们分开。因此,我计划使用 git config --add merge.ff false
。然而,当我执行拉取操作(我了解这是获取+合并),我希望出现快进行为,以避免不必要的额外提交。
这样做是否明智?是否可行?
我在工作流中有许多短暂的分支,希望将它们分开。因此,我计划使用 git config --add merge.ff false
。然而,当我执行拉取操作(我了解这是获取+合并),我希望出现快进行为,以避免不必要的额外提交。
这样做是否明智?是否可行?
push.ff
的配置。pull.ff::
初始答案(2012年10月)
尝试a:
git pull --ff
--ff
选项。--no-ff
选项,如“理解Git工作流程”所述。使用足够的标志,您可以强制Git按照您认为应该而不是它想要的方式进行操作。但这就像使用螺丝刀当锤子一样;它可以完成工作,但完成得很差,需要更长时间,并且会损坏螺丝刀。
考虑一下常见的Git工作流程如何失败。
Create a branch off Master,
do work,
and merge it back into Master when you’re done
-no-ff
强制创建一个新提交。” 这完成了工作,您继续前进。然后有一天,您在生产中发现了一个关键错误,并且需要追踪它是何时引入的。您运行bisect
但总是落在检查点提交上。您放弃了并手动调查。您将错误缩小到单个文件。您运行blame
以查看它在过去48小时内如何更改。您知道这是不可能的,但blame
报告该文件几周内未被修改。事实证明,blame
报告的是初始提交的更改时间,而不是合并的时间。您的第一个检查点提交几周前修改了此文件,但该更改今天才合并。 no-ff
的临时措施,破坏的bisect和blame的神秘现象都表明您正在将螺丝刀用作锤子。
更多信息,请参见:
--no-ff
是不好的。如果合并是一个快进(FF),你仍然会面临同样令人困惑的问题,即合并实际发生的时间(甚至更加神秘,因为根本没有记录)。如果您使用了--no-ff
,则可以结合“blame”和“git log --graph --ancestry-path”来确定代码何时进入分支。 - Kelvin
git config push.ff only
将有助于Git 2.0。请参见下面我编辑的答案。 - VonCpull.ff
而不是push.ff
。此外,它在您的答案编辑中出现了一次。 - Kelvingit pull --rebase
可以解决你的问题。 - Nick Roz