我们的团队已经尝试使用git子模块来实现我们大多数产品共享的一些核心CRUD功能。我们还成功地使用了Nuget软件包（现在自托管）用于一些常见的实用程序。
我们的核心功能经常发生变化，保持子模块正确承诺证明更像是我们期望的苦差事。我正在考虑将核心功能从子模块移动到Nuget软件包，但我想知道对软件包的频繁更新是否会让Nuget更加痛苦。
在对我们的架构和流程进行这种稍微干扰性的更改之前，是否有任何人对我可能遇到的其他挑战有任何经验和指导？
答案 0 :(得分：3)
与任何事情一样，这取决于。您是否考虑过使用单独的CI软件包存储库，其中每个核心模块的提交都会生成CI软件包？
最大的挑战是包版本化，因为NuGet尚未完全支持SemVer（例如预发布版本+内部版本号）。
编辑：nuget.org现在支持SemVer 2.0软件包版本。请参阅此规范：https://github.com/NuGet/Home/wiki/SemVer2-support-for-nuget.org-%28server-side%29
正确使用SemVer。您通常不会预先知道发布的版本号，因此您的CI包版本将从最新的稳定版本继续。这样的CI包将被视为预发布。
例如：2.2.0-CI201209140650（这是在2012-09-14 06:50为即将发布的2.2.0版本进行的CI构建）＆lt; - 注意：此版本版本仍然可以更改，但是有总是会成为一条更新路径。
如果采用SemVer v2.0.0，您甚至可以采用以下示例：2.2.0-CI.2012.09.14.06.50。
重要提示： nuget.org（以及其他任何其他NuGet服务器/服务，例如MyGet或VSTS）不支持多个包版本仅因构建元数据不同！
这对我使用这些约束（以及一些适当的TeamCity构建配置）起作用。 简而言之，这些都是麻烦：
希望这有帮助！
答案 1 :(得分：2)
我更喜欢使用子模块而不是 Nuget 包来频繁更改内部库。原因如下：
合并：如果多个开发人员同时对同一个库进行更改，使用子模块，则可以合并这些更改。对于 Nuget 包，显然没有合并的概念。
减少等待：对于子模块，您可以推送，然后使用您需要使用子模块的任何存储库进行拉取。通常需要几秒钟。使用 Nuget，您必须等待包发布，通常是在 CI 流程完成之后。
版本冲突：同样，如果多个开发人员同时进行更改，他们可能会将 Nuget 版本号增加到相同的版本，尽管他们的更改不同。要解决多少痛苦取决于您的 CI 流程。
可以在“客户端”存储库中进行更改：有时，在处理将使用库的客户端代码时，最容易充实库更改的详细信息。对于子模块，这是可能的。当然，这不是测试覆盖率的替代品。
答案 2 :(得分：-3)
我不推荐 git 子模块。我知道现在 git 很流行，但从客观的角度来看，git 太复杂了，不能用于基本用途。官方文档通常不清楚，让人想知道并尝试看看高级功能是如何工作的。高级功能的使用也过于复杂和繁琐。
总的来说，我仍在寻找更好的源代码控制选项。 Git 声名鹊起是本地提交，但在实践中，我已经看到 98% 的时间，它就像传统的源代码控制一样使用，在签入代码时更新远程存储库。更新远程也充当备份，而本地回购则没有。唯一的区别是现在，您必须提交和推送。所以，传统上是一步，现在是两步。这不是进步。
我推荐 NuGet。