.NET 主要版本和发布分支的 git 分支策略

对于包含多个类库的 .NET 项目，我当前使用以下 git 分支策略：

                feature 1
             +------------+
           ^/              \
  master   /                v
----------+-+---+---------- PR ----+------+-----------
             \   \                  \      \
              \   v  release/7.0     \      v
               \  +------------------ \ ----+--------- I branched from master and set the "version" to 7.0.0, 7.0.1, ... The aspnetcore package versions also point to 7.x.x
                \                      \
                 v  release/6.0         v
                 +----------------------+------------- I branched from master and set the "version" to 6.0.0, 6.0.1, ... The aspnetcore package versions also point to 6.x.x

但是，这样做会阻止我在主分支上正确更新 .NET 版本，因为这些更改还需要合并到发布分支中。所以 master 分支总是会过时。

我读过有关 GitFlow 的内容，但我不清楚这如何解决主分支中的版本更改合并到所有发布分支的问题。

如果我使用源树 https://www.sourcetreeapp.com检查分支图ASP.NET核心 https://github.com/dotnet/aspnetcore，我看到main分支实际上从未合并到release/6.0 and release/7.0分支，但提交仍然最终在这些分支上：

The version https://github.com/dotnet/aspnetcore/blob/main/eng/Versions.props#L9被改变在main分支到8，但这些更改不会传播到其他发行分支。

我过去已经阅读过一些资源，但无法得到答案。 那么我该如何正确组织我的 git 存储库以便以正确的方式进行版本控制呢？

EDIT

看来对于angular https://github.com/angular/angular，主分支上的提交最终会出现在发布分支中，而不会实际合并它们。但我想知道他们是如何做到这一点的。提交时间戳相隔 2 秒，所以我认为他们不会手动挑选它

问题：

• 那么发布流程何时/何处替换0.0.0-PLACEHOLDER与实际版本，它来自哪里？另外，他们如何在该阶段映射相应的依赖版本？
• 是 Angular/asp.net core/... 使用git-flow？或者他们如何管理彼此相邻的多个主要版本？
• 版本号从哪里来？

在我看来，我必须更改主服务器上的版本（+依赖项的版本），并且标记合并到发布分支时要跳过的提交 https://stackoverflow.com/questions/727994/git-skipping-specific-commits-when-merging……但这可行吗？

EDIT 2

LinkedIn 发布了一条关于这一点，它指向一个应用程序来自动挑选并创建拉取请求。但 github 上似乎也有一些动作。

甚至谷歌也创建了一个github bot 创建拉取请求 https://github.com/apps/gcp-cherry-pick-bot挑选提交到发布分支

管理分支策略的方法有很多很多。我认为出于您的目的，您可以通过几种方法来处理事情。

精挑细选：每当功能/错误修复进入主版本并应向后移植到现有版本时，明确地将更改选回相关分支。在此模型中，发布分支和主分支永远不会相互合并。这可以完全控制每个分支中最终发生的更改。一个风险是您忘记将更改挑选到所有相关版本中 - 您可能记得将其挑选到release/6.0，但忘记了release/7.0。

对最旧的受影响版本进行更改，然后向前合并：每当发布分支上需要错误修复/功能时，首先将更改合并到最旧的相关版本分支。然后将该发布分支合并到下一个发布分支（即将release/6.0合并到release/7.0）。最后将最新的release分支合并到master中。这避免了挑选，因此可能更简单。此外，很容易检查每个版本是否已完成所有所需的更改 - 每个版本应该在下一个版本之前进行 0 次提交。它的缺点是您必须提前决定要合并到的最旧版本。如果您后来决定要将更改合并到旧版本，那么您最终会挑选对旧版本的原始更改，然后从该版本合并到已经具有该更改的较新版本（因此合并提交为空） ）纯粹是为了让所有版本 0 在下一个版本之前提交。值得注意的是，在此模型中，所有版本号更改都发生在 master 上，因此在采用发布分支后，您将立即增加 master 上的版本。

Gitflow 分支模型既有 master 又有开发，因此需要管理比当前更多的分支，因此对于您的需求来说可能过于复杂。

我建议的两种模型都允许您对 master 进行任意更改，因为您永远不会将 master 合并到任何发布分支中。

祝您选择适合您的分支策略。