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

Question

A Successful Git Branching Model建议合并分支时使用--no-ff：

--no-ff 标志导致合并总是创建一个新的提交 对象，即使可以使用快进执行合并。这 避免丢失有关特征历史存在的信息 分支和组合在一起的所有提交，它们一起添加了 特征。 […]

是的，它会创建更多（空）提交对象，但收益是 比那个成本大得多。不幸的是，我还没有找到方法 使 --no-ff 成为 git merge 的默认行为，但它确实 应该是。

但是，

Understanding the Git Workflow 建议不要使用--no-ff：

所以你添加了一条新规则：“当你在你的特性分支中合并时，使用 –-no-ff 强制执行新的提交。”这样就完成了工作，然后你就搬家了 在。 […]

--no-ff 创可贴、破掉的bisect 和blame 都是谜团 您将螺丝刀用作锤子的症状。 […]

对于不同的场景，这两种方法似乎都是合理的，但什么才是“好的做法”？

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

Answer 1

这实际上取决于您的工作流程，以及您如何使用分支。

假设您有一个“master”和两个功能分支“foo”和“bar”正在开发中。

在这种情况下，分支的存在只是为了让不同的开发者工作不冲突，当特性完成后，需要合并到master中，不知道这些特性是否在不同的分支中实现。

但是您可以有不同的工作流程，分支“foo”和“bar”是否指代系统中的独立模块。

在这种情况下，某些提交可能会更改模块范围之外的文件。当您将这两个分支合并到主分支时，特定模块之外的文件日志可能会变得混乱并且难以知道这些更改来自何处。

您需要确定分支合并的历史对您的工作流程是否重要。

在 cmets 之后，我更喜欢 rebase 和 pull --rebase 工作流程。

Answer 2

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

git 的特点是它是一个非常强大的工具，你可以通过多种方式使用它——其中大部分都没有错。问什么是“正确的方式”去做这件事就像问什么是画一幅画的正确方式。

至少对我来说，这是我喜欢的一组不断发展的方式，团队中经常讨论我们希望如何在代码上进行协作 - 从中​​我们试图推导出一种“这里是如何完成的”标准，但这只是我们的做法。

Answer 3

对于单次提交的已完成分支，不要使用--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 次提交实际上属于一个特性？