时间戳

首页 > 解决方案 > Git 樱桃挑选然后变基

git - Git 樱桃挑选然后变基

问题描述

在 git 中挑选樱桃后，当我重新设置基准时，有些东西我不明白。有人可以告诉我发生了什么事吗？

像这样的场景：

我正在处理以下主分支和主题分支，并且该主题有两个提交。

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

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

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

我将发布合并到主控中。

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

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

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

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

标签： git

解决方案

樱桃选择会将元数据关联更改为提交（如日期或其父级）。
但它不会改变它的内容（它引用的树 SHA1）

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

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

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

从手册页：

--reapply-cherry-picks

--no-reapply-cherry-picks

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

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

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

推荐阅读