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

Question

对于包含多个类库的 .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 版本，因为这些更改还需要合并到发布分支中。所以主分支总是会过时。

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

如果我使用 SourceTree 检查 asp.net core 的分支图，我会发现

main

分支实际上从未合并到

release/6.0

和

release/7.0

分支中，但提交仍然最终位于这些分支上分支机构：

main分支中的

version

更改为

8

，但这些更改不会传播到其他发布分支。

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

编辑

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

问题：

• 那么发布过程何时/何处将

  0.0.0-PLACEHOLDER

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

在我看来，我必须更改主服务器上的版本（+依赖项的版本），并标记合并到发布分支时要跳过的提交...但这可行吗？

Answer 1

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

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

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

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

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

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