Git 子模块 vs Nuget 包 [英] Git submodules vs Nuget packages

问题描述

我们的团队已经尝试使用 git 子模块来实现我们大多数产品共享的一些核心 CRUD 功能.我们还成功地将 Nuget 包(现在自托管)用于一些常见的实用程序.

Our team has experimented with git submodules for some core CRUD functionality shared by most of our products. We have also successfully used Nuget packages (self-hosted now) for some common utilities.

我们的核心功能经常发生变化，以至于保持子模块正确提交被证明是我们预期的更多苦差事.我正在考虑将核心功能从子模块转移到 Nuget 包，但我想知道对包的频繁更新是否会在 Nuget 中更加痛苦.

Our core functionality changes often enough that keeping submodules properly committed is proving to be more of a chore that we expected. I am considering moving the core functionality from a submodule to a Nuget package but am wondering if the frequent updates to the packages would be even more of a pain in Nuget.

在对我们的架构和流程进行这种略微侵入性的更改之前，是否有人对我可能遇到的其他挑战有任何经验和指导?

Does anyone have any experience and guidance as to what other challenges I might encounter before making this slightly intrusive change to our architecture and process?

推荐答案

与任何事情一样，这取决于.您是否考虑过使用单独的 CI 包存储库，其中对核心模块的每次提交都会生成一个 CI 包?

As with anything, it depends. Have you considered using a separate CI package repository where every commit to the core module produces a CI package?

imo 面临的最大挑战是包版本控制，因为 NuGet 尚未完全支持 SemVer(例如预发布版本 + 内部版本号).

The biggest challenge imo is package versioning, as NuGet doesn't support SemVer yet to its full extent (e.g. pre-release versions + build number).

nuget.org 现在支持 SemVer 2.0 包版本.请参阅此规范:https:///github.com/NuGet/Home/wiki/SemVer2-support-for-nuget.org-%28server-side%29

正确使用 SemVer.你通常不知道发布的版本号，所以你的 CI 包版本从最新的稳定版本继续.CI 包本身被视为预发布版本.

Use SemVer properly. You usually don't know the released version number upfront, so your CI package version continues from the latest stable release. CI packages as such are to be considered pre-releases.

例如:2.2.0-CI201209140650(这是 2012 年 9 月 14 日 06:50 为即将发布的 2.2.0 版本拍摄的 CI 版本)<-- 注意:此版本版本仍然可以更改，但总会有更新路径.

E.g.: 2.2.0-CI201209140650 (which is a CI build taken on 2012-09-14 at 06:50 for an upcoming 2.2.0 release) <-- note: this release version can still change, but there's always going to be an update path.

如果采用SemVer v2.0.0，甚至可以采用如下例子:2.2.0-CI.2012.09.14.06.50.

If you adopt SemVer v2.0.0, you can even adopt the following example: 2.2.0-CI.2012.09.14.06.50.

重要说明: nuget.org(以及其他任何 NuGet 服务器/服务，例如 MyGet 或 VSTS)不支持多个包版本仅因构建元数据而异！

Important note: nuget.org (and by extent any other NuGet server/service out there such as MyGet or VSTS) does not support multiple package versions differing only by build metadata!

使用这些约束(以及一些适当的 TeamCity 构建配置)，这对我很有用.所以简而言之，这些都是麻烦:

This has worked for me using these constraints (and some proper TeamCity build configurations). So in short, these are the hassles:

• 正确的版本控制
• 提醒选择正确的包源(将您的 CI pkgs 与预发布和发布分开，尽管从技术上讲您的 CI 包是作为预发布版本控制的)
• 如果预发布标签的字符串排序高于CI"(例如Alpha")，则从 CI pkg 升级到预发布可能会成为问题.在这种情况下:卸载包CI"，然后是安装包Alpha".

• proper versioning
• reminder to select proper package source (keep your CI pkgs separate from pre-releases and releases, although technically your CI package is versioned as a pre-release)
• upgrading from a CI pkg to a pre-release might be an issue if the pre-release tag is string-sorted higher than "CI" (e.g. "Alpha"). In this case: uninstall-package "CI" followed by install-package "Alpha".

希望这会有所帮助！

这篇关于Git 子模块 vs Nuget 包的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！