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

【问题标题】：How should I update the version inside my pom.xml when releasing using git flow?使用 git flow 发布时，我应该如何更新 pom.xml 中的版本？
【发布时间】：2015-05-31 20:21:20
【问题描述】：

在 maven 项目中，项目的版本包含在 pom.xml 文件的 <version> 属性中。在 git flow 模型中创建新版本时，我需要填写版本号。 This article 解释了这是如何完成的（没有 maven）：

创建发布分支
更改版本号并提交
将发布分支合并到开发和主控

另外它说：

正是在发布分支的开始，为即将发布的版本分配了一个版本号——而不是更早的版本。在那之前，develop 分支反映了“下一个版本”的变化，但在发布分支启动之前，尚不清楚“下一个版本”最终会变成 0.3 还是 1.0。该决定是在发布分支开始时做出的，并由项目的版本号调整规则执行。

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

在 maven 中正在开发的版本将是 [下一个版本]-SNAPSHOT。所以我们不能真正推迟下一个版本的决定，直到我们创建发布分支的那一刻。当然，如果我们以后可以改变主意，但我们已经需要在这里输入 /some value/ 了。
在创建我们的版本之前，pom.xml 中的版本假设为1.1-SNAPSHOT。现在我们在发布分支上将其更改为简单的1.1 并将其合并到master。美好的。但是我们也应该将该分支合并回开发，为此我们需要使版本适应例如1.2-SNAPSHOT。也许我们不应该在发布分支上这样做，因为该提交不应该是发布的一部分。实际上，我们可能应该在分支开发后立即进行此更改，因为未来所有关于开发的提交都将用于下一个版本。

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

【问题讨论】：

1) 只需 ++ 到版本。 2）合并开发然后更改版本。并使用一些 gitflow maven 插件，它会比手工做的要好得多。

标签： git maven versioning git-flow

【解决方案1】：

对于普通发布，合并发布分支后做快照版本bump：

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

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

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

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

git checkout master
git checkout -b hotfix/1.0.1
制作您的修补程序！
mvn versions:set -DnewVersion=1.0.1
git commit -a -m "hotfix release 1.0.1"
git checkout master
git merge hotfix/1.0.1（很简单，因为我们创建了 master 的分支）
git checkout develop
mvn versions:set -DnewVersion=1.0.0
git commit -a -m "workaround to avoid merge conflicts"
git merge hotfix/1.0.1（由于之前的提交，将起作用）
mvn versions:set -DnewVersion=1.1.0-SNAPSHOT
git commit -a -m "set version back to 1.1.0-snapshot"

不是很好，但它有效。 jgitflow（一个支持您使用 git flow 的 Maven 插件）也使用此解决方案。

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

结帐分店
从分支名称派生发布版本并使用内部版本号或时间戳来丰富它，例如对于 release/1.0.1 的构建 42，它将是 1.0.1-42
使用mvn versions:set -DnewVersion=1.0.1-42设置版本
构建版本并发布

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

【讨论】：

嗨@chris，在发布期间我们需要进行一些小的更改，因为在环境中检测到的东西......我的意思是，在这个 URL 中解释说，在发布期间可能需要做更改：stackoverflow.com/questions/37010535/…。例如，如果在 nexus 中配置了一个版本不能重新部署，我们应该如何处理？提前致谢
您可以使用新版本号构建新版本。上面描述的不错的替代方法也可以解决您的 Nexus 问题。

【解决方案2】：

请记住，Git 是为 Linux 内核开发的，它有自己的版本规则。

对于 Maven，您应该创建一个发布分支来获取下一个版本的快照版本。此更改应该是一个单一的提交（即只是 pom.xml 中版本号的更改）。合并时，检查 master 并使用 git merge --strategy=ours <release-branch>

--strategy=ours 表示：通过说“master 中的所有内容已正确地与发布分支合并”进行合并；没有对 master 进行任何更改。之后，尽管两个分支中的版本号不同，Git 仍会将分支视为合并（即没有更改）。

为避免在使用 Maven 构建 master 时出现各种问题，请使用像 99.DEV-SNAPSHOT 这样永远不会更改的奇数或非常高的版本号。

发布时，从发布分支中的版本中删除 -SNAPSHOT 并提交。之后，你 checkout master 并再次与--strategy=ours 合并。

注意：如果您这样做，您不能在发布分支上进行任何其他更改，而是更改版本。任何其他修补程序都将丢失！你只能挑选它们。

【讨论】：

警告...在发布 maven 之前，您必须合并（或挑选）任何要掌握的错误修复。 release-branch 和 master 之间的唯一区别必须是版本号。
我认为--strategy=ours 是个坏主意。使用 gitflow，您可以在 master 分支上进行修补程序（通过合并开发和 master 上的修补程序分支......），这样您就可以放松修补程序修改！

【解决方案3】：

您可以使用jgitflow-maven-plugin：目标jgitflow:release-start 和jgitflow:release-finish。

【讨论】：

【解决方案4】：

使用 Maven，您应该不手动更改版本号。

您应该将“scm”信息添加到您的 pom 中，以便让 Maven 直接提交和推送版本更改。

然后，使用“发布插件”。它将为您完成工作。假设您当前的版本是“1.1-SNAPSHOT”，“release:perform”maven 任务将：

将版本更改为 1.1，提交，标记此版本并推送。
再次将版本更改为1.2-SNAPSHOT（或1.1.1-SNAPSHOT、2.0-SNAPSHOT……您可以选择下一个版本），提交并推送。

以下是使用 Maven 发布插件的项目的 git 历史摘录：

* 2345678 - Normal developpement commit (on branch 1.2-SNAPHOT).
* 5678901 - [maven-release-plugin] prepare for next development iteration
* 8901234 - (tag: 1.1) [maven-release-plugin] prepare release 1.1
* 1234567 - Normal developpement commit (on branch 1.1-SNAPHOT).

注意 1：在发布时，您必须配置下一个版本（本例中为 1.2）。如果你改变主意，你可以在以后改变它。 Maven "version:set-version" 插件允许您重新分配所有项目层次结构的版本。您只需在下一个版本之前提交此版本更改。

注意2：在发布时，您也可以更改发布版本。即使当前版本是 1.1-SNAPSHOT，您也可以决定发布是 2.0 版本，下一个开发版本是 2.1-SNAPSHOT。

【讨论】：

Maven 发布插件不做 gitflow。
在使用 Maven 时，版本命名约定是一个很大的限制（当与内部工件存储库一起使用时）。所以我更喜欢使用 Maven 约定/插件来管理项目，并调整 gitflow 以适应这些 Maven 约束。在测试了几个可能的选项后，我认为这是最好的折衷方案。
@BenoitCourtine 我们如何使用发布插件进行修补程序。因此，对于修补程序，我们从 master 获取一个新分支，提升版本并合并到 master。同一个分支被合并到 dev 上，dev pom.xml 版本被手动提升。