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 回答