让我们有一个 git master 分支，并在某个时刻让 fork 分支发布（发布分支将被称为 R1）。有时我需要向他们（master 和 R1）推送提交。通常我在主分支上工作，完成后我对其进行测试，挑选到 R1，在那里测试并推送到它们。
我想在 R1 提交中引用 master 分支。这是由cherry-pick -x 完成的。但是，这种方法仅在我推送到主分支然后从主分支到 R1 时才有效。假设测试花费了太多时间，我希望 master 和 R1 尽可能多地同步（我想最小化推送之间的时间间隔），所以我想同时推送。通过这种方式，我无法获得参考（cherry-pick 中的 -x），因为在 R1 中进行 rebase 时哈希会发生变化（不能使用合并）。有什么办法可以自动化这个，所以我会在 R1 描述中有正确的散列？像哈希预测这样的东西？
有什么办法可以自动化这个，所以我会在 R1 描述中有正确的散列？像哈希预测这样的东西？
最简洁的答案是不。
更长的答案仍然是否定的，但您可能不需要预测哈希。这里的问题是您正在将一些修复提交（我们称之为）F从master另一个分支复制。让我们称之为-x精心挑选的副本提交Fx。您也可能最终将修复提交复制到新的修复提交，因为您避免git merge在此工作流程中使用，因此如果master获得了新提交，您可以使用 rebase 来挑选您将添加到F的新提交，并且现在你想用精心挑选的.F'masterFxFF'
所以，你可以这样做。如果您将提交变基F为 make F'，请从另一个分支中剥离Fx并重新运行git cherry-pick -x以复制F'到Fx'. 你已经知道这些是哪些提交，因为你有原始的哈希 IDF并且挑选它（通过 rebase）产生F'；并且您在 中具有F的哈希 ID Fx。缺点是这会在 另一个分支上重新复制任何提交Fx，因为“Fx从另一个分支剥离”可能很重要。
（一种避免所有这些大惊小怪的替代方法是将修复合并到两个分支中。请参阅如何在 git 中进行部分合并？和链接的博客文章。）