git - 何时将大型 Git 存储库拆分为较小的存储库？

Question

我正在努力从 SVN 迁移到 Git。我已经使用 git-svn 将历史记录放入单个 git 存储库中，并且我已经知道如何使用 git-subtree 将该存储库拆分为更小的存储库。这个问题不是怎么迁移，而是什么时候拆分，什么时候不拆分。

我想拆分大型存储库，因为其中一些目录是独立的库，也与其他项目共享。以前 svn checkout 是在库上完成的，而不需要 checkout 整个项目。在所有这些过程中，我发现可能有几十个目录在它们自己的存储库中是有意义的，因为它们 1) 独立并且 2) 跨项目共享。

一旦您超越了少数几个 git 存储库，使用一种工具可以更轻松地处理许多存储库似乎是明智的。一些示例是 Google 的 repo、git submodules、git subtree 和创建自定义脚本(似乎是 Chromium 执行此操作)。我探索了这些不同的方法，并了解如何使用它们。

所以问题是关于颠覆的方向。

我应该尝试坚持使用一个大型 git 存储库，仅在绝对必要时将其拆分为较小的部分，还是应该将其拆分为数十个或可能数百个较小的存储库？哪个更容易工作和？我错过了另一种解决方案吗？如果要使用许多存储库，我应该使用哪个工具？哪些因素会使人们更喜欢一种方法而不是另一种方法？

注意:需要在 Windows、MacOS 和 Linux 上 check out 源。

Answer 1

该过程可以由 component approach 指导，您在其中标识了一组连贯文件(一个应用程序、一个项目、一个库)

就历史而言(在源代码控制工具中)，一个连贯集意味着它将被标记、分支或 merge 为一个整体，独立于其他文件集。

对于分布式版本控制系统(如 git)，这些文件中的每一个都适合用于自己的 git 存储库，然后您可以将您需要的那些文件分组以用于特定的父 repo 中的项目 submodules .

我在中描述了这种方法；

• "Git repository setup for a project that has a server and client "(服务器和客户端是两个明显连贯的独立集合，它们受益于拥有自己的 repo)
• "What is Component-Driven Development? "

相反(将所有内容保存在一个存储库中)称为“system-based approach”，但会导致巨大 Git 存储库，正如我在“Performance for Git”中提到的那样，它不是与 Git 的实现方式兼容。

---

OP onionjake在 the comments 中询问:

Could you please include more information on the subtleties of identifying components?

此过程(识别“组件”，进而成为 git 存储库)由 software architecture 指导你的系统。
充当独立文件集的任何子集都是其自己的 repo 的良好候选者。它可以是库或 dll，也可以是应用程序的一部分(GUI、客户端与服务器、调度程序……)

每次您识别一组紧密链接的文件(意味着修改一个文件可能会对其他文件产生影响)时，应该有组件的一部分，或者在 git 中，相同的 repo。