我正在从SVN迁移到Git。我已经使用git-svn将历史记录放入单个git存储库中，并且我已经知道如何使用git-subtree将该存储库拆分为较小的存储库。这个问题不是关于如何进行迁移，而是关于何时拆分以及何时不进行拆分。
我想拆分大型存储库，因为某些目录是自包含的库，它们也与其他项目共享。以前在库上完成了svn checkout，无需签出整个项目。在所有这些过程中，我发现可能有数十个目录在自己的存储库中是有意义的，因为它们是1）独立的，2）跨项目共享。
一旦你获得了一些git存储库，使用一个工具可以更容易地处理许多存储库似乎是明智的。一些示例是Google的repo，git submodules，git subtree，以及创建自定义脚本（看起来Chrome就是这样做的）。我已经探索了这些方法，并了解如何使用它们。
所以问题是关于从颠覆过渡的方向。
我应该尝试坚持使用一个大型git存储库，只在绝对必要时将其拆分成更小的部分，还是应该将其拆分为数十个或可能数百个较小的存储库？哪个更易于工作用？还有其他我错过的解决方案吗？如果使用多个存储库，我应该使用哪个工具？哪些因素会让某人偏爱另一种方法？
注意：需要在Windows，MacOS和Linux上签出源代码。
答案 0 :(得分：4)
该过程可以由component approach引导，您可以在其中识别连贯的文件集（应用程序，项目，库）
在历史方面（在源控制工具中），相干集意味着它将被标记，分支或合并为全部，与其他文件集无关。
对于分布式版本控制系统（如git），这些文件集中的每一个都是自己的git仓库的良好候选者，然后您可以将特定需要的文件分组。使用 submodules 在父级仓库中投放。
我在这里描述了这种方法;
相反（将所有内容保存在一个仓库中）称为“system-based approach”，但可以导致巨大的 Git仓库，正如我在“Performance for Git”中提到的那样，与Git的实现方式不兼容。
OP onionjake在the comments中提出要求：
您能否提供更多关于识别组件的细微之处的信息？
此过程（识别“组件”，进而成为git repos）由您系统的software architecture引导。
作为独立文件集的任何子集都是其自己的回购的良好候选者。它可以是库或dll，也可以是应用程序的一部分（GUI，客户端与服务器，调度程序......）
每当你确定一组紧密链接的文件（意味着修改一个文件可能会对其他文件产生影响）时，应该有部分组件，或者在git中，应该有相同的repo。
答案 1 :(得分：2)
我个人喜欢小型回购 - 当你有一个像Composer for PHP这样的良好的依赖管理系统时，它们运行良好。
管理结帐流程并跟踪版本等需要付出痛苦。
它还允许repos由不同的提供商托管。我们使用定制代码和开源代购的组合。
答案 2 :(得分：2)
我想说，如果不是所有的话，大部分时间都使用子树 - 并且可以根据需要自由地制作子树。
有很多依赖项，submodules开始变得痛苦。如果你对这些依赖性的发展有任何影响，那么这种情况就会更加严重。如果你有一个完全没有经常更改版本的第三方库，那么子模块可能没问题，并且你永远不会在大型项目中积极开发。
对于您实际使用的依赖项，子模块与super-repo过于分离。
示例：如果对子模块进行更改，则必须提交子模块，向上推，cd到super repo，将子模块添加到索引/阶段，提交它，然后再次向上推。这是一个工作流程的麻烦。更不用说删除，移动或重命名子模块的麻烦了。
Git子树要好得多。历史交织在一起，但您可以在任何给定的奇思妙想中将目录拆分为子树。如果你决定不再需要某个子树了......只需停止执行子树拆分或推送。
子树的缺点是它们根本没有被跟踪。因此，您必须记住所有路径及其与存储库的关系 - 并且任何其他从事该项目的人员也必须知道如果他们想要执行子树操作。好消息是，大多数开发人员可以处理任何依赖项上的任何代码，而不必担心如何将其推送到那些存储库。另外，正如你所说，一些bash脚本可以自动化手动内容。
答案 3 :(得分：1)
如果您有多个项目的良好重用案例，那么请考虑将其拆分为子项目。在你有两个使用它的项目之前，我会避免创建一个共享项目。
标准我会考虑制作一个子项目回购：
我发现最容易管理的子树，因为我可以将库作为项目的一部分进行开发，然后在需要时将其拆分。
我还想指出，两个项目在公共库上分歧是完全可以的，并且通常更喜欢将它们保持在稳定状态。只要很容易汇总公共代码，我认为采用惰性方法共享库没有坏处。
无论如何，这是解决这个问题的好兆头;这意味着你已经做好了可重复使用的代码。 ：）
答案 4 :(得分：1)
当您在分布式环境中工作，提供git的功能时，如果其他项目使用这些组件或者您打算这样做，则应避免将不同的组件直接分组到单个存储库中。或者，如果它是可能的或可取的，它将来会发生。
这是因为开发人员/贡献者将能够专注于他们的部分，而无需下载他们不会使用/更改的所有其他组件的完整历史记录。如果您与来自互联网速度比我们使用的速度慢的国家/地区的贡献者合作，那么这一点也很重要。
当你尝试并理解各种方法时，你不会被低知识所困扰，这不是一项艰巨的任务。据我所知，你有各种可能的选择。
如果他们以某种方式独立于主存储库，我不会担心会有数十个或可能数百个较小的存储库。拥有如此多的存储库只会增加首次配置新主存储库的时间。
只有当您需要立即迁移＆＃34;时才应该支持大型存储库解决方案。来自颠覆。或者对替代品没有或很少了解的人。
我会使用git subtree，因为它可以使用git作为标准功能：除了git之外，用户不需要安装任何其他内容，并且它将继续保留，直到git将。