我刚刚开始拆分包含所有产品代码的Git存储库，其中包括共享库，服务器，客户端和工具代码。
作为消除我们对DCVS的一些技术债务的一部分，我们建议将我们的共享客户端和服务器库移动到Nuget存档，该存档将严格控制开发和发布分支上的推送权限促进我们一直懒散的拉动请求。
分裂部分没什么大不了的;我根据自己的喜好定制了git filter-branch关于历史保留的内容，现在正在研究如何将存储库重新组合在一起。
目前，在我准备打包它们之前（以及正确的单元测试等），这些库并不是完全清晰，需要进行一些重构，并且希望能够对库进行更改。两个存储库，重点是代码审查，作为中短期解决方案。
我已经阅读了足够多的git subtree和git submodule来了解他们的相对优势和劣势，但仍然对于该做什么感到矛盾。虽然绝大多数资源都反对使用git submodule，因为它对那些不知道如何使用它的人很脆弱（有罪！），它的替代git subtree似乎缺乏明确的引用功能我我正在寻找。
如果有人有类似我正在寻找的设置，或者有不同的工作流程，你能评论一下吗？我将离开并测试这两种策略，同时我等待咬一口，并希望有更高的评估。
答案 0 :(得分：2)
我们最近从更传统的版本控制系统转移到Git。在我开始之前很久，我们已经习惯了将库检入版本控制。显然这在Git中不起作用，在其他VC中也不是一个好主意。所以我们遇到了类似的选择。在审查了子树和子模块之后，我们决定不使用它们。我们有多个克隆为同行的存储库：
<some folder>
|
+ <repo1>
|
+ <repo2>
|
+ <repo3>
|
+ <packages>
我们还使用Nuget来处理我们的库（注意我们用C和C ++开发而不是.Net）。 Nuget适用于本地图书馆，我们还没有找到替代方案。这个过程比我想要的手动更多，但它确实避免了一整套有趣的＆＃34;似乎困扰子模块和子树的问题。
希望有所帮助。