GitFlow 中的 Maven 版本控制

2022-09-02 04:49:34

Git Flow已经存在了很长时间,很多人似乎正在将其作为他们最喜欢的git工作流程。

当涉及到在Java / Maven设置中实现Git Flow时,我想知道应该如何处理下面所有分支上的软件模块的版本控制。

enter image description here

在一个简单的Maven世界中,

  • 开发人员始终使用快照版本(例如:0.0.1-SNAPSHOT)
  • 某些发布过程创建一个版本 (0.0.1)
  • 新的快照版本可供开发人员开发 (0.0.2-SNAPSHOT)。

如果你只有一个开发和主分支,这是可以的,但是你如何处理GitFlow中的maven版本控制。

主服务器上的版本非常容易定义,因为它们将是最终从“发布”分支创建和发布的版本。

但是,一旦代码进入发布分支,您就会在这里部署什么版本控制策略?

  • 我想我们需要在发布分支上保留一个新的版本号,以避免与开发冲突?以及该版本号与开发分支上的任何内容有何关系。
  • 我假设在发布分支上,在发布进入生产环境之前也可以有多个提交。由于我们无法重用非快照版本,因此我们是在每次提交时增加固定版本,还是在最终确定并推送到 master 之前也使用发布快照版本?
  • 当我们将更改从发布合并到开发分支时,我们是否开始一个新的快照版本?

答案 1

对于发布分支,我们应该遵循命名约定。另外,请浏览 mvn jgitlfow 插件。这将提供上述所有讨论的功能。0.0.1-RC-SNAPSHOT

请包括以下内容。

   <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(devlop 0.1-SNAPSHOT)在devlop 0.2-SNAPSHOT和0.1-RC-SNAPSHOT的发布分支之后

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


答案 2

在我们的应用程序中,我们使用 来更新 pom 文件中的版本。当我们使用像 Jenkins这样的工具时,每当我们配置作业时,我们也有条件来触发下游作业。因此,在我们的例子中,我们有以下设置:maven-release-plugin

  1. 发出了从 到 的拉取请求,并且生成将在发布时运行,如果成功,它将启用合并。releasemaster
  2. 当合并发生时,触发了 jenkins 作业以将 pom 中的版本更新为快照版本。在此之后,将触发下游作业以更新分支中的相同快照版本。develop

因此,在我们的例子中,每当一个版本经历了两个版本更新时,就会发生更新,一个是当发布版本被剪切时,另一个是当快照版本在发布到母版和开发版时被剪切时。因此,在我们的母版和开发发布后,最终版本将始终是快照版本。对于某些团队,我看到他们只在开发中更新快照版本,并将发布版本直接推送到master(也就是说,他们从没有版本更改合并到快照,而在下游作业中,当合并到时,他们将版本更改为快照)。masterreleasedevelop

对于您的问题:我假设在发布分支上也可以有多个提交,然后才能进入生产环境。由于我们无法重用非快照版本,因此我们是在每次提交时增加固定版本,还是在最终确定并推送到 master 之前也使用发布快照版本?

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


推荐