git log --cherry-pick --right-only --no-merges是否会忽略分支之间正确选择的所有提交？

Question

我在一个大型软件团队中工作，每月发布大量新闻。我们在一个分支上发布模型（见图）。

此模型解决了许多问题，但存在一些管理风险。当我将分支1.1发布到生产环境时，我需要检查1.0中的所有提交都在1.1中。

我可以使用以下命令执行此操作：

git log --cherry-pick --right-only --pretty="%h %ce %B" --no-merges release/1.1/master...release/1.0/master > missingcommits.log

然后，我将此列表通过电子邮件发送给每个相关的开发人员，并请他们仔细检查一下。

这工作得很好，但是我担心它会收到一些误报。

当然，现在如果您已经在具有两个不同提交的两个不同分支中签入了相同的代码，那么这将与此次扫描不符。

理论上，如果您从1.0到1.1挑选了提交-则该扫描中不应显示该提交（即，两个分支中都存在相同的提交）。

现在我的代码可以正常工作了。即在一个分支中的代码，我挑了一下，然后在此扫描中未显示。所以我认为它应该起作用。

当我仅向他们发送电子邮件时，“他们在新发行版分支中缺少提交”时，我得到的是一些开发人员回覆对我说：

  

不，我绝对不喜欢将代码移到其他地方。

现在可能是

（a）防御行为，或

（b）采摘樱桃出错，

（c）我对git或

的误解

（d）此过程确实存在问题。

我的问题是： git log --cherry-pick --right-only --no-merges是否会忽略分支之间正确选择的所有提交？

Answer 1

有两种可能的“错误”：

• 在您不希望将其列出（从医学术语中借来的，它们是假阳性）时提交列表；和
当您没有希望他们列出时，
• 提交未列出（假否定）。

有一个单一的潜在机制，这意味着两者都可能发生。但是，特别危险的一次提交（应该是错误的否定）没有列出，这是非常罕见的。

要了解发生了什么，请先通读git patch-id documentation。请注意，每个提交都有其自己唯一的哈希ID，但是给定两个 different 提交，它们的输出与git diff或git show足够相似，将两个提交中的每个提交与其父级进行比较（ s），这两个不同的提交将具有 same 补丁ID。换句话说，补丁ID是 attempt ，用于标识经过精心挑选的提交。

这种尝试是不完美的。如文档所述，patch-ID本质上是diff的校验和，其中已删除了diff主体中的行号和任何空白。如果有人精心挑选一个提交并顺利进行，则新的提交和原始的提交肯定具有相同的补丁ID。但是，如果存在问题（如果提交需要某种手动冲突解决方案），则新提交可能会具有不同的补丁ID。这给了您一个错误的肯定：当某人不得不检查提交 在那里时，它只是浪费了一些时间。

错误的负值表示更改了重要内容（可能是闭合块的放置）的提交被遗漏了。例如，当diff＃1说“从行A移到右括号到行B”，而diff＃2说“从行C移到不同右括号到D行”时，就会发生这种情况。补丁ID会删除行号，右括号只是一个右括号。缩进可能也会在两个差异之间发生变化，但是这也将被忽略。因此，事实是差异1中的循环＃1受到影响，差异2中的完全不同的循环＃2也受到影响。从语义分析的角度来看，应该认为这两个补丁 是不同的，但是没有进行此类分析的git patch-id认为它们是相同的。

这些可以发生。如果您有一个好的测试套件，那么任何可能导致错过“樱桃选择”的错误否定测试都可能无法通过测试，但这绝对不是Git可以保证的。