我想决定是否使用 --no-ff 选项（合并时）。
我阅读了这篇文章：了解 Git 工作流程。从那里引用：
不幸的是，您的功能分支包含检查点提交，频繁的提交会备份您的工作，但会捕获处于不稳定状态的代码。现在这些提交与 Master 的稳定提交没有区别。你可以很容易地卷入一场灾难。
但事实上，这种可能性并不让我担心。所以这不是--no-ff我使用的理由。对我来说，也不是像作者建议的那样“在合并之前，使用重置、变基、压缩合并和提交修改等工具清理我的分支。”。
不过，我想使用--no-ff另一个原因：它让我很容易知道哪个提交是关于哪个功能的。IOW，它让我可以单独保存每个功能，这样我就可以单独浏览它。基本上与我使用带有文件夹、子文件夹和文件的分层文件系统的原因相同。
还有另一个原因：我不喜欢平原如何git merge创造无意义的交错历史。示例（一天内）：
在分支中提交master：
- mFoo，下午 1 点提交
- mBar，下午 3 点提交
在分支中提交feature：
- fFoo，下午 2 点提交
- fBar，下午 4 点提交
一个普通的 git merge 会创建这个历史：
mFoo, fFoo, mBar, fBar
所以现在如果我回到 mBar，我也会得到feature's 的部分更改，这是没有意义的——它们甚至可能与 mBar 不兼容。
git blame似乎我的这些偏好在概念上与and的正常功能并不冲突git bisect，但出于某种原因，我显然不能两者兼得。
你能告诉我这个原因是什么，是否有解决方法？