Git 如何合并两个存储库

我想建立一些坚如磐石的规则，我们可以使用这些规则来逐步将我们的多重回购合并为单一回购。我以前做过，但只是在一个简单的案例中

我的出发点是

在我们的案例中，我们已经发展了六个左右的回购协议，几个月前，我将其中一个合并成了一个新的，最终我们希望一切都在这个新的协议中，而不会失去历史

让我强调一下，我们在Github中讨论的是一个组织帐户，所有回购协议都是私有的，都是这些回购协议的分支

在一般情况下，我所看到的挑战是，其他人已经分出这些回购协议，并且可能在其分出的分支上也有基本回购协议中不存在的分支

因此，如果我简单地将一个基本回购合并到另一个中，原始回购的分支将变得无效，并且它们仅存在于分支上的内容提交将变得不可用

此外，本文中未讨论多个分支机构的问题，如果要合并的源回购协议有多个分支机构，则这些分支机构必须在所有这些分支机构的言行完成后保留或存在于合并回购协议中

---

那么，在这种一般情况下，如何处理呢？顺便说一句，我们在大部分git工作中都使用Smartgit。

我认为您的一些担忧是基于对git如何组织其信息的误解。尽管如此，我还是同意一个可靠的、可重复的计划将是一个非常好的主意

第一件事：您可以收集每个repo中的所有对象，自动合并重叠，并显示所有引用，只需对正确的遥控器执行一次获取操作即可

git init
git remote add origin
git remote add dept_A_fork
git remote add dept_B_fork
git fetch --all

现在你有了一个本地回购协议，每个远程分支都有。您有origin/master、dept\u A\u fork/master、dept\u B\u fork/master。如果只有dept_B_fork有一个feature_XYZ分支，那么就有dept_B_fork/feature_XYZ

所有这些分支都有完整的历史记录。如果他们共享了历史记录，那么他们已经共享了所有常见的对象，包括提交。如果有人分叉了dept_B_fork，他们可以远程重新指向这个新的回购，他们将找到所有需要的东西，以提供其本地分支机构扎根的上游历史

从那里你需要的是惯例。对于所有回购协议都有分支机构的情况，您希望如何处理？将它们合并在一起，使其成为本地引用？当然可以。可能涉及大量冲突解决和测试

那么只在某些回购协议中发生的分支机构呢？您可以只保留远程引用，但假设完成后这将是一个真正的远程引用，我会想出一种方法将所有内容重新映射到本地分支。因此，远程ref-refs/remote/dept_B_fork/custom_分支可能会变成一个本地ref-refs/heads/dept_B_fork/custom_分支，其中有一点名称空间

最重要的规则是，因为你担心你的叉子的叉子，并保持它们的有效性，所以不要重新设置任何东西的基准。不要采摘樱桃。不要使用过滤器分支。不要做壁球合并。不要做任何会移动任何ref的事情，因为这样做会使它不再到达它用来到达的commit

如果你真的知道自己在做什么，这些规则中的一些可以说是过火了，但是遵循它们，你应该没有问题

这并不意味着没有人会头痛。他们必须弄清楚如何将他们的跟踪信息映射到新的uber remote，因为dept-B-fork和fork-of-dept-B-fork之间的映射规则将不再正确。但这并不坏；至少历史都在那里，你已经留下了分支，尽管可能有一个新的名字。另外，重新映射跟踪信息的唯一方法是，如果您知道，在每个分支中，具有相同名称的分支始终可以合并在一起，以在新回购中创建具有该名称的分支，而不管您的分支的组合是什么

你可以知道你是否真的避免了所有的头痛；如果是这样的话，您将能够干净地将任何分支推送到相应的分支（如果任何远程分支中存在），而不使用-force/-f选项

不管怎样，一旦一切都反映在本地分支机构中，您就可以

cd ..
git clone --mirror repo-I-just-made new-origin

---

创建正确的原始回购

除非此处的合并意味着重写相关历史，否则为什么分叉会变得不可用？内部的提交在合并到最终存储库中时与它们最初从中派生出来时一样有效。我不喜欢那篇文章中概述的过程。它以目录作为分支的工作结束。唯一有意义的是，如果你正在合并的回购协议是独立的项目——在这种情况下，将它们保留在独立的回购协议中。我应该注意，根据你的描述，我假设所有回购协议都有一些共同的历史——一个是另一个的分支，等等。如果这不是真的，然后，将所有对象提取到一个repo将创建一个多根repo。这不一定不好，但如果/w 当你试图合并这些历史时。