【发布时间】：2017-06-04 01:05:31
【问题描述】：
我们正在尝试将 git-flow 模型应用于 maven 项目。
我们使用develop 和feature/XXX 分支来处理-SNAPSHOT 版本化的工件，这些工件部署在我们的DEV 和TST 环境中。
当应用程序“准备好”时，我们有“发布候选”：代码被推送到release 分支上，我们编辑 pom 以更新版本（将-SNAPSHOT 替换为-RC1），这个版本被构建并存储在存储库管理器中，然后部署在我们的UAT env 上。
如果需要一些修复，我们会在同一个 release 分支中创建其他 -RCx 版本，这些工件存档在存储库管理器中，并部署在 UAT 环境中。因此我们可以精确跟踪不同版本中的错误修复。
一旦-RCx 版本被批准，release 分支将被推送到master，更新 pom 以删除 -RCx，构建并存储在存储库管理器中，然后再部署到 PROD 环境中.
但是通过这种方式，在PROD 和UAT 中部署的二进制文件并不完全相同：由于<version> 标记，两个WAR 中的POM 是不同的。 这并不是一个真正的好习惯。
如果我正确理解了 git-flow 模型，“最终”版本号（没有-RCx）应该在创建release 分支时设置，并且相同版本在此分支之前是“活动的”被推到master，对吧？在这种情况下：
- 我们丢失了
UAT中真正部署的应用程序版本的信息（因为我们丢失了-RCx标识符，我们可能不知道部署的版本是否包含最后的错误修复，或者它是否是旧版本已部署...） - 在存储库管理器中，我们无法知道工件是从
release分支还是从master构建的，因为在将feature分支推入@987654349 时版本号不再更改@。
什么更好？这两种方式的优缺点是什么？ （不同 env 上的二进制文件不同 -vs- 没有明确的候选版本。）
你（或者你会）如何使用 git-flow 模型中的 Maven 项目管理Release Candidates？
【问题讨论】：
标签： maven version-control pom.xml git-flow release-candidate