<分区>
我们的团队已经尝试使用 git 子模块来实现我们大多数产品共享的一些核心 CRUD 功能。我们还成功地将 Nuget 包(现在是自托管的)用于一些常见的实用程序。
我们的核心功能经常更改，以致于正确提交子模块被证明是我们预期的更多苦差事。我正在考虑将核心功能从子模块移动到 Nuget 包，但我想知道频繁更新包是否会在 Nuget 中更加痛苦。
在对我们的架构和流程进行这种稍微侵入性的更改之前，是否有人对我可能遇到的其他挑战有任何经验和指导？
<分区>
我们的团队已经尝试使用 git 子模块来实现我们大多数产品共享的一些核心 CRUD 功能。我们还成功地将 Nuget 包(现在是自托管的)用于一些常见的实用程序。
我们的核心功能经常更改，以致于正确提交子模块被证明是我们预期的更多苦差事。我正在考虑将核心功能从子模块移动到 Nuget 包，但我想知道频繁更新包是否会在 Nuget 中更加痛苦。
在对我们的架构和流程进行这种稍微侵入性的更改之前，是否有人对我可能遇到的其他挑战有任何经验和指导？
最佳答案
我更喜欢使用子模块而不是 Nuget 包来频繁更改内部库。原因如下:
merge :如果多个开发人员同时对同一个库进行更改，通过子模块，这些更改可以 merge 。对于 Nuget 包，显然没有 merge 的概念。
更少等待:对于子模块，您可以推送，然后使用您需要在其中使用子模块的任何 repo 进行 pull 。通常需要几秒钟。使用 Nuget，您必须等待包发布，通常是在您的 CI 过程完成之后。
版本冲突:同样，如果多个开发人员同时进行更改，他们可能会将 Nuget 版本号增加到同一版本，尽管他们的更改不同。要解决的痛苦程度取决于您的 CI 流程。
调试:由于 Nuget 包是经过编译的，因此您不能单步执行它们的代码。
可以在“客户端”存储库中进行更改:有时在处理将使用库的客户端代码时充实库更改的详细信息是最容易的。使用子模块，这是可能的。当然，这不能替代测试覆盖率。
关于Git 子模块与 Nuget 包，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12411929/