git - 使用 git flow 发布时，我应该如何更新 pom.xml 中的版本？

Question

在maven项目中，项目的版本包含在<version>中。 pom.xml 文件的属性。在 git 流模型中创建新版本时，我需要修改版本号。 This article解释这是如何完成的(没有 maven):

1. 创建发布分支
2. 修改版本号并提交
3. merge 发布分支以开发和掌握

另外它说:

It is exactly at the start of a release branch that the upcoming release gets assigned a version number—not any earlier. Up until that moment, the develop branch reflected changes for the “next release”, but it is unclear whether that “next release” will eventually become 0.3 or 1.0, until the release branch is started. That decision is made on the start of the release branch and is carried out by the project’s rules on version number bumping.

我在这里看到两个与 maven 相关的问题:

1. maven 正在开发的版本是[下一个版本]-SNAPSHOT。所以我们不能真正推迟到创建发布分支时才决定下一个版本。当然，如果我们稍后可以改变主意，但我们已经需要在此之前输入/some value/。
2. 在创建我们的版本之前，pom.xml 中的版本假设为 1.1-SNAPSHOT .现在我们将其更改为简单的 1.1在发布分支上并将其 merge 到 master 中。美好的。但是我们还应该将该分支 merge 回 develop 并且为此我们需要调整版本以例如1.2-SNAPSHOT .也许我们不应该在发布分支上这样做，因为该提交不应该是发布的一部分。实际上，我们可能应该在开发分支后立即进行此更改，因为所有 future 对开发的提交都将针对下一个版本。

在谷歌上搜索这个问题时，我发现了一些关于可以自动执行该过程的 maven 插件的文章，这可能很有趣，但这个问题实际上是关于 git 图应该是什么样子以及版本 bump 提交应该在哪里而不是在哪里我如何使用 maven 插件自动执行此操作。

Answer 1

对于正常发布，只需在 merge 发布分支后进行快照版本提升:

1. 从 develop 创建发布分支并从版本中删除快照
2. merge 到master
3. merge 到develop
4. 将develop 上的版本更改为下一个快照版本
5. 同时推送 master 和 develop

当您同时推送所有更改时，团队只会看到快照版本增加。

对于修补程序，这是不可能的，因为您是在 master 分支上创建的。这种情况有一个解决方法，这里是一个使用原始 git 命令的示例。

示例:您在 master 上有 1.0.0 并且想要创建一个 1.0.1 修补程序版本。您的开发已经在 1.1.0-SNAPSHOT。

1. git checkout master
2. git checkout -b hotfix/1.0.1
3. 制作你的修补程序!
4. mvn versions:set -DnewVersion=1.0.1
5. git commit -a -m "hotfix release 1.0.1"
6. git checkout master
7. git merge hotfix/1.0.1(很简单，因为我们创建了 master 分支)
8. git checkout develop
9. mvn versions:set -DnewVersion=1.0.0
10. git commit -a -m "避免 merge 冲突的解决方法"
11. git merge hotfix/1.0.1(由于之前的提交，将会工作)
12. mvn versions:set -DnewVersion=1.1.0-SNAPSHOT
13. git commit -a -m "将版本设置回 1.1.0-snapshot"

不是很好，但它有效。 jgitflow(一个支持 git flow 的 Maven 插件)也使用了这个解决方案。

一个不错的选择 永远不要在 pom.xml 中提交版本更新，而是在您的构建在 CI 服务器上运行之前设置它。示例 CI 管道:

1. 检查分支机构
2. 从分支名称中导出发布版本并使用内部版本号或时间戳丰富它，例如对于 release/1.0.1 的构建 42，它将是 1.0.1-42
3. 使用mvn versions:set -DnewVersion=1.0.1-42设置版本
4. 构建版本并发布

版本号不会那么纯粹，但您永远不会再有 merge 冲突，并且您始终可以将版本追溯到它的构建。