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

问题描述

我们的团队已经对git子模块进行了试验，以获得大部分产品共享的一些核心CRUD功能。我们还成功地将Nuget软件包（现在自行托管）用于一些常用实用程序。

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

任何人都有任何经验和指导，可以在对我们的体系结构和流程进行稍微侵入式改变之前遇到哪些其他挑战？ 解决方案

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

不支持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 （这是CI版本将于2012年9月14日在06:50发布，用于即将发布的2.2.0版本）< - 注意：此版本版本仍然可以更改，但始终会有更新路径。

如果您采用SemVer v2.0.0，您甚至可以采用以下示例： 2.2.0-CI.2012.09.14.06.50 。

重要说明： nuget.org（以及其他任何NuGet服务器/服务，例如MyGet或VSTS）不支持多个包版本只有构建元数据才有区别！

这对我使用这些约束（以及一些合适的TeamCity构建配置）非常有用。
简而言之，这些都是麻烦：

• 正确的版本控制


• 提醒您选择正确的包源（尽管从技术角度讲，您的CI包是作为预发布版本进行版本化的）（请将您的CI包与预发行版和发行版分开）
$ b如果预发布标签的字符串排序高于CI（例如Alpha），则$ b
• 从CI pkg升级到预发布可能会造成问题。在这种情况下：uninstall-packageCI后跟安装包Alpha。

希望这会有所帮助！

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.

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?

解决方案

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?

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).

EDIT: nuget.org now supports SemVer 2.0 package versions. See this spec: https://github.com/NuGet/Home/wiki/SemVer2-support-for-nuget.org-%28server-side%29

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.

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.

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

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!

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

• 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".

Hope this helps!

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