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

Vik*_*ash 14 git

我的工作流程中有许多短命分支,我希望它们能够分开.所以,我打算用git config --add merge.ff false.但是,当我正在进行拉(我理解为fetch + merge)时 - 然后我想要一个快进行为,以避免不必要的额外提交.

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

Von*_*onC 16

注意:Git 2.0(2014年第2季度)将引入提交b814da8配置push.ff:

pull.ff::
Run Code Online (Sandbox Code Playgroud)

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

  • 当设置为false时,此变量告诉Git在这种情况下创建额外的合并提交(相当于从命令行提供--no-ff选项).
  • 设置为only时,仅允许此类快进合并(相当于--ff-only从命令行提供选项).

初步答复(2012年10月)

试试:

git pull --ff
Run Code Online (Sandbox Code Playgroud)

它应该优先于您的合并配置设置.
它会将--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
Run Code Online (Sandbox Code Playgroud)

大多数情况下,这种行为与您期望的一样,因为Master在您分支后发生了变化.然后有一天你将一个功能分支合并到Master中,但Master没有分歧.Git不是创建合并提交,而是将Master指向功能分支上的最新提交,或"快进".(图)

不幸的是,您的功能分支包含检查点提交,频繁提交以备份您的工作但捕获处于不稳定状态的代码.现在这些提交与Master的稳定提交无法区分.你可以很容易地重新陷入灾难.

因此,您添加了一条新规则:"当您在功能分支中合并时,使用–no-ff强制执行新提交."这可以完成工作,然后继续.

然后有一天你发现了生产中的一个关键错误,你需要追踪它何时被引入.你运行bisect但继续登陆检查点提交.你放弃并手工调查.

您将错误缩小到单个文件.你跑去blame看看它在过去48小时里的变化情况.你知道这是不可能的,但blame报告文件几周没有被触及.
结果blame是初始提交时的报告更改,而不是合并时.您的第一个检查点提交在几周前修改了此文件,但此更改已于今天合并.

no-ff创可贴,破平分,并指责奥秘是你使用螺丝刀作为锤子症状.

有关更多信息,请参阅

  • 我真的不明白这句话如何证明为什么 `--no-ff` 不好。如果合并是 FF,您仍然会面临合并实际发生时间的相同谜团(它更加神秘,因为没有任何记录)。如果你使用了 `--no-ff`,你可以结合 `blame` 和 `git log --graph --ancestry-path` 来确定代码何时进入分支。 (2认同)
  • @Kelvin 是的。关于 ff 的其他好读物:http://stackoverflow.com/a/29319178/6309 和 http://git-blame.blogspot.fr/2015/03/fun-with-non-fast-forward.html。 (2认同)