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

时间:2017-06-16 11:09:47

标签: maven merge git-flow

假设我的开发分支在v 1.0.1-SNAPSHOT上,我的主人在1.0.0上。 我必须创建一个修补程序。使用SourceTree的Git Flow菜单(或任何其他工具),我从master创建了修补程序分支,我将poms更新为v 1.0.0.1(使用mvn版本:set -DnewVersion = 1.0.0.1),并进行修复。

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

考虑到在修补程序期间没有对poms进行任何更改,只需使用develop分支上的版本即可解析它们。

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

最好的方法是什么?

2 个答案:

答案 0 :(得分: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-SNAPSHOT

您可以在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>

但是要注意,在您希望flatten-maven-plugin或只想deploy such artifacts to a repository的情况下,您必须使用mvn install。这需要看起来像这样:

<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}目前不支持其他媒体资源。

答案 1 :(得分:0)

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

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

在我们的工作流程中,我们执行手动合并解析,然后使用maven确保我们拥有正确的快照版本集。

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

然后我们运行我们的测试,并将其称为一天。

我一直在阅读有关git rerere的内容,并认为这可能会非常有用。

  

该名称代表“重复记录的分辨率”,顾名思义,它允许您让Git记住您是如何解决大块冲突的,以便下次看到相同的冲突时,Git可以自动解决它为了你。   More here

对于大多数开发团队来说,这是一个非常恼人的问题,我有兴趣看到其他解决方案!