假设我曾经拥有一个存储库Z，并根据它创建了两个存储库（A和B）。
我让他们互相排斥。我的意思是A中的文件不应该在B中，反之亦然。所以，我删除了A中的一些文件以及B中的文件。
这两个存储库随着时间的推移不断增长。
现在，由于一些管理决策，我需要将它们作为单个存储库返回。我尝试进行合并，如How to use the subtree merge strategy所示，但它给了我太多的冲突，合并本身非常脏。我知道这是一项不寻常而艰巨的任务。
你们有没有遇到同样的问题，你是怎么解决的？
提前致谢，
答案 0 :(得分：1)
我怀疑这是一个好主意，但听起来它是否真的无关紧要。
所以你有一个单独的回购，我假设，其中有两个项目。他们分享了一段历史，似乎你需要回到那个状态 - 一个包含所有文件的主分支。
你显然已经把所有物品都放到了一个回购中。例如，也许您添加了一个repo作为另一个的远程，并获取其主参考;所以，假设你有
A -- B -- C -- X1 -- X2 -- X3 <--(master)
\
Y1 -- Y2 -- Y3 <--(repoB/master)
你试试
git checkout master
git merge repoB/master
你会得到冲突和其他混乱，并且可能理解混乱会有助于理解该做什么。冲突可以像“文件在这里删除并在那里修改”一样简单，这很容易解决，但其他事情也可以继续。
例如，如果您要拆分两个项目，那么您可能已经将一堆东西从项目子目录移动到工作树根目录。或者您可能在一个仓库中创建了一个文件，其路径/名称与另一个仓库中的现有文件相同。或者其他什么。
所以我要做的第一件事就是确保每个repo的工作树都是你想要的组合工作树的子集。如果已经是这种情况 - 即在拆分回购后你没有移动文件，那么两个回购中都没有路径/文件名，而所需的工作树就是你cd所获得的一个repo的工作树和cp -R另一个repo的工作树 - 然后你可以跳过这一步。
但除此之外，你可以
git checkout master
然后mv文件，以便您拥有所需工作树的子集，并提交。然后
git checkout repoB/master
git checkout -b repoB
再次根据需要提交mv并提交。
A -- B -- C -- X1 -- X2 -- X3 -- X <--(master)
\
Y1 -- Y2 -- Y3 -- Y <--(repoB)
你可能没有这个，但它给了我们下一步比我们原本更简单的选择。
接下来我们可能想要开始合并。我们不希望默认的合并结果，这意味着我们正在创建可能被称为“邪恶”合并的东西;但在我看来它并没有那么糟糕，因为默认情况下合并会发生冲突 - 所以从某种意义上说， 没有默认的合并结果。
无论如何，我们希望将git置于“正在进行合并”状态，但是它的默认合并算法在这里没有多大用处;所以
git checkout master
git merge -s ours --no-commit repob
现在我们需要添加来自repob的文件，这些文件可以顺利运行，因为它们都不是我们已有文件的路径。
git checkout repob -- .
验证工作树现在看起来是正确的。然后
git commit