我无法理解如何使用版本号。在我的团队中，我们的基本工作流程就像这样。我团队的开发周期看起来像这样。
在我们的开发环境中进行持续开发。我们每个月都有一个代码冻结，其中当前版本的应用程序部署到一个单独的QA环境中，我们的QA人员会测试它的稳定性以及开发人员错过的任何错误。一旦QA得到满足（这需要1至2周，具体取决于QA的工作量），QA版本将部署到我们的实时生产服务器。
我们正在从Subversion迁移到Git，我正在尝试设计我们的分支/发布策略来支持这一点。我想做的是：
起点：DEV正在master上的1.0-SNAPSHOT版本上运行
在Code Freeze：从master创建一个新分支release-1.0。将master上的POM增加到1.1-SNAPSHOT
质量保证后：将版本1.0部署到我们的nexus服务器并标记存储库。将release-1.0合并到master中，以便将任何错误修复或更改集成到将来的版本中。
问题在于，当我将release-1.0合并到master中时，我在POM版本上遇到合并冲突。 <version>1.1-SNAPSHOT</version>与<version>1.0</version>冲突。合并冲突很容易解决，但它阻止我自动执行此步骤。
理想情况下，发布分支可以作为维护分支保留，其开发版本为1.0.1-SNAPSHOT，但我不希望将该更改集成到主分支中。否则，我很高兴删除发布分支并依赖标记为1.0.1版本创建任何热修复分支，因为这仅适用于无法等待下一个发布周期的关键生产问题。
我希望避免从发布分支到主服务器的提交，以消除丢失某些内容的可能性，并且不会合并到主服务器中。
有没有办法用maven-release插件管理它，或者我注定要手动执行此操作？
答案 0 :(得分：1)
正如Tim所提到的，如果您的项目源包含版本号，标签名称，计划发布日期（！），您将始终遇到冲突，因为两个分支只是不同意这一点。
这在今天的软件项目中很常见。这是Maven Way，也是Linux方式，但我不认为Linus会接受内核版本号或代号中的冲突补丁 - 它们遵循的模型与大多数项目不同。
替代方案是保持一个特殊的＆＃34; 0-SNAPSHOT＆＃34; （在Maven术语中）源代码中的版本，只有在它发布时才进行修改。然后所有开发分支都会同意，我相信这就是你想要的。
请注意，Maven的设计并未考虑到这一点，您将遇到问题。例如，您如何解释您的质量保证最终版本（1.0）与他们批准的版本（1.0-rc-5）有不同的SHA1哈希只是因为您更改了源代码中的数字？
如果您完全从项目源中删除版本号，这将不再是一个问题。我没有发现这是我害怕的Maven Way。我们需要更好的工具。