合并多模块 maven 项目的 Git 流修补程序的最佳工具

Question

假设我的开发分支在v 1.0.1-SNAPSHOT上，我的主节点在1.0.0上。 我必须创建一个修补程序。使用 SourceTree 的 Git Flow 菜单(或任何其他工具)，我从 master 创建修补程序分支，将 poms 更新到 v 1.0.0.1(使用 mvn versions：set -DnewVersion=1.0.0.1)，然后进行修复。

当我使用 Git-Flow 完成修补程序时，我必须合并回开发分支。这意味着 pom 文件将发生冲突。如果我有一个带有大型模块树的多模块项目，则必须解析所有poms。在两个分支中更改的其他文件也将发生冲突。

考虑到在修补程序期间没有对poms进行任何更改，只需使用开发分支上的版本即可解决这些问题。

必须为每个修补程序执行此操作，但是例如使用SourceTree，在视觉上很难区分poms和其他冲突文件。很高兴我可以以某种方式分离这些文件，我可以通过接受开发分支上已有的内容来安全地忽略和合并这些文件。

最好的方法是什么？

Answer 1

我知道最简单的解决方案是为版本使用属性，而不是将它们从字面上定义到 pom 文件中。这从 Maven 3.5.0 开始可用。

你可以这样做：

<project ...>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>18</version>
</parent>
<groupId>org.apache.maven.ci</groupId>
<artifactId>ci-parent</artifactId>
<name>First CI Friendly</name>
<version>${revision}</version>
...
</project>

现在您可以通过以下方式构建它：

mvn -Drevision=1.2.0-SNAPSHOT clean package

但这意味着每次通过命令行调用 Maven 时都要定义修订版，这有点麻烦。因此，您可以通过包含以下内容.mvn/maven.config文件使用该解决方案：

-Drevision=1.2.0-快照

您可以在 Maven pom 本身中定义属性，如下所示：

<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>18</version>
</parent>
<groupId>org.apache.maven.ci</groupId>
<artifactId>ci-parent</artifactId>
<name>First CI Friendly</name>
<version>${revision}</version>
...
<properties>
<revision>1.0.0-SNAPSHOT</revision>
</properties>
</project>

这意味着您只有一个定义版本的位置，而不是在每个模块等中。

多模块设置的工作方式也是这样的，上面父级的子级可能如下所示：

<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache.maven.ci</groupId>
<artifactId>ci-parent</artifactId>
<version>${revision}</version>
</parent>
<groupId>org.apache.maven.ci</groupId>
<artifactId>ci-child</artifactId>
...
</project>

但请注意，如果您想将此类工件部署到存储库或只想执行mvn install，则必须使用 flatten-maven-plugin。这需要看起来像这样：

<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>18</version>
</parent>
<groupId>org.apache.maven.ci</groupId>
<artifactId>ci-parent</artifactId>
<name>First CI Friendly</name>
<version>${revision}</version>
...
<properties>
<revision>1.0.0-SNAPSHOT</revision>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
<version>1.0.0</version>
<configuration>
<updatePomFile>true</updatePomFile>
</configuration>
<executions>
<execution>
<id>flatten</id>
<phase>process-resources</phase>
<goals>
<goal>flatten</goal>
</goals>
</execution>
<execution>
<id>flatten.clean</id>
<phase>clean</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<modules>
<module>child1</module>
..
</modules>
</project>

这意味着最终您只有一行来定义项目版本，这应该会大大减少这种合并问题。

请仔细阅读文档！

请仅使用${revision}、${changelist}或${sha1}当前不支持其他属性。

Answer 2

对于 git flow 来说，这是一个很好的问题。

在您的方案中，您没有提到在版本之外对 Pom 进行更改，但这在热修复中是可能的。除了一些非常漂亮的git技巧之外，我们手动解决此问题。

在我们的工作流程中，我们执行手动合并解析，然后使用 maven 来确保我们设置了正确的快照版本。

mvn versions:set -DnewVersion=1.0.1-SNAPSHOT -DgenerateBackupPoms=false

然后我们运行我们的测试，并称之为一天。

我一直在阅读有关git rerere的信息，并认为它在这里可能非常有帮助。

该名称代表"重用记录的分辨率"，顾名思义，它允许您要求 Git 记住您如何解决大块冲突，以便下次看到相同的冲突时，Git 可以自动为您解决它。 更多在这里

对于大多数开发团队来说，这是一个超级烦人的问题，我有兴趣看到其他解决方案！