3

存储库 A:在修订时从项目的 SVN 迁移到 git r:克隆了整个内容,包括 SVN 的所有历史、标签等。之后对 git 进行了一些开发。

存储库 B:同一个项目,但在修订版时从 SVN 独立迁移r+small_number。只有最新的快照被带入 git。之后大量独立开发。

现在我将 A 合并到 B 中。想法是 SVN 将被丢弃,开发将继续在developGitHub 上项目的 repo 分支中进行。我使用简单的合并来完成这项工作;幸运的是,真正的冲突很少。开发主要是在不同的领域,尽管在合并后有很多清理工作,与 git 无关。

但是:现在,当我git rebase -i HEAD~2合并的结果进行例如操作时,我知道这应该让我重新设置最后两个提交的基础,我看到了大约 300 多个提交的页面——这是自 SVN 修订版 1 以来项目的完整历史。我中止了 rebase,因为害怕搞砸更多(显然我是一个完整的 Git 新手)。

这是预期的结果吗?这是可取的吗?如果不是,如何解决?

请注意,所有单元测试等都通过了,文件本身还可以,只是我不明白 git 元数据/历史记录发生了什么。

编辑:这就是我*认为*存储库现在的样子:

          r         A
... o --- o --- ... o 
                     \ 
               B      \    
    o --- .... o ----  o --- ... o 
   r+small_number      C         HEAD
4

1 回答 1

8

我猜这种行为的发生是因为您试图通过合并提交进行变基。

对于以下答案,我假设您的历史记录如下所示,即存储库 A 和 B 是完全独立的:

          r         A
... o --- o --- ... o

o ... o
r'    B

你需要问问自己你想要达到什么目标?所以你想要一个新的分支 C 包含 A 和 B 的变化。这里的优先级是什么?你想实现一个适当的历史;r'纠正丢失其 SVN 历史的事实?还是保持 A 和 B 的 git 历史不变很重要?

我的回答是假设你想要实现前者。由于 A 和 B 都来自非常相似的 SVN 存储库版本,因此在合并公共历史之前给它们一个公共 git 库可能是个好主意。因此,理想情况下,在合并之前,您会遇到以下情况:

          r          A
... o --- o --- .... o
           \
            \
             o --- .... o
       r+small_number   B

目前,我不确定哪个是实现这一目标的最佳方法,但您可以尝试做git rebase -p --onto r --root B.

然后你可以只是git mergeA 和 B 并以历史结束

          r          A     C
... o --- o --- .... o --- o
           \              /
            \            /
             o --- .... o
       r+small_number   B

其中 C 包含您的所有更改。我可能会留在那里;没有任何进一步的变基。

于 2011-03-18T13:41:58.400 回答