--no-ff merge 如何打破平分和指责？

了解 Git 工作流程文章说，

因此，您添加了一条新规则：“当您合并功能分支时，请使用 –no-ff 强制进行新的提交。”这样就完成了工作，然后你就可以移动了 在。

然后有一天，您在生产中发现了一个严重的错误，并且您需要 追踪它的推出时间。你跑平分但继续着陆 在检查点提交上。你放弃并手工调查。

您将错误缩小到单个文件。你跑去责怪看看怎么样 过去 48 小时内发生变化。你知道这是不可能的，但责备 报告该文件已经几周没有被触及了。事实证明责备 报告初始提交时的更改，而不是合并时的更改。 您的第一个检查点提交在几周前修改了此文件，但是 更改已合并到今天。

无用的创可贴、破损的平分线和责备之谜都是 您将螺丝刀用作锤子的症状。

git合并--no-ff是您显式阻止快进合并的情况。但是，如果一个提交不是另一个提交的直接祖先，则快进甚至不会发生。这是开发中罕见的场景。换句话说，大多数合并都是非快进类型的。那么如何通过--no-ff破坏的功能bisect and blame?

tl;dr

合并提交和--no-ff没有任何关系git bisect or git blame per se.

Mixing public and private历史使得理解不同提交引入的变化变得更加困难。当使用时，这变得非常明显git bisect and git blame用于调试。

合并提交和git bisect

正如@torek所说，通过传递强制创建合并提交--no-ff没有做任何事git bisect.

真正的问题来自于污染公共历史具有临时提交的存储库 – 有时称为检查站提交——程序员用来在本地跟踪自己的工作。

由于其临时性，这些提交往往是不一致的– 可能会在代码库中引入错误 – 并且文档记录不足。在调试会话中进行这样的提交git bisect这不是一次愉快的经历；该补丁可能难以解释，或者更糟糕的是，它可能会破坏工作树中的代码。

I think莱纳斯·托瓦尔兹说得最好:

我想要干净的历史，但这实际上意味着（a）干净和（b）历史。

关于“干净”的部分，他接着详细阐述：

保持你自己的历史可读。

有些人通过先在头脑中解决问题来做到这一点， 并且不犯错误。但这是非常罕见的，对于我们其他人来说， 我们在解决问题时使用“git rebase”等。

别暴露你的垃圾。

合并提交和git blame

到那个时刻git blame, 合并提交do， 实际上，影响您得到的结果.

git blame总是显示原作者给定的代码行；换句话说谁added到文件中。从 Git 的角度来看，合并提交并不add任何内容到文件，它只是表示存储库目录和文件的快照，这些快照是由两行或多行历史记录组合而成的。除非它是一个邪恶合并， 那是。

这意味着运行git blame合并文件上将显示每一行的原始作者，无论谁进行了合并提交。

这就是为什么合并提交会让跟踪变得更加困难who做了一个特定的改变并且when。但话说回来，你不应该合并private致力于public无论如何，分支，因为除了原作者之外，它们对其他任何人都没有意义。