我正在与许多开发人员一起进行一个大型Java项目。我们使用Gitlab作为存储库。现在，每个提交合并请求的开发人员都必须在提交之前更新pom.xml中的项目版本。 当两个开发人员从事不同的工作并同时制作两个不相关的MR，且两个MR的更新版本号相同时，就会发生此问题。第一个MR已正确合并，第二个合并未显示冲突（pom.xml中的版本号相同），因此也将其合并。现在，我们合并了两个具有相同版本号的MR。将构建上传到工件时，这会引起问题。
如何解决此问题？
我当时在想，每个开发人员都可能在版本号后附加一些ID（例如，开发人员的姓名缩写），从而在上述情况下造成冲突。或者也许使用挂钩自动更新pom.xml版本，因此开发人员不必这样做。
为每个MR更新项目版本号的正确方法是什么？
答案 0 :(得分：1)
您似乎在考虑团队中的版本控制。我以前见过这样的计划-人们一直在遭受痛苦。您无法使用Git解决此问题，因此只需停止更改Maven的版本-而是更改上传工件的方式即可。
如果您要在公司中实施CD-版本控制的一种好方法是使用 resolved SNAPSHOT。只需保留x.y.z-SNAPSHOT版本，而不更改x.y.z。当Maven上传工件时，它将创建一个可以唯一标识的时间戳+数字版本，例如1.1.0-20190830.184736-6123。
注意：默认情况下，每个模块都有自己的时间戳。要在所有模块中使用相同的版本，您可以手动生成该版本并将其分配给mvn versions:set。
答案 1 :(得分：0)
问题在于，在开发过程中，您不确定要发布的内容是什么。
我已经看到了发行经理的角色。他是决定何时发布该版本以及将其部署到哪个版本的人。另外，开发人员在功能分支中工作，因此，如果两个开发人员在同一功能中工作，则他们应在同一分支中工作。
有几种分支模型。 link
中有4个但是有些公司由于自身的发布周期而使用自己的分支模型。
我的建议：检查分支模型，分析发布周期，并根据发现进行任何更改。之后，请按照Tim Biegeleisen所述，考虑转向CI / CD解决方案