.NET多类库项目Git分支策略与版本管理优化咨询

当前分支策略及问题 #

管理包含多个类库的.NET项目时，采用如下Git分支策略：

feature 1
             +------------+
           ^/              \
  master   /                v
----------+-+---+---------- PR ----+------+-----------
             \   \                  \      \
              \   v  release/7.0     \      v
               \  +------------------ \ ----+--------- 从master分支创建该分支，将"version"设为7.0.0、7.0.1…，aspnetcore包版本也指向7.x.x
                \                      \
                 v  release/6.0         v
                 +----------------------+------------- 从master分支创建该分支，将"version"设为6.0.0、6.0.1…，aspnetcore包版本也指向6.x.x

该策略存在明显问题：无法在master分支正常更新.NET版本，因为此类版本变更需同步合并至所有release分支，导致master分支始终滞后。曾了解过GitFlow，但不清楚它如何解决master分支版本变更需合并至所有release分支的问题。

参考ASP.NET Core分支策略 #

通过SourceTree查看ASP.NET Core的分支图，发现main分支从未合并至release/6.0和release/7.0分支，但提交仍会出现在这些分支上：

main分支已将版本改为8，但该变更未同步到其他release分支。

补充说明：参考Angular分支策略 #

观察Angular项目的分支图发现，main分支的提交无需合并即可同步至release分支，且提交时间仅差2秒，并非手动cherry-pick：

核心疑问 #

• 发布流程何时/何地将0.0.0-PLACEHOLDER替换为实际版本？版本来源是什么？该阶段如何映射对应依赖版本？
• Angular/ASP.NET Core等项目是否使用GitFlow？它们如何同时管理多个主版本？
• 版本号的来源是什么？

个人推测方案 #

是否可以在master分支修改版本及依赖版本，并标记此类提交在合并至release分支时跳过？该方案是否可行？

补充说明2 #

LinkedIn在其开发博客发布文章，介绍了一款可自动执行cherry-pick操作并创建PR的应用，同时也存在相关的GitHub Actions；Google也推出了用于将提交cherry-pick至release分支并创建PR的GitHub Bot。

内容的提问来源于stack exchange，提问作者Pieterjan