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

Question

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

36

在Maven项目中，项目的版本包含在pom.xml文件的<version>属性中。在Git Flow模型中创建新版本时，我需要升级版本号。这篇文章解释了如何做到这一点（不使用Maven）：

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

此外，它还指出：

正是在发布分支的开始，即将来的发布才被分配一个版本号——之前没有。在那个时刻之前，开发分支反映了“下一个发行版”的变化，但尚不清楚该“下一个发行版”最终会成为0.3还是1.0，直到发布分支启动。该决定在发布分支的开始时进行，并由项目关于版本号升级的规则执行。

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

Maven中正在开发的版本将会是[next version]-SNAPSHOT。因此，我们不能真正推迟决定哪个版本是下一个版本，直到我们创建了一个发布分支。当然，如果我们以后改变主意，但我们已经需要更早地输入/一些值/。
在创建我们的发布之前，在pom.xml中的版本是1.1-SNAPSHOT。现在，我们已经将其更改为简单的1.1，并将其合并到主分支。很好。但我们还应该将该分支合并回开发分支，为此，我们需要将版本适应为例如1.2-SNAPSHOT。可能我们不应该在发布分支上这样做，因为该提交不应该成为发布的一部分。实际上，我们可能应该在从develop分支分支之后立即进行此更改，因为develop的所有未来提交都将是下一个版本的。

在搜索问题时，我找到了一些关于可以自动化处理此过程的maven插件的文章，这可能很有趣，但这个问题确实关注于git图形应该如何看起来以及版本升级提交应该在哪里，而不是我如何使用maven插件自动化此过程。

- yankee

1

升级到最新版本（Just ++ to version）。
合并到 develop 分支，然后更改版本。使用一些 gitflow maven 插件会比手动操作更好。

- Aleksandr M

4个回答

3

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

对于Maven，您应该创建一个发布分支，其中包含下一个版本的快照版本。此更改应该是单个提交（即仅在pom.xml中更改版本号）。合并后，切换到master并使用git merge --strategy=ours <release-branch> --strategy = ours 的意思是：通过说“master中的所有内容已正确地与发布分支合并”来进行合并；不对master进行任何更改。之后，Git将把这些分支视为已合并（即没有更改），尽管两个分支中有不同的版本号。

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

当您发布时，请从发布分支中删除-SNAPSHOT，并进行提交。然后，您再次切换到master并使用--strategy=ours进行合并。

注意：如果您这样做，则不能在发布分支上进行任何其他更改，除了更改版本之外。任何其他热修复都将丢失！您只能挑选它们。

- Aaron Digulla

1

警告：在进行Maven发布之前，必须将任何错误修复合并（或精选）到主分支中。发布分支和主分支之间唯一的区别必须是版本号。 - David W

我认为 --strategy=ours 是一个不好的想法。使用 Gitflow 时，您会在主分支上进行热修复（通过将热修复分支合并到开发和主分支上...），因此您可能会丢失热修复修改！ - Thibaud Sowa

1

使用Maven时，不应手动更改版本号。您应该将"scm"信息添加到pom中，以便让Maven直接提交和推送版本更改。然后，使用"release plugin"。它会为您完成工作。假设您当前的版本是"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。

- Benoit Courtine

5

Maven发布插件不支持GitFlow。 - Aleksandr M

1

在使用Maven时，版本命名约定是一个很大的限制（当与内部工件库一起使用时）。因此，我更喜欢使用Maven约定/插件来管理项目，并调整gitflow以适应这些Maven限制。经过测试几个可能的选项后，我认为这是最好的折衷方案。 - Benoit Courtine

@BenoitCourtine 我们如何在热修复中使用发布插件。因此，在热修复中，我们从主分支中获取一个新的分支，增加版本号并合并到主分支。同一分支被合并到dev，并手动提高了dev pom.xml中的版本号。 - unnik

1

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

- numéro6

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- chris · Accepted Answer

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

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

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

对于热修复，这是不可能的，因为它是在master分支之外创建的。但是，针对这种情况有一个解决方法，以下是使用原始git命令的示例。

示例：你在master上有1.0.0，想要创建1.0.1的热修复版本。你的develop已经是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设置版本
构建并发布版本

版本号可能不会很纯粹，但您将永远不会再遇到合并冲突，并且您始终可以追踪版本到其构建。