基于主干的开发中的发布（版本）提交

Question

我最近一直在研究基于主干的开发 (https://trunkbaseddevelopment.com)，我们所做的工作非常适合这种方法（小团队、频繁发布、一些直接提交或短期分支等）。

我唯一的困难是标记版本。我们进行 CI，但并非所有产品都投入生产，我们希望在代码交付到客户环境后增加（更改）版本。

在主干基础开发中（以惯用的方式）我应该如何发布？你对 master 上的发布提交有什么感觉？我可以看到两种方法（我正在使用 Java + Maven 位，这只是应该出现的工具）。

方法#1

1. //trunk中的版本信息：'SNAPSHOT'
2. git checkout -b release/1.11
3. //在发布分支上更新版本并提交
4. //构建完整的项目并发布
5. git checkout master
6. //继续功能

方法 #2

1. //trunk中的版本信息：'1.11-SNAPSHOT'
2. git 分支发布/1.11
3. //将master分支上的版本更新为1.12-SNAPSHOT'
4. git checkout release/1.11
5. // 将发布分支上的版本更新为“1.11”并提交
6. //构建完整的项目并发布
7. git checkout master
8. // 继续功能

第二种方法会在存储库的历史记录中留下一个提交，我不知道对此有何感受。后一种方法使代码更易于跟踪，并且发布过程更容易一些。

顺便说一句，我不太关心错误修复等。我们确实发布了一个新版本。但如果需要修补程序，我们计划挑选

Answer 1

不要仅仅为了更新版本而创建发布分支，而是以真正的 CI/CD 方式将每个提交都视为可发布。

1. //trunk中的版本信息：“SNAPSHOT”，开发者从未编辑过，仅在本地构建时使用
2. 每次推送到主干时，您的 CI 工具都会构建并运行所有测试并创建一个可发布的包。在执行任何操作之前，CI 工具会将 SNAPSHOT 版本替换为某个唯一的版本号（见下文）。这种版本的更改永远不会提交，它只是用于构建。为了便于追溯，CI 工具可以将唯一版本添加为指向提交的 git 标记（如果唯一版本号如下所述从 git 信息派生，则不是严格要求）

通过这种方式，您提交到主干的所有内容都是潜在的版本，除了记下交付给客户的唯一版本之外，无需将其作为发布的一部分完成。

关于唯一版本号我通常让 CI 工具将 SNAPSHOT 版本替换为 <git commit date>-<short git commit hash> 之类的东西，这样做的好处是

• 真正独一无二（感谢哈希）
• 很容易被人类解释和比较（感谢日期）
• 可复制（感谢使用 git 信息）