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

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

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

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

方法#1

//中继中的版本信息：“快照”

git签出-b发行版/1.11

//发布分支和提交时更新版本

//构建完整的项目并发布

git签出主机

//继续使用功能

方法#2

//中继中的版本信息：“1.11-SNAPSHOT”

git分支版本/1.11

//将主分支上的版本更新为1.12-SNAPSHOT'

git签出版本/1.11

//将发布分支上的版本更新为“1.11”并提交

//构建完整的项目并发布

git签出主机

//继续使用功能

第二种方法在存储库的历史记录中只留下一个提交，我不知道该如何感觉。后一种方法使代码更易于跟踪，发布过程也更容易

---

顺便说一句，我不太关心错误修复等问题。我们确实发布了一个新版本。但是，如果需要热修复程序，我们计划挑选而不是创建发布分支来更新版本，以真正的CI/CD方式将每个提交都视为可发布的

//主干中的版本信息：“快照”，开发人员从不编辑，仅在本地构建时使用

每次推送到主干时，CI工具都会构建并运行所有测试，并创建一个可发布的包。在执行任何操作之前，CI工具将快照版本替换为某个唯一的版本号（请参见下文）。此版本的更改从未提交，只是用于构建。为了便于跟踪，CI工具可以将唯一版本添加为指向提交的git标记（如果唯一版本号可以从git信息派生，则这不是严格要求的，如下所述）

通过这种方式，您对主干的所有承诺都是潜在的版本，并且除了记录作为发布的一部分交付给客户的唯一版本之外，没有其他流程

关于唯一的版本号我通常让CI工具代替快照版本，使用类似于

-

的工具，这样做的好处是

• 真正独一无二（多亏了散列）
• 很容易被人解释和比较（由于日期）
• 可复制（由于使用git信息）

---

谢谢。我喜欢这种方法。我也在考虑类似的方式，取分支名称，并将其部分作为人类可读的发布版本。但是我更喜欢你的

-

。我将尝试一下，一旦实现工作正常，我将接受我一直坚持的答案

-

；我还以博客的形式总结了这一点，其中包含Maven构建脚本片段（），以保持问题语言的独立性。谢谢