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

Question

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

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

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

方法1

1. //主干中的版本信息：“ SNAPSHOT”
2. git checkout -b版本/1.11
3. //更新发行分支上的版本并提交
4. //构建完整的项目并发布
5. git checkout master
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 checkout master
8. //继续使用功能

第二种方法是在存储库的历史记录中保留一次提交，我不确定该如何处理。后一种方法使代码更具可追溯性，并且释放过程更简单。

顺便提一句，我不太关心错误修正等问题。我们确实发布了新版本。但是，如果需要修补程序，我们计划选择

Answer 1

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

1. //中继中的版本信息：“ SNAPSHOT”，未经开发人员编辑，仅在本地构建时使用
2. 每按一次主干，您的CI工具就会构建并运行所有测试，并创建一个可发布的软件包。在执行任何操作之前，CI工具会将SNAPSHOT版本替换为某个唯一的版本号（请参见下文）。永远不会提交此版本更改，它仅用于构建。为了便于追溯，CI工具可以将唯一版本添加为指向提交的git标签（如果要从git信息中获取唯一版本号，则并非必须这样做，如下所述）

这样，您提交到主干的所有内容都是潜在发行版，除了注明发行给客户的唯一版本之外，无需执行其他任何过程。

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

• 真正独特（由于哈希）
• 容易被人解释和比较（感谢日期）
• 可复制（由于使用了git信息）