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

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

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

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

---

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

---

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

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

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

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

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

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

根据评论，我更喜欢 rebase 和 pull --rebase 工作流程。

---