GitFlow 中的 Maven 版本控制答案

【问题标题】：Maven versioning in GitFlowGitFlow 中的 Maven 版本控制
【发布时间】：2017-11-18 16:57:12
【问题描述】：

Git Flow 已经存在了很长时间，而且似乎很多人都将它用作他们最喜欢的 git 工作流程。

当谈到在 Java / Maven 设置中实现 Git Flow 时，我想知道应该如何对下面所有分支上的软件模块进行版本控制。

在一个简单的 Maven 世界中，

开发人员始终使用 SNAPSHOT 版本（例如：0.0.1-SNAPSHOT）
一些发布过程创建一个发布 (0.0.1)
新的快照版本可供开发人员在 (0.0.2-SNAPSHOT) 上进行开发。

如果你只有一个 Develop 和 Master 分支，这没问题，但是你如何在 GitFlow 中处理 maven 版本控制。

master 上的版本很容易定义，因为它们将是最终从 Release 分支创建和发布的版本。

但是，一旦代码进入发布分支，您会在此处部署什么版本控制策略？

我想我们需要在发布分支上保留一个新的版本号以避免与 Develop 冲突？该版本号将如何与开发分支上的任何内容相关联。
我假设在发布分支上也可以在发布投入生产之前进行多次提交。由于我们不能重复使用非快照版本，我们是在每次提交时增加固定版本，还是在最终确定并推送到 master 之前使用发布快照版本？
当我们将更改从发布分支合并回开发分支时，我们是否会启动新的快照版本？

【问题讨论】：

Maven 看待发布版本的方式早于 git 及其思维方式。使用 git，提交 is 的 sha1-key 版本在您不知道提交时哪个提交将在生产中运行的设置中特别有用。如果您将整个项目放在一个 git 存储库中，那么让 maven 仅使用快照并使用 git commit id 作为您使用的版本。
“人们似乎将其用作他们最喜欢的 git 工作流程”——这并不是因为它很好。但是因为人们不太了解 CI 和现代开发流程，如 CD、JIT、ToC。 GitFlow 是一种非常过时的分支思考方式。有很多更好的选择，今天最著名的方法是基于主干的开发。尽管对于某些团队来说它可能太先进了。在这些团队中，您可能希望从简单的 FeatreBranch->master 方法开始。
@StanislavBashkyrtsev 是的，但是那些仍然每 2 个月左右发布一次并且仍然需要大量手动测试才能投入生产的团队呢？
@JFMeier，稀有版本不会对您使用分支或版本的方式产生太大影响。可能在后备箱中使用 FeatureBranches 而不是 FeatureToggles 更容易（或者可能不使用 - 它会有所不同），但仅此而已。所以 GitFlow 和复杂的版本控制在稀有版本的情况下也没有任何好处。
@StanislavBashkyrtsev 我只是觉得如果你有release 和hotfix 分支，在开发过程中修复生产版本或修复测试版上的错误会更容易。如果发布需要数周的手动测试（和错误修复），那么很难只拥有一个主分支而没有其他任何东西。

标签： java git maven git-flow

【解决方案1】：

对于发布分支，我们应该遵循0.0.1-RC-SNAPSHOT 命名约定。也请探索 mvn jgitlfow 插件。它将提供上述所有讨论的功能。

请包括以下相关性。

   <plugin>
                <groupId>external.atlassian.jgitflow</groupId>
                <artifactId>jgitflow-maven-plugin</artifactId>
                <version>${jgitflow-maven-plugin.version}</version>
                <configuration>
                    <enableSshAgent>true</enableSshAgent>
                    <noDeploy>true</noDeploy>
                    <noReleaseBuild>true</noReleaseBuild>
                    <noFeatureBuild>true</noFeatureBuild>
                    <noHotfixBuild>true</noHotfixBuild>
                    <enableFeatureVersions>true</enableFeatureVersions>
                    <releaseBranchVersionSuffix>RC</releaseBranchVersionSuffix>
                    <allowSnapshots>true</allowSnapshots>
                    <pushReleases>true</pushReleases>
                    <pushHotfixes>true</pushHotfixes>
                    <pushFeatures>true</pushFeatures>
                    <flowInitContext>
                        <versionTagPrefix>v</versionTagPrefix>
                    </flowInitContext>
                </configuration>
            </plugin>

示例指令

mvn jgitflow:release-start

使用 RC 创建一个发布分支并将开发分支 pom 更新到下一个版本

 mvn jgitflow:release-finish

合并发布以掌握和开发并创建标签：大多数情况下，此分支会进行集成测试，任何错误修复都会提交到发布分支，当它关闭时，开发也会在合并时获得更新。

创建一个发布分支，同时更新开发 pom ie before (devlop 0.1-SNAPSHOT) 在 devlop 0.2-SNAPSHOT 之后创建 0.1-RC-SNAPSHOT 的发布分支

https://bitbucket.org/atlassian/jgit-flow/wiki/Home

【讨论】：

【解决方案2】：

在我们的应用程序中，我们使用maven-release-plugin 来更新 pom 文件中的版本。当我们使用像 Jenkins 这样的工具时，每当我们配置 Job 时，我们还可以触发下游作业。所以在我们的例子中，我们有以下设置：

从release 向master 发出拉取请求，构建将在发布时运行，成功后将启用合并。
当合并发生时，jenkins 作业被触发以将 pom 中的版本更新为快照版本。在此之后，触发下游作业以更新 develop 分支中的相同快照版本。

所以，在我们的例子中，每当一个发布经历了两次版本更新时，一次是发布版本被剪切，另一次是快照版本在发布后被合并到 master 和 development 时被剪切。所以，在我们的 master 和 development 发布之后，最终的版本永远是快照版本。对于某些团队，我看到他们只在开发中更新快照版本并将发布版本直接推送到主版本（也就是说，他们从 release 合并到 master 而不将版本更改为快照，并且在下游作业中更改版本合并到develop时进行快照）。

对于您的问题：我假设在发布分支上也可以在发布投入生产之前进行多次提交。由于我们不能重复使用非快照版本，我们是在每次提交时增加固定版本，还是在最终确定并推送到 master 之前使用发布快照版本？

在理想情况下，发布分支不会直接提交。它必须经过开发才能发生。所以，是的，每当您从开发合并到发布时，版本都需要增加，因为它被设置为一个过程。如果您每次增加版本，跟踪错误修复和功能也更容易释放。

【讨论】：

【解决方案3】：

我发现将源代码控制（由 Git 管理）和构建（由 Maven 管理）区域分开很重要。换句话说，管理版本控制和分支应该发生在您的pom.xml 文件之外。它仍然可以通过一些 Maven 插件来实现，但是这个插件不应该是构建过程的一部分 - 它应该是这个过程之外的工具。

话虽如此，看看this description 的Maven 版本。你是对的，当一个发布分支被创建时，一个版本X.Y.Z被“保留”了这个版本（并且develop分支原子地获得递增的快照版本X.Y.(Z+1)-SNAPSHOT或X.(Y+1).Z-SNAPSHOT等取决于什么样的版本是计划下一个）。同时，您的发布分支将存在一段时间，您可能需要在构建之间更改工件的版本以避免冲突。这可以通过同时使用内部版本号或限定符和内部版本号来完成。例如，您可以从X.Y.Z-alpha-0 开始并继续直到您更改为X.Y.Z-beta-0 及以后。每次需要将“预发布”工件部署到存储库时，您都会增加内部版本号。最终，当发布时，您的版本 X.Y.Z 将被 Maven 视为“大于”具有内部版本号和修饰符的所有版本。

【讨论】：

嘿，我目前正在学习 Maven，我在您的回答中发现了一些有趣的东西。你提到-'管理版本控制和分支应该发生在你的 pom.xml 文件之外。由于我对 Maven 的了解有限，如果我们想使用 maven 插件，它们应该被添加到 pom 文件中，以及我们如何使它成为一个外部工具。我目前正在为我的项目使用'gitflow-maven-plugin'，我只能更新版本中的最后一个数字（Z），不知道如何测试和更新X和Y，我也在考虑将它与 Jenkins 结合起来自动完成这个过程，有什么想法吗？
@Cecilia，您仍然可以使用 Maven 来运行某些操作，只需在不同的 pom.xml 文件中执行此操作（您可以为此使用选项 -f）。关键是要遵守关注点分离的原则：将项目的测试和构建功能放在主pom.xml 中，并在另一个文件中发布和分支内容（它也可以在版本控制之外并由一些 Maven 插件交付从命令行调用）。