Git存储库 - 如何在运行git filter-branch后重放对旧存储库的更新提交,以及修改后的存储库

时间:2014-02-13 12:04:46

标签: git

在我正在为之工作的公司,我们最近将一个Subversion存储库迁移到了Git,但在这个过程中,分支和合并点丢失了,留下了一堆完全平行的未链接分支。因为它们没有分支点,所以git无法干净地合并。我们无法重做迁移,因为人们已经在向每个不同的分支推送额外的提交。

我们决定通过从subversion存储库中提取分支和合并点列表来修复git存储库,将它们匹配到git存储库中的提交ID,然后运行git filter-branch来重写所有父级引用。

那部分工作正常。我在分支之间进行了一些测试合并,以确认手术正常,到目前为止,非常好。问题是在这个过程中,团队继续工作,在他们各自的分支上添加了各种提交,并且因为filter-branch导致生成新的提交ID,所以我的情况是团队的新提交是旧的提交。提交,我需要以某种方式将这些提交现在应用于新的重写树。

我知道git rebase通常用于此类事情,但rebase似乎只适用于常见的分支点,而现在已经不再适用了。

我也尝试使用git cherry-pick,但我没有成功,因为我不知道它应该如何工作,这意味着我不知道如何解释它给我的意外输出我所读到的关于如何使用它的内容并不是特别清楚,无论是使用什么命令还是应该的预期输出。

我试图说明下面的问题:

Git Tree Surgery

  • 请注意,我们在Windows上 - 除非通过msysgit附带的Git Bash,否则Linux命令不可用。

1 个答案:

答案 0 :(得分:1)

根据需要这些修复的分支数量,我很想为每个分支执行以下操作:

git rebase --onto H' H J

这会在HJ之间进行任何提交,并将其应用于H'之上(其中H'是您中间H的新ID图)。

这适用于存在线性拓扑的情况,但是对于其他情况,您需要额外的标志:

git rebase --preserve-merges --onto I' I M

这应保留包含KL的合并拓扑。

我也发现这种问题在我身边tig更容易解决(确保set commit-order = topo最大限度地发挥作用)。

相关问题