Git 择优挑选然后 rebase

Question

当我在 git 中挑选樱桃后进行 rebase 时，有一些我不明白的事情。有人可以告诉我发生了什么事吗？

场景是这样的：

我正在主分支和主题分支上工作，如下所示，该主题有两次提交。

      C---D  topic
     /
A---B      master

我的主题分支有问题，所以我决定只挑选 D 并将其合并到主分支中。我创建一个发布分支并挑选它。

      C---D  topic
     /
A---B      master
     \
      D'  release

我将发布合并到主控中。

      C---D  topic
     /
A---B----E   master
     \  /
      D'  release

该主题的基础分支已更改，因此我将其重新设置为最新的主分支。

           C  topic
          /
A---B----E   master
     \  /
      D'  release

最后，那个精心挑选的提交D从主题中消失了。这就是我想要的结果。但我不明白为什么 git 发现它们是相同的，即使提交哈希值不同。

Answer 1

择优挑选会更改与提交关联的元数据（例如日期或其父级）。
但它不会更改其内容（它引用的树 SHA1）

正如“如何git rebase跳过其更改已在上游的提交？ ”中所述，与该提交关联的补丁 ID 与已合并的补丁 IDD相同。 所以rebase不会重复。D'

使用Git 2.34 (Q4 2021)，您实际上会看到那些跳过的提交，正如 rebase 会告诉您的那样：

skipped previously applied commit xxx
use git rebase --reapply-cherry-picks to include skipped commits

从手册页：

--重新申请樱桃挑选

--不重新申请樱桃选择

重新应用任何上游提交的所有干净的樱桃选择，而不是抢先删除它们。（如果这些提交在变基后变空，因为它们包含已经上游更改的子集，则针对它们的行为由 --empty 标志控制。）

默认情况下（或者如果--no-reapply-cherry-picks指定），这些提交将自动删除。
因为这需要读取所有上游提交，所以在需要读取大量上游提交的存储库中，这可能会很昂贵。
使用合并后端时，将为每个删除的提交发出警告（除非--quiet给出）。advice.skippedCherryPicks除非设置为 false，否则也会发出建议。

--reapply-cherry-picks允许 rebase 放弃读取所有上游提交，从而可能提高性能。