3

考虑以下场景：

$ git branch –a 
* dev
  master

$ git branch --contains 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6
 dev

$ git branch --contains f7dfb3689edcaf5f819fa5e691ce13abf858bca8
   dev
   master

$ git cherry master dev
+ 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6
+ a4e66dbde954f73185d61bfb78b40ac5e61fe56c
+ 6fcffbd9b57e8a74726ea2cd3713f14baaaa06f5
+ 5031ad3cdf2e81c880e9cbf049abed6f1edde3bc
+ dcca33c373df6953ff164e8d70531abd71841278

但转折点是，提交f7dfb3689edcaf5f819fa5e691ce13abf858bca8实际上是从 中挑选出来的53fdfaf89fca499c36c71d29f25eb1a13b32d4d6，并且两者完全相同（请原谅我，因为出于某种原因，我们必须有 2 个完全相同的提交，但提交 id 不同）除了提交消息和提交 id，还有两次提交之间没有区别。

现在根据git cherry文档， 将提交与从 git patch-id 程序获得的补丁 ID 进行比较。

所以我实际上继续执行git patch-id下面的程序

$ git show 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6 | git patch-id
bd6c061bd6c380d53832510cbaf68bebb4fb182d 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6

$ git show f7dfb3689edcaf5f819fa5e691ce13abf858bca8 | git patch-id
bd6c061bd6c380d53832510cbaf68bebb4fb182d f7dfb3689edcaf5f819fa5e691ce13abf858bca8

上面的结果表明，git patch-id实际上确实承认这两个提交是相同的，但git cherry命令仍然无法做到这一点。

我能看到发生这种情况的唯一原因是如果git cherry考虑到除git patch-id.

它是否考虑了头部提交的数量（即我的开发分支）？因为我们在 dev 分支上有 2 个版本的提交，而在 master 上只有 1 个。

4

1 回答 1

1

从上面的输出中，您也将精心挑选的修订版合并到 dev 中（通过在某些时候合并 master）。Git 正在遍历修订集，它现在找到一个完全匹配并将其从要检查的修订集中删除，并且不会为其生成补丁 ID。好消息是，git merge仍然承认 dev 上的原始更改已经在 master 中，并且不会尝试重新应用该更改。

我认为在大多数涉及樱桃采摘的工作流程中，您永远不会将包含樱桃采摘的分支合并回您的分支。您通常会做更多类似的事情：将修复提交给 master，然后将cherry-pick 提交给一个稳定的分支。或者，在您的情况下，将错误修复提交给 master，然后将 master 合并到 dev 中。

git cherry 你可以在这里看到后面的代码。请注意此处的补丁 ID 生成。特别要注意第719 行的注释。它将要求对 master 进行修订，而不是在 dev 中，因为 master 已合并到 dev 中，这将是没有的。因此不会生成补丁 ID。结果，看起来您最初的非樱桃采摘修订版尚未被掌握。

你可以争辩说这种行为是一个错误。但我认为，修复它可能会对性能产生重大影响。

于 2012-12-09T11:14:41.323 回答