如何在没有合并冲突的情况下管理git中的POM版本号

我很难理解如何使用版本号。在我的团队中，我们的基本工作流程是这样的。我的团队的开发周期如下所示

持续开发是在我们的开发环境中完成的。每个月我们都会有一次代码冻结，将当前版本的应用程序部署到一个单独的QA环境中，我们的QA人员会在那里测试它的稳定性和开发人员遗漏的任何bug。一旦QA满意（这需要1到2周的时间，取决于QA的工作量），QA版本将部署到我们的实时生产服务器上

我们正在从Subversion迁移到Git，我正试图设计我们的分支/发布策略来支持这一点。我想做的是：

起点：DEV在

主机上的1.0版快照上运行

代码冻结时：从master创建一个新分支release-1.0。将

master

上的POM增加到1.1-SNAPSHOT
在QA之后：将1.0版部署到我们的nexus服务器并标记存储库。将

release-1.0

合并到

master

中，以便将任何错误修复或更改集成到未来的版本中

问题是，当我将

release-1.0

合并到master中时，POM的版本会出现合并冲突<代码>1.1-快照与

1.0

冲突。合并冲突很容易解决，但它使我无法自动执行此步骤

理想情况下，发布分支可以作为维护分支保留，开发版本为

1.0.1-SNAPSHOT

，但我不希望将该更改集成到主分支中。否则，我很乐意删除发布分支，并依靠标签为1.0.1版本创建任何热修复分支，因为这只适用于不能等待下一个发布周期的关键生产问题

我希望避免将发布分支提交到master中，只是为了消除遗漏某些内容的可能性，避免将其合并到master中

---

有没有办法用maven release插件来管理这一点，或者我注定要手动完成这一点？

正如Tim所提到的，如果您的项目源包含版本号、标记名、计划发布日期本身（！），那么您将总是会遇到冲突，因为两个分支在这一点上根本不同意

这在当今的软件项目中很常见。这是Maven的方式，也是Linux的方式，但是我不认为Linus会接受内核版本号或代码名上有冲突的补丁-它们遵循与大多数项目不同的模型

另一种方法是在源代码中保留一个特殊的“0-SNAPSHOT”（用Maven术语）版本，并仅在发布时对其进行修改。然后所有的开发部门都会同意，我相信这就是你想要的

请注意，Maven的设计并没有考虑到这一点，您将遇到一些问题。例如，您如何解释您的QA最终版本（1.0）与他们批准的版本（1.0-rc-5）的SHA1哈希不同，仅仅因为您更改了源代码中的数字

---

如果您完全从项目源中抛出版本号，这将不再是一个问题。恐怕我还没有发现这是一种专业的方式。我们需要更好的工具。

但是在其他文件中不总是存在合并冲突吗？在每次合并中都需要手动解决？与@TimBiegeleisen达成一致，如果您将任何错误的修复推送到主分支，那么该文件上也会存在合并冲突。如果它是一个单独的发行版，你也可以使用升级版。有一种方法是进行合并，并指定

--他们的

或

--我们的

无条件地接受父母一方的版本。但是，因为除了POM之外，您可能还有其他文件，如果盲目地接受每个文件的一个版本而不是另一个版本，那么您将把孩子和洗澡水一起扔掉。我以前尝试过使用自定义合并筛选器驱动器：