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

Question

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

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

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

方法#1

1. // trunk 中的版本信息: 'SNAPSHOT'
2. git checkout -b 版本/1.11
3. // 更新发布分支上的版本并提交
4. // 构建完整的项目并发布
5. git 结账大师
6. // 继续特性

方法#2

1. // 主干中的版本信息: '1.11-SNAPSHOT'
2. git 分支发布/1.11
3. // 将 master 分支上的版本更新为 1.12-SNAPSHOT'
4. git checkout 版本/1.11
5. // 将发布分支上的版本更新为“1.11”并提交
6. // 构建完整的项目并发布
7. git 结账大师
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 信息）