我想决定是否使用--no-ff选项（合并时）。
我读过这篇文章：Understanding the Git Workflow。从那里引用：
不幸的是，您的功能分支包含检查点提交，频繁提交以备份您的工作但捕获处于不稳定状态的代码。现在这些提交与Master的稳定提交无法区分。你可以很容易地重新陷入灾难。
但实际上，这种可能性并不让我担心。因此，对我来说，使用--no-ff并不是理由。对我来说，这也不是合并前的理由，而是使用诸如重置，重组，压缩合并和提交修改等工具来清理我的分支。＆＃34;，就像作者所建议的那样。
我想将--no-ff用于另一个原因：它让我轻松提交哪个功能。 IOW，它让我可以将每个功能分开保存，这样我就可以单独浏览了。基本上我使用带有文件夹，子文件夹和文件的分层文件系统的原因相同。
另一个原因是：我不喜欢普通git merge创建无意义的交错历史。示例（在一天内）：
在分支master中提交：
在分支feature中提交：
普通的git合并会创建此历史记录：
mFoo, fFoo, mBar, fBar
所以现在如果我回到mBar，我也会参与feature的变化，
没有意义 - 他们甚至可能与mBar不兼容。
似乎我的这些偏好在概念上与git blame和git bisect的正常运作没有冲突，但出于某种原因显然我不能同时兼顾。
你能告诉我这是什么原因，以及是否有解决方法？