git - 使用 Git 和 Nuget 管理内部共享库

Question

我刚刚开始拆分我们的 Git 存储库，该存储库包含我们所有的产品代码，其中包括共享库、服务器、客户端和工具代码。

作为消除我们与 DCVS 的一些技术债务的一部分，我们提议将我们的共享客户端和服务器库移动到一个 Nuget 存档，该存档将严格控制对开发和发布分支的推送权限以强制促进我们一直松懈的 pull 请求。拆分部分没什么大不了的；我根据自己的喜好定制了 git filter-branch 来保留历史记录，现在我正在研究如何将存储库拼接在一起。

目前，这些库还不是完全明确的，在我准备好打包它们之前需要进行一些大量的重构(以及适当的单元测试等)，并且希望能够对这两个存储库都强调代码审查，作为中短期解决方案。

我已经阅读了足够多的关于 git subtree 和 git submodule 的文章，以了解它们的相对优势和劣势，但我仍然对如何做感到矛盾。虽然绝大多数资源反对使用 git submodule 因为它对那些不知道如何使用它的人来说很脆弱(有罪!)，它的替代品 git subtree 似乎缺乏我正在寻找的显式引用功能。

如果有人的设置与我正在寻找的类似，或者类似的工作流程以不同的方式完成，您可以评论一下吗？我将在“等一口”的同时离开并测试这两种策略，并希望获得更高的评估。

Answer 1

我们最近从更传统的版本控制系统迁移到 Git。早在我开始之前，我们就养成了将库 checkin 版本控制的习惯。显然这在 Git 中效果不佳，在其他 VC 中也不是一个好主意。因此，我们遇到了与您类似的一组选择。在审查了子树和子模块之后，我们决定两者都不使用。我们有多个存储库被克隆为对等体:

  <some folder>
             |
             + <repo1>
             |
             + <repo2>
             |
             + <repo3>
             |
             + <packages>

我们还使用 Nuget 来处理我们的库(请注意，我们使用 C 和 C++ 而不是 .Net 进行开发)。 Nuget 对于 native 库来说已经足够好了，我们还没有找到替代方案。这个过程比我想要的要手动得多，但它确实避免了似乎困扰子模块和子树的一整套“有趣”问题。

希望对您有所帮助。