- 如何合并打破平分和责备？ [英] How does --no-ff merge break bisect and blame?

问题描述

了解Git工作流程文章说，

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

然后有一天你发现生产中有一个严重的错误，并且当它被引入时你需要
来追踪。你运行平分，但在检查点提交时保持
。你放弃并手工调查。

您将错误缩小为单个文件。你运行责任，看看它在过去的48小时内如何变化
。你知道这是不可能的，但责备
报告文件在几周内没有被触及。原来指责
报告初始提交时间的变化，而不是合并时的变化。
您的第一次检查点提交在几周前修改了此文件，但是
更改在今天已合并。

no-ff创可贴bisect和怪罪奥秘都是你使用螺丝刀作为锤子的所有
症状。

git merge - no-ff 是您明确阻止快进合并的情况。但是，如果一个承诺不是另一承诺的直接祖先，那么快速发展甚至不会发生。这是一种罕见的情况。换句话说，大部分合并都是非快进类型。那么如何通过 - no-ff 来打破 bisect 和 blame

解决方案

tl; dr

合并提交和 - no-ff 与 git bisect 或没有任何关系。 git blame 本身。

混合 public 和历史是什么使得更难理解不同提交引入的变化。这在使用 git bisect 和 git blame 进行调试时变得非常明显。

合并提交和 git bisect

正如@torek所说，强制创建合并提交传递 - no-ff 不会对 git bisect 产生任何影响。

真正的问题来自于使用临时提交（有时称为检查点提交）污染存储库的公共历史 - 程序员用它来跟踪由于其临时性质，这些提交往往是不一致的 - 可能会在代码库中引入错误 - 并且记录不完善。在 git bisect 的调试会话中着陆这样的提交并不是一个愉快的体验;该补丁可能很难解释，甚至更糟 - 它可能会破坏工作树中的代码。

我想 Linus Torvalds 说得很好：

我想清除历史记录，但这确实意味着（a）清洁和（b）历史记录。

关于清洁部分，他继续阐述：

保持您自己的历史可读性。

<有些人通过先把事情做好，b $ b而不是犯错。但这是非常罕见的，对于我们其他人来说，在我们处理我们的问题时，我们使用git rebase等
。

不要暴露你的废话。

合并提交和 git blame

说到 git blame ，合并提交 do ，实际上

git blame

/ code>总是显示给定代码行的原创作者;换句话说，谁将添加到文件中。从Git的角度来看，合并提交不会将任何内容添加到文件中，它只是表示合并两行或更多行历史记录而导致的存储库目录和文件的快照。除非它是邪恶合并这意味着在合并的文件上运行 git blame 会显示出来。

你是每一行的原始作者，不管谁是合并提交者。

这就是为什么合并提交可能会使得难以跟踪谁一个特定的变化，当时。但是再一次，您不应该将 private 提交合并到 public 分支中，因为除了原作者之外，其他任何人都没有意义。

Understanding the Git Workflow article says,

So you add a new rule: "When you merge in your feature branch, use –no-ff to force a new commit." This gets the job done, and you move on.

Then one day you discover a critical bug in production, and you need to track down when it was introduced. You run bisect but keep landing on checkpoint commits. You give up and investigate by hand.

You narrow the bug to a single file. You run blame to see how it changed in the last 48 hours. You know it’s impossible, but blame reports the file hasn’t been touched in weeks. It turns out blame reports changes for the time of the initial commit, not when merged. Your first checkpoint commit modified this file weeks ago, but the change was merged in today.

The no-ff band-aid, broken bisect, and blame mysteries are all symptoms that you’re using a screwdriver as a hammer.

git merge --no-ff is a case when you prevent fast-forward merge explicitly. But, if one commit is not the direct ancestor of another, fast-forward doesn't even take place. It's a rare scenario in development. In other words, most of the merges are non-fast-forward type. Then how does passing --no-ff break the functionality of bisect and blame?

解决方案

tl;dr

Merge commits and --no-ff don't have anything to do with git bisect or git blame per se.

Mixing public and private histories is what makes it harder to make sense of the changes introduced by different commits. This becomes painfully obvious when using git bisect and git blame for debugging.

Merge commits and git bisect

As @torek said, forcing the creation of merge commits by passing --no-ff doesn't do anything to git bisect.

The real problem comes from polluting the public history of a repository with interim commits – sometimes called checkpoint commits – that were used by the programmers to keep track of their own work locally.

Due to their temporary nature, these commits tend to be inconsistent – potentially introducing errors in the code base – and poorly documented. Landing on such a commit in the middle of a debugging session with git bisect isn't a pleasant experience; the patch could be hard to interpret or – even worse – it could break the code in the working tree.

I think Linus Torvalds said it best:

I want clean history, but that really means (a) clean and (b) history.

Regarding the "clean" part, he goes on to elaborate:

Keep your own history readable.

Some people do this by just working things out in their head first, and not making mistakes. But that's very rare, and for the rest of us, we use "git rebase" etc. while we work on our problems.

Don't expose your crap.

Merge commits and git blame

When it comes to git blame, merge commits do, in fact, have an impact on the results you get.

git blame always shows the original author of a given line of code; in other words who added it to the file. From the point of view of Git, a merge commit doesn't add anything to a file, it simply represents the snapshot of the repository's directories and files that results from combining two or more lines of history. Unless it's an evil merge, that is.

This means that running git blame on a merged file is going to show you the original author of each line, regardless of who did the merge commit.

That's why merge commits can make it harder to track who did a particular change and when. But then again, you shouldn't be merging private commits into public branches anyway, since they won't make sense to anyone else but the original author.

这篇关于 - 如何合并打破平分和责备？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！