GitFlow中的Maven版本控制

Question

Git Flow已经存在很长时间，许多人似乎将其作为最喜欢的git工作流采用。

当在Java / Maven环境中实现Git Flow时，我想知道如何处理位于所有下方分支上的软件模块的版本控制。

在简单的Maven世界中，开发人员总是使用SNAPSHOT版本（例如：0.0.1-SNAPSHOT），某些发布过程会创建一个发布版本（0.0.1），新的快照版本可供开发人员开发（0.0.2-SNAPSHOT）。

如果您只有Develop和Master分支，那么这样做就可以了，但是在GitFlow中如何处理maven版本控制呢？

主分支上的版本定义起来很容易，因为它们最终将从Release分支创建并发布。

但是一旦代码进入发布分支，我们该采用什么版本控制策略呢？

我们需要在发布分支上保留一个新版本号以避免与Develop分支发生冲突。那个版本号与Develop分支上的内容有何关系？

我想，在发布分支上也可能有多个提交，然后才能将发布推向生产环境。由于我们无法重复使用非快照版本，所以我们是否应该在每次提交时增加固定版本，或者在最终完成并推送到主分支之前，也使用发布快照版本？

当我们将更改从发布分支合并回Develop分支时，我们是否要开始一个新的快照版本？

- ddewaele

---

Maven对版本控制的看法比git及其思维方式早得多。使用git时，提交的sha1-key就是版本号，这在你不知道哪个提交将在生产环境运行时非常有用。如果整个项目都在单个git存储库中，则只需让maven使用快照，并使用git提交ID作为您使用的版本即可。 - Thorbjørn Ravn Andersen

人们似乎正在采用它作为他们最喜欢的Git工作流程，这不是因为它很好，而是因为人们对CI和现代开发过程（如CD、JIT、ToC）不太了解。GitFlow是一种非常过时的关于分支的思考方式。有更好的替代方案，如今最广为人知的是基于主干的开发方式。虽然这可能对一些团队来说太高级，但在这些团队中，您可能希望从简单的FeatrBranch->master方法开始。 - Stanislav Bashkyrtsev

@StanislavBashkyrtsev 是的，但对于仍然每2个月发布一次并且在生产之前仍需要大量手动测试的团队呢？ - J Fabian Meier

@JFMeier，罕见的发布对你如何处理分支或版本没有太大影响。在主干中使用FeatureBranches可能比使用FeatureToggles更容易（也可能不是-因情况而异），但仅此而已。因此，在罕见的发布情况下，GitFlow和复杂的版本控制也没有任何好处。 - Stanislav Bashkyrtsev

@StanislavBashkyrtsev 我只是有这样的印象，如果你有release和hotfix分支，在开发进展的同时修复生产版本的错误或修复beta版上的错误会更容易。如果发布需要数周的手动测试（和错误修复），那么仅仅拥有一个主分支是很困难的。 - J Fabian Meier

@JFMeier，你是指在稳定发布分支的同时开始了新的开发吗？你可以将这个新的开发工作放在功能分支上。这样你的主分支就被“锁定”，在此期间不能合并新的功能。如果这个稳定期太长（这是一个大问题），你可能想让开发人员推送到一些“develop”分支来集成他们的更改。但这会导致更长的稳定阶段，因为他们在这段时间内会犯很多错误。所以如果事情无法适应功能分支，停止开发工作通常是更便宜的选择。 - Stanislav Bashkyrtsev

Answer 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的发布分支，并更新develop分支pom到下一个版本。

 mvn jgitflow:release-finish

Mergers发布到主分支和开发分支并创建标签：通常，此分支进行集成测试，任何错误修复都会提交到发布分支，当发布分支关闭时，开发分支也会获得更新，因为它已合并。

创建一个发布分支，同时更新开发pom，即之前的（devlop 0.1-SNAPSHOT）。之后，开发版本变为0.2-SNAPSHOT，并创建了一个0.1-RC-SNAPSHOT的发布分支。

参考链接：https://bitbucket.org/atlassian/jgit-flow/wiki/Home。

- loneStar

Answer 2

在我们的应用程序中，我们使用了 maven-release-plugin 来更新 pom 文件中的版本。当我们使用像 Jenkins 这样的工具时，每当我们配置一个 Job 时，我们也有触发下游 Job 的选项。因此，在我们的情况下，我们有以下设置：

1. 从 release 到 master 的 pull request 被创建，构建将在 release 上运行，如果成功，则启用合并。
2. 当合并发生时，jenkins job 被触发以将版本更新为快照版本。之后，触发下游 job 将同一快照版本更新到 develop 分支中。

因此，在我们的情况下，每当发布经历两个版本更新时，一个是在剪切发布版本时发生的更新，另一个是在发布后将快照版本剪切时发生的更新，当合并到主分支和开发分支时。因此，在我们的主分支和开发分支中，在发布后，最终版本将始终是快照版本。对于一些团队，我看到他们只更新开发分支中的快照版本，并将发布版本直接推送到主分支（也就是从发布分支合并到主分支而不更改为快照版本，在下游作业中在合并到开发分支时更改版本为快照版本）。

对于您的问题：我假设在发布分支上，在发布进入生产之前也可能有多个提交。由于我们无法重用非快照版本，因此我们是否应该在此处使用每个提交递增固定版本，或者在完成和推送到主分支之前也使用发布快照版本？

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

- Ananthapadmanabhan

Answer 3

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

有关此问题，请查看 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视为“大于”所有具有构建编号和修饰符的版本。

- scrutari

---

嘿，我目前正在学习Maven，并在你的回答中发现了一些有趣的东西。你提到：“版本控制和分支管理应该在pom.xml文件之外进行。”就我的有限Maven知识而言，如果我们想要使用Maven插件，它们应该添加在pom文件中，那么我们如何将其变成外部工具呢？我目前正在使用“gitflow-maven-plugin”来管理我的项目，我只能更新版本中的最后一个数字（Z），不确定如何测试和更新X和Y，同时我考虑将其与Jenkins结合起来，使这个过程自动化，你有什么想法吗？ - wawawa

@Cecilia，您仍然可以使用Maven来运行某些操作，只需从不同的pom.xml文件中执行即可（您可以使用-f选项）。重点是遵循关注点分离原则：将项目的测试和构建功能放在主要的pom.xml文件中，将发布和分支处理等内容放在另一个文件中（它也可以在版本控制之外，并通过一些Maven插件从命令行调用来交付）。 - scrutari