GitFlow中的Maven版本控制
dde*_*ele 10 java git maven git-flow
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之前使用版本快照版本？
- 当我们将更改从发布版本合并到开发分支时,我们是否会启动新的快照版本？
我发现将源代码控制（由 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.ZMaven 将认为您的版本比所有具有内部版本号和修饰符的版本“更好”。