Meilleures pratiques pour le contrôle IntelliJ IDEA 9 + Maven + Version

Le projet utilise Maven pour que les fichiers POM soient les principales sources d’informations sur le projet. Il y a quelques parameters utiles dans les fichiers de projet qui seraient intéressants à conserver.

OTOH IDEA semble créer trop de changements redondants dans la structure du fichier de projet, ce qui pollue l’historique SVN et crée parfois des conflits.

Dois-je conserver le répertoire .idea et les fichiers * .iml sous contrôle de version? en entier? en partie?

Mise à jour: La meilleure pratique que j’ai trouvée pour moi et mon équipe est donc la suivante:

  1. Vérifiez tous les fichiers IDEA, les répertoires * .iml et .idea. Ils contiennent des informations précieuses et il est inutile de les recréer à chaque mise à jour.
  2. Créer une twig privée pour chaque développeur
  3. cd dans le répertoire .idea
  4. svn le changer à son homologue de twig privée
  5. Ne pas archiver les fichiers IDEA lors de validations régulières – ils polluent l’historique. Vérifiez-les sur les commits spéciaux.

De cette façon, vous conservez le contenu du répertoire .idea dans le contrôle de version, mais vous le gardez hors de scope des validations régulières. Tout développeur peut avoir access aux répertoires IDEA de quiconque.

Mise à jour 2: Depuis que cette question a été écrite, j’ai changé ma pratique pour ne pas archiver les fichiers IntelliJ dans le contrôle de version, comme conseillé par de nombreux intervenants. C’est ma pratique actuelle pour Maven et Gradle. Les outils ont évolué au point que les informations critiques peuvent toujours être reproduites à partir des fichiers .POM ou .gradle originaux. Lorsque les fichiers changent, l’EDI suit les modifications de manière fiable, vous ne perdez donc pas souvent vos fichiers IDE, vous n’avez donc pas besoin de les enregistrer.

Mise à jour 3: 7 ans après avoir posé cette question, elle semble toujours pertinente. Les mêmes bonnes pratiques s’appliquent également à Gradle (probablement aussi SBT): ne vérifiez pas les fichiers IDE, recréez-les si nécessaire à partir des fichiers POM, .gradle ou SBT de base.

Réponse courte: ne mettez pas ces fichiers dans le référentiel de contrôle de source car vous pouvez les “générer” (et c’est encore plus vrai si vous n’en avez pas besoin, s’ils sont agaçants, s’ils peuvent casser d’autres environnements).

J’utilise personnellement les valeurs suivantes pour svn:ignore :

 target *~ *.log .classpath .project *.ipr *.iws *.iml .settings 

L’un des avantages de Maven est que l’outil prend en charge la transformation d’un POM en projet natif dans Eclipse, Idea et Netbeans. Si vous avez un pom, vous pouvez créer un projet natif assez rapidement.

Pour cette raison, je ne vérifierais pas les fichiers .idea ou * .iml sous contrôle de source, pas plus que je ne verrais dans les fichiers RMI ou les fichiers de classe.

Je pense que vous devriez mettre le répertoire .idea dans le contrôle de version. La plupart de la configuration contenue dans cette version doit être suivie par la version, par exemple les configurations du compilateur.

Le seul fichier n’appartenant pas au contrôle de version est .idea / workspace.xml, car il ne contient que la configuration spécifique à votre environnement local.

IntelliJ Idea place réellement workspace.xml dans la liste des ignorés par défaut, donc si vous utilisez Idea pour l’archiver, vous devriez être tous configurés sans rien changer.

Je vois que la réponse standard est “ne pas vérifier dans le fichier de projet, juste le .pom”. Mais les choses comme les fichiers .ipr contiennent beaucoup de parameters utiles qui ne peuvent PAS être dérivés du fichier .pom. Que se passe-t-il si d’autres utilisateurs d’IntelliJ souhaitent partager ces parameters? Je sais que les fichiers .ipr sont conçus pour être versionnés (voir ce fil par exemple). J’aurais aimé avoir une réponse réelle, mais je n’ai pas encore trouvé de bonne pratique à ce sujet.

Mon avis est que nous devrions garder tous les fichiers spécifiques à IDE hors du contrôle de version. L’idée est que nous devrions garder autant d’informations que possible sous une forme indépendante IDE comme les fichiers Maven pom, etc. Tous les parameters critiques du projet peuvent y être conservés. Et ayant tous les principaux parameters du projet conservés dans le fichier pom, je ne vois aucune raison sérieuse de vérifier non seulement la configuration du projet IDEA, mais également toute autre configuration spécifique à l’IDE. En outre, la configuration du projet de style de dossier .idea pollue réellement les journaux des jeux de modifications. Et nous voulons toujours conserver les parameters du projet IDEA dans le contrôle de version, nous pouvons au moins les stocker dans un seul format de fichier .ipr.

Je suis en retard à cette fête, mais ce problème précis me préoccupe. Et je me suis inspiré de ce que je pense pourrait fonctionner, du moins avec notre système de contrôle de source.

Les fichiers IntelliJ ne doivent pas être stockés “ensemble” avec le fichier pom.xml faisant autorité et la source. L’historique du contrôle de version n’est pas “pollué” si ces modifications non liées à la source sont enregistrées à un endroit différent de l’arborescence source.

Je vais donc essayer de déplacer les fichiers IntelliJ vers un emplacement parallèle dans le système de contrôle de version, utiliser un simple mappage de fichiers / répertoires pour réunir les fichiers source et projet sur la machine de développement et surveiller les modifications du système de contrôle de version la construction.