我们正在尝试将 git-flow 模型应用于 maven 项目。
我们使用 develop和 feature/XXX分支工作 -SNAPSHOT版本化 Artifact ，部署在我们的 DEV 中和 TST环境。
当应用程序“准备好”时，我们有“发布候选”:代码被推送到 release分支，我们编辑 pom 来更新版本(将 -SNAPSHOT 替换为 -RC1 )，这个版本被构建并存储在存储库管理器中，然后部署在我们的 UAT 上环境
如果需要一些修复，我们会创建其他修复 -RCx版本相同 release分支，这些 Artifact 存档在存储库管理器中，并部署在 UAT 上。环境因此，我们可以精确跟踪不同版本中的错误修复。
曾经-RCx版本被批准，release分支被推送到 master ，pom 更新以删除 -RCx 、在 PROD 中部署之前构建并存储在存储库管理器中环境
但是通过这种处理方式，部署在 PROD 中的二进制文件并在 UAT并不完全相同:由于 <version>，2 个 WAR 中的 POM 不同标签。这不是一个很好的做法。
如果我正确理解了 git-flow 模型，则应该在创建 -RCx 时设置“最终”版本号(没有 release )。分支，并且相同的版本是“事件的”，直到这个分支被推送到 master ， 对 ？在这种情况下:
UAT 中丢失了真正部署的应用程序版本的信息。 (因为我们丢失了 -RCx 标识符，我们可能不知道部署的版本是否包含最后的错误修正，或者它是否是部署的旧版本......)release 构建了 Artifact 。分支或来自 master , 因为推送 feature 时版本号不再发生变化分支到 master . 什么是更好的 ？这两种做法的优缺点是什么？ (不同 envs 上的二进制文件不同 -vs- 没有明确的候选发布版本。)
你(或者你会)如何使用 git-flow 模型中的 Maven 项目管理发布候选？
最佳答案
我建议在您的版本控制策略中添加一个修订号。当您启动发布分支时，修订号设置为 0，然后随着每次修复而增加。测试完成后，将验证测试的确切版本部署到生产中。这种方法为每个版本提供了可追溯性，使版本在不同环境中保持一致，并避免了对仅围绕版本号进行形式化的新构建的需要。在您的测试环境中验证的完全相同的二进制文件可以部署到生产中。
我已经在几个生产应用程序中使用了这个策略并且没有遇到任何问题。
关于Maven 和 git-flow，候选发布版本策略，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41739985/