将两个不同的git存储库组合在一起，而不丢失任何一个历史。

Question

在我当前的项目中，我面临一个有趣的git问题：

自项目开始以来，更改就存储在我客户端远程服务器上的SVN存储库中。在开发过程中，我开始并行地创建一个本地git存储库，这样我就可以在不破坏当前版本的情况下更容易地测试新特性。可悲的是，git-svn没有工作，这会使我的生活更轻松。

现在，我的客户端切换到另一个服务器，在这个过程中，他们将SVN移动到git (使用git2svn)。

虽然我对此感到高兴，但现在有两个问题，

1. 因为我做了一个更大的功能，我已经有7天没有承诺使用SVN了。我在一个本地特性分支中工作，并将其备份到我的本地服务器上，但是SVN副本(现在是远程git )与我的本地版本相比已经过时了。
2. 由于远程回购是由git2svn创建的，它与我自己的回购完全不同(消息:警告:回购没有常见的提交。)--这使得标准合并成为不可能。

现在我的想要的目标

1. 合并两个repos有我的当前版本，是签入一个，并推送到原点工作。
2. 保存这两个回复的历史(从SVN以及从我的git过去7天的旧记录)。

到目前为止我尝试了什么，

我试图克隆远程git (从svn)，并将本地回购合并到其中。我和“两个版本都变了”有153次冲突。接受“他们的”(即我的最新发展)失去了文件的历史(它只是从我的并行git初始化开始)。

我的想法是，我可以为过去7天的每次提交创建一个补丁，并将其提交到带有相应提交消息(即“手动合并”)的新回购中。在编写脚本之前，我想问一下是否有一个内置的方式来完成这个任务。

提前感谢！

UPDATE：我尝试了许多解决方案，但都失败了。基本问题是，我现在有两个分支，没有一个公共提交，而是具有相同的树结构。这导致合并冲突，比如“在两个分支中添加”，因为git不知道myFile.txt" andmyFile.txt“是相同的，可以合并。相反，我必须手动合并我在那一周更改的150个文件--我不能也不会这样做。”

到目前为止，我最好的方法是为这些更改创建一个补丁，并将其应用于“新”回购。但是我并没有创建一个不会因为树错配而失败的补丁。我还没有找到正确的承诺开始补丁信息。

分辨率

医生:根本没有。你可以在较小的邪恶之间做出选择。

1. 您可以使用merge method desribed here，但是它将把SVN中的单个文件历史替换为您的侧git(也就是说，如果您的另一个repo只有2个月的历史，您就无法查找这个文件在3个月前更改的原因)。但是，从积极的方面来看，您仍然可以通过git日志将您的更改合并到全球历史中。
2. 我的另一个选择是复制并替换"new“(又名SVN) repo中的所有文件，使其具有git的当前状态(通过cp -vru，但省略了.git-folder和所有生成的文件)。这让我失去了一个星期的历史价值，但仍然让我回顾过去，直到我喜欢的项目开始。为了减轻损失带来的痛苦，我在提交消息中使用git log --date=short --pretty="format:%cd - %s" --name-status编写了一份详细的操作摘要，至少让我有机会回到这个条目并看到一条带有描述的消息。但是，这当然不适用于文件删除，您也无法知道哪些更改实际上属于biiiig提交消息的哪个部分。

Answer 1

我刚刚用我的存储库测试了这个。我创建了一个新的克隆，它代表了您客户的新存储库。然后，我将旧版本的内容复制到一个新文件夹中，并在其中初始化了一个存储库。我添加了内容，并提交了一些内容。

这样，我就有了两个没有普通提交的存储库。

现在，在新的存储库中，我将我的副本(在下面的mine中)添加为一个远程并获取其内容。然后我向我的主人检查了一个新的分支：

git checkout -b new mine/master

因此，我可以从这个分支访问我的所有单独存储库的历史。接下来，我使用递归合并策略将更新后的主服务器合并到我的分支中，但倾向于对冲突进行(新的)更改：

git merge master -s recursive -Xours

这将自动合并所有内容，在发生冲突时，它将通过使用我们的版本来自动解决这些问题，从而有效地丢弃主版本中的更改。

因此，您应该得到一个合并的分支，来自这两个存储库的所有历史记录都仍然存在。

Answer 2

如果我没听错的话，你会遇到这样的情况：

remote repo:
A - B

your repo
C - D - E - F

其中commit A实际上与C完全相同，并且提交B到D(关于所包含的文件)。我相信，可能起作用的只是将您的工作重新基于最新的远程提交，方法是执行以下操作

git rebase --onto B D

这将使您的提交从D到您的头部(例如F)，并将它们作为补丁应用于B，结果如下：

A - B - E' - F'

然后，这应该与您的本地更改相同，并且可以一致地推送到远程存储库。