Git Flow已经存在了很长时间,很多人似乎都将它作为他们最喜欢的git工作流程。
当谈到在Java / Maven环境中实现Git Flow时,我想知道如何对下面所有分支上的软件模块进行版本控制。
在简单的Maven世界中,
如果您拥有的只是一个开发和主分支,那就没关系,但是如何在GitFlow中处理maven版本。
master上的版本很容易定义,因为它们将是最终从Release分支创建和发布的版本。
但是一旦代码进入发布分支,您在此处部署了哪种版本控制策略?
答案 0 :(得分:2)
对于发布分支,我们应遵循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
合并人员更愿意掌握和开发并创建标签:多数情况下,此分支进行集成测试,将所有错误修复都提交到release分支,当它关闭时,develop也会在合并时获取更新。
创建一个发布分支,并同时更新开发pom,即在devlop 0.2-SNAPSHOT和一个0.1-RC-SNAPSHOT发行分支之前(devlop 0.1-SNAPSHOT)创建后
答案 1 :(得分:1)
在我们的应用程序中,我们曾使用maven-release-plugin
来更新pom文件中的版本。当我们使用诸如Jenkins之类的工具时,每当配置Job时,我们还可以触发下游作业。因此,在本例中,我们进行了以下设置:
release
到master
的拉取请求,该构建将在发行版上运行,并且成功启用合并。develop
分支中的相同快照版本。因此,在我们的案例中,每当发行版进行两次版本更新时,一种是在发行版本被剪切时进行的,另一种是在发行后合并到母版并进行开发时快照版本被剪切时的。因此,在我们掌握和发布之后进行开发时,最终版本始终是快照之一。对于某些团队,我已经看到他们仅在开发中更新快照版本并将发行版本直接推送到主版本(也就是说,他们从master
合并到release
,而版本未更改为快照并在下游作业合并到develop
时将版本更改为快照。
对于您的问题:我假设在发行版投入生产之前,在发行版分支上还可以进行多次提交。由于我们无法重复使用非快照版本,因此我们在每次提交时都在此处增加固定版本,还是在最终确定并推送至主版本之前使用发行快照版本?
在理想情况下,发行分支不会对此直接提交。因此,是的,每当您从开发阶段合并到发行版本时都需要增加版本,因为它是作为一个过程设置的,如果每次增加版本都会更容易跟踪错误修正和功能。释放。
答案 2 :(得分:0)
我发现将源代码控制(由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视为比所有具有内部版本号和修饰符的版本都更大。