Meilleur outil pour fusionner le correctif de flux Git pour les projets maven multi-module

Question

Supposons que ma branche develop soit sur v 1.0.1-SNAPSHOT, mon maître est sur 1.0.0. Je dois créer un correctif. En utilisant le menu Git Flow de SourceTree (ou tout autre outil), je crée la branche correctif à partir de master, je mets à jour les poms vers v 1.0.0.1 (en utilisant mvn versions: set -DnewVersion = 1.0.0.1), et faites le correctif. Lorsque je termine le correctif à l'aide de Git-Flow, je dois fusionner de nouveau pour développer la branche. Cela signifie que les fichiers pom seront en conflit. Dans le cas où j'ai un projet multi-module avec un grand arbre de module, tous les poms doivent être résolus. Les autres fichiers qui ont été modifiés dans les deux branches seront également en conflit. Considérant que pendant le correctif il n'y avait aucun changement aux poms, ils peuvent être résolus en utilisant simplement la version sur la branche de développement.

Cela doit être fait pour chaque correctif, mais en utilisant SourceTree, par exemple, il est difficile de distinguer visuellement les poms et les autres fichiers en conflit. Ce serait bien que je puisse séparer ces fichiers d'une façon ou d'une autre que je peux ignorer et fusionner en acceptant ce qui est déjà sur la branche de développement.

Quelle est la meilleure façon de procéder?

Answer 1

C'est une bonne question pour le flux git.

Dans votre scénario, vous n'avez pas mentionné de modifications apportées au Pom en dehors de la version, mais cela est possible dans une hot-fix. Mis à part quelques trucs vraiment astucieux git, nous résolvons cela à la main.

Dans nos flux de travail, nous effectuons une résolution de fusion manuelle, puis utilisons maven pour nous assurer que la version de l'instantané est correcte.

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

Ensuite, nous effectuons nos tests et nous l'appelons un jour.

J'ai lu environ git rerere et pense que cela pourrait être super utile ici.

Le nom signifie « réutilisation enregistrée résolution » et comme son nom l'indique, il vous permet de demander Git de se rappeler comment vous avez résolu un conflit de gros morceau de telle sorte que la prochaine fois qu'il voit le même conflit, Git peut résoudre automatiquement pour vous. More here

Ce problème est un super gênant pour la plupart des équipes de dev, je suis curieux de voir des solutions autres!

Answer 2

La solution la plus simple que je connaisse est d'utiliser une propriété pour une version plutôt que littérale en la définissant dans le (s) fichier (s) pom. Ceci est disponible depuis Maven 3.5.0.

Vous pouvez le faire comme ceci:

<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> 

Maintenant, vous pouvez le construire via:

mvn -Drevision=1.2.0-SNAPSHOT clean package 

Mais cela signifierait pour définir la révision chaque fois que vous appelez Maven via la ligne de commande qui est un peu encombrant. Donc vous pouvez utiliser la solution via le fichier .mvn/maven.config qui contient:

-Dévision = 1.2.0-SNAPSHOT

Vous pouvez définir la propriété dans le Maven se pom comme ceci:

<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> 

Cela signifie que vous avez seulement un seul endroit où la version est définie et non dans le module tous les

etc.

une configuration du module fonctionne aussi plusieurs comme celui-ci où un enfant d'un parent ci-dessus pourrait ressembler à ceci:

<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> 

mais sachez que vous devez utiliser flatten-maven-plugin dans les cas où vous voulez deploy such artifacts to a repository ou voulez simplement faire mvn install. Cela doit ressembler à ceci:

<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> 

Cela signifie à la fin vous avez une seule ligne où la version de votre projet est défini et qui devrait permettre de réduire considérablement cette fusion des problèmes.

Veuillez lire attentivement la documentation!

Veuillez utiliser seulement ${revision}, ${changelist} ou ${sha1} Les autres propriétés ne sont pas supportées pour l'instant.