何时在Git中使用'--no-ff'合并选项

Question

一个成功的Git分支模型建议--no-ff在合并分支时使用:

该--no-ff标志使合并始终创建新的提交对象,即使可以使用快进执行合并.这样可以避免丢失有关功能分支历史存在的信息,并将所有一起添加功能的提交组合在一起.[...]

是的,它会创建一些(空的)提交对象,但增益要大得多.不幸的是,我还没有找到一种方法来制作--no-ffgit merge的默认行为,但它确实应该如此.

但是,了解Git工作流建议不要使用--no-ff:

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

该--no-ff创可贴,破碎bisect,和blame奥秘是你使用螺丝刀作为锤子症状.[...]

这两种方法对于差异情景似乎都是合理的,但是什么被认为是"良好实践？"

你什么时候使用--no-ff,什么时候不用,为什么？

Answer 1

这真的取决于你想要做的事情.我的经验法则是,如果合并"意味着什么",我使用--no-ff选项.当合并实际上没有任何意义并且您可能使用了rebase时,没有理由使用--no-ff

使用git的是它是一个非常强大的工具,你可以在很多方面使用它 - 大多数都没有错.询问做什么的"正确方法"就像问什么是绘制图片的正确方法.

至少对我而言,这是我喜欢的一系列不断变化的方式,在团队中经常讨论我们如何在代码上进行协作 - 从中​​我们试图得出一种"如何在这里完成"的标准,但是这只是我们这样做的方式.

Answer 2

对于具有单个提交的已完成分支的情况,不要使用--no-ff,只是快进它,因为历史将更简单且更简洁.很难说--no-ff在这种情况下可以获得任何优势,因为只需一次提交就可以看到开发的并行分支,而不是顺序行中的单个提交,这是无趣的:

# No fast-forward
$ git merge --no-ff awesome-feature
*   3aa649c Merge branch 'awesome-feature'
|\
| * 35ec88f Add awesome feature
|/
* 89408de Modify feature-001.txt and fix-001.txt
* c1abcde Add feature-003

# versus fast-forward
$ git merge awesome-feature
* 35ec88f Add awesome feature
* 89408de Modify feature-001.txt and fix-001.txt
* c1abcde Add feature-003

对于具有多个提交的已完成分支的情况,由您决定,无论您是否要保持分支开发发生在并行和顺序上的事实.我可能会使用--no-ff多个提交,只是为了让我可以在视觉上看到这个分支的工作,以便我可以用一个单独的操作它,git revert -m 1 <sha-of-merge-commit>如果我不得不.

# No fast-forward
$ git merge --no-ff epic-feature
*   d676897 Merge branch 'epic-feature'
|\
| * ba40d93 Add octocat.txt
| * b09d343 Add bye.txt
| * 75e18c8 Add hello.txt
|/
* 89408de Modify feature-001.txt and fix-001.txt
* c1abcde Add feature-003

# versus fast-forward
$ git merge epic-feature
* ba40d93 Add octocat.txt
* b09d343 Add bye.txt
* 75e18c8 Add hello.txt
* 89408de Modify feature-001.txt and fix-001.txt
* c1abcde Add feature-003

看看在这种快速合并的情况下如何在提交消息本身没有附加信息的情况下,很难说最后3次提交实际上属于一个特征？