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

Question

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

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

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

方法 #1

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

方法 #2

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

第二种方法在存储库的历史记录中留下一个提交，我不确定如何看待它。后一种方法使代码更易于跟踪，发布过程也更容易一些。

附带说明一下，我不太关心错误修复等。我们确实发布了一个新版本。但如果需要修补程序，我们计划 cherry-pick

Answer 1

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

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

通过这种方式，您向主干提交的所有内容都是潜在版本，除了记下交付给客户的唯一版本外，没有其他过程需要作为版本的一部分完成.

关于唯一版本号 我通常让 CI 工具将 SNAPSHOT 版本替换为类似 <git commit date>-<short git commit hash> 的版本，它具有 [=11] 的优点=]

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