Question

我克隆了一个公共存储库。在我的本地存储库中，我有一个像这样的分支结构，其中字母代表提交：

[public tag: v1] - A - B - C [myBranch1]
                       \
                        \- D [myBranch2]

公众回购已移动并发布了新标签“v2”。我想将我的分支机构重新定义到新版本，所以我做了：

git rebase --onto v2 v1 myBranch1
git rebase --onto v2 v1 myBranch2

这似乎有效，除了它创建具有相同内容但不同哈希码的提交A和B的不同副本：

[public tag: v2] - A' - B' - C' [myBranch1]
                 \
                  \A''- B''- D' [myBranch2]

我意识到我可以做一些更复杂的事情，如：

git rebase --onto v2 v1 myBranch1
git rebase --onto myBranch1 B myBranch2

这应该给我想要的结果，但是要复杂得多，特别是当我/当我创建更多的额外分支时。当我去捕获提交哈希码时，它更容易出错，并且必须跟踪每个分支从哪个分支分支的位置。

1）有没有更好的方法来实现这个结果？我猜你可以建议其他工作流程，但我很确定这是我想要维护的那种分支/提交结构。

2）为什么 A'和A''的哈希码不同？它们不是将相同的差异/作者/时间戳应用于相同的基线/内容的产物吗？我意识到这两个操作是作为两个单独的操作生成的，但我希望这些操作是确定性的，因此“碰撞”（正确）。

Answer 1

1）您可以使用B自动查找merge-base：

git merge-base myBranch1 myBranch2

会给你B

2）Rebase并没有真正移动原始提交，而是复制它们，或者实际上重放每个提交引起的差异。重新设定的提交将始终有新的哈希值。

提交中的哈希不仅是受版本控制的整个文件树的所有内容的校验和，而且还是父提交的哈希的校验和。因此，即使您要重现相同的文件树（不太可能），您仍然会获得新的哈希，因为您有不同的父级。

Answer 2

[Klas Mellbourn打败了我;我的回答只是在这一点上扩展了他的一点。]

对于它的价值，我已经看到了一些允许这种事情的“群体或集体变种”方法的尝试。他们都需要一些方法来首先选择哪个分支进行rebase，然后在现在重新分支的分支上重新定义其他“依赖”分支。

这些答案就是：

不，除了您可以自动执行此操作。 well 如何自动完成它完全是另一个问题。 :-)我见过的剧本并不像应该的那样聪明。（一个自动化系统应该在所有分支上进行爬行，为每个分支计算适当的合并基础，并进行一组最小的rebase / cherry-pick操作，记录足够的“开始状态”以允许你做点击需要手动解决的点时--abort或--continue。这也需要延迟各种分支标签的移动。）
A''有一个不同的提交时间戳，vs A'（如果它具有完全相同的提交元数据和相同的树，它实际上最终将是相同的实际新提交）。作为Klas Mellbourn noted，一旦A''不同，其他所有内容也会不同。