git，maven和jenkins-版本，开发和发布构建工作流程

使用git，maven和jenkins进行以下操作的首选方式是：

我正在开发一个应用程序，我想维护它的“ dev”和“ release”分支。我希望詹金斯同时建立两者。发行工件可能具有1.5.2之类的版本，而dev-builds仅为0.0.1-SNAPSHOT。我不想有2个不同的pom.xml文件。

我查看了配置文件，但是它们似乎无法更改工件版本。我研究的一种方法可能是在测试版本中添加“限定符”。当然，我可以重命名该文件，因为关于此的真实工件信息并不重要，因为该应用程序是独立的。

这样做的首选方式是什么？还是您会怎么做？

我想这些分支之间应该存在固有的关系，应该解决版本号问题。

发行

我想您可能会做一些事情，例如将生产就绪代码从dev分支合并到release分支，然后执行Maven发布（通过Jenkins或手动进行）。这将自动将版本号滚动到下一个版本。因此，您将代码1.4.7-SNAPSHOT合并到此分支，执行发布并剪切版本1.4.7，Maven会自动将工作副本滚动到1.4.8-SNAPSHOT。

更新基准（可选）

如果尚未将主干（或基准分支等）用作发布位置，则应在完成发布后立即更新主干。这意味着您的版本号也正在更新。如果仅将发布分支视为基准，则此步骤可能没有意义。

从基准到开发分支的合并

您的开发部门必须与实际生产代码保持最新，这一点至关重要。您需要将代码从基线（或发布分支，具体取决于实现）合并到开发分支。这对您来说很重要，因为这意味着将在发行过程中发生的pom更改（将版本更改为1.4.8-SNAPSHOT）带到了该分支。

根据我已经读过的内容（以及组织中的流程），这似乎是对Maven版本和快照的相当标准和有效的使用，而不是在不同分支上维护完全断开的版本号，这很容易分辨任何1.4.7-SNAPSHOT版本实际上都是1.4.7版本的直接前身。他们有关系。我要说的是，如果您不在这些分支之间来回合并，那么您在进行SCM和Maven版本控制时都将出错，并且您将面临着针对与生产不匹配的代码进行开发的风险，将错误重新引入生产等。

重新考虑您的方法。

在发行版中使用例如1.4.2，然后在下一个开发中使用1.4.3-SNAPSHOT是非常常见的。

当您需要维护 1.4.2版本时，则从产生1.4.2工件的提交中将其分支。

然后，您告诉Jenkins存储库的位置和分支名称，导致检出文件集，然后告诉Jenkins在项目上使用maven进行构建。

注意：我发现使用单个pom.xml来构建实际的工件，而使用另一个pom.xml来创建要发送给客户的实际部分是非常有益的。