我想建立一些坚如磐石的规则，我们可以用它来逐步将我们的多个回购组合成一个回购。我以前做过这个，但只是在一个简单的情况下。
我的出发点是this article。
在我们的案例中，我们已经（进化了）六个左右的回购，几个月前我将其中一个合并为一个新的，最终我们希望一切都在这个新的，而不会丢失历史。
让我强调一下，我们在Github谈论一个组织帐户，所有回购都是私人的，都是这些回购的分支。
我所看到的挑战 - 在一般情况下 - 是其他人已经分叉了这些回购，也可能在他们的基础仓库中不存在分支。
因此，如果我只是将一个基本仓库合并到另一个仓库中，原始仓库的分支将变为无效，其内容（仅存在于货叉上的提交）将无法使用。
另外 - 在那篇文章中没有讨论 - 是多个分支的问题，如果源代表（要合并）有无数分支，这些分支必须在完成所有分支时，保留或存在于合并中回购。
那么如何处理这个一般情况呢？顺便说一句，我们使用Smartgit进行大部分的git工作。
答案 0 :(得分：1)
我认为您的一些担忧是基于对git如何组织其信息的误解。不过，我同意，一个可靠，可重复的计划将是一个非常好的主意。
首先要做的事情是：您可以收集每个仓库中的所有对象，自动组合重叠，并且所有引用都存在，只需对右侧遥控器进行一次提取即可。
git init
git remote add origin
git remote add dept_A_fork
git remote add dept_B_fork
git fetch --all
现在，每个远程的每个分支都有一个本地仓库。您有origin/master，dept_A_fork/master，dept_B_fork/master。如果dept_B_fork只有feature_XYZ分支，则您有dept_B_fork/feature_XYZ。
这些分支中的每一个都有完整的历史记录。如果他们共享历史记录，他们已经共享了所有常见的对象（包括提交）。如果有人分叉dept_B_fork，他们可以将这个新的仓库重新命名为遥控器，他们将找到他们所需的一切，以提供其本地分支所在的上游历史记录。
从那里你需要的是约定。对于所有回购都有分支的情况，你想做什么？将它们合并在一起并使其成为“本地”参考？你当然可以。可能需要进行大量的冲突解决和测试。
仅在某些回购中出现的分支怎么样？你可以只是离开远程引用，但假设这将成为One True Remote，当你完成时我会找到一种方法将所有内容重新映射到本地分支。因此，远程参考refs/remote/dept_B_fork/custom_branch可能会成为本地参考refs/heads/dept_B_fork/custom_branch（其中有一个小名称空间）。
基本规则，因为你担心叉子的叉子并保持它们的有效性，不要改变任何东西。不要挑选。不要使用filter-branch。不要做壁球合并。不要做任何会以任何方式移动任何引用的东西，使它不再达到它曾经达到的提交。
（如果你真的知道你在做什么，那么其中一些规则可能会有点过分，但是要遵循它们，你应该没有问题。）
这并不意味着没有人会头疼。他们必须弄清楚如何将他们的跟踪信息映射到您的新超级远程，因为dept-B-fork和fork-of-dept-B-fork之间的映射规则将不再适用。但那并不是那么糟糕;至少历史就在那里，你已经离开了分支机构（尽管可能有一个新名字）。 （关于跟踪信息重新映射的唯一方法，顺便说一下，如果你知道总是，从每个分支，可以将具有相同名称的分支合并在一起，以在新的仓库中创建该名称的分支，而不管是什么组合你的叉子有那个分支。）
（你可以判断你是否确实避免了所有的麻烦;如果是这样的话，你将能够干净地将任何分支推送到任何远程的相应分支（如果存在），没有--force / { {1}}选项。）
无论如何，一旦所有内容都反映在本地分支中，您就可以
-f创建合适的原始仓库