Les meilleures pratiques pour IntelliJ IDEA 9 + Maven + de commande Version

Question

Le projet utilise Maven de sorte que les fichiers POM sont les principales sources d'information sur le projet. Il y a quelques paramètres utiles dans les fichiers de projet qui serait bon de garder.

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

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

Mise à jour: Donc, la meilleure pratique, j'ai trouvé travailler pour moi et mon équipe est à ce jour:

1. Vérifiez dans tous les fichiers IDEA, * répertoires de .iml et .idea. Ils contiennent des informations précieuses et il est une perte de temps pour le recréer à chaque fois que vous mettez à jour.
2. Créer un autocommutateur privé pour chaque développeur
3. cd dans le répertoire de .idea
4. changer svn à son homologue autocommutateur privé
5. Ne pas vérifier dans les fichiers IDEA sur commits réguliers - ils polluent l'histoire. Vérifiez-les dans le commits spéciaux.

De cette façon, vous gardez le contenu du répertoire .idea dans le contrôle de version, mais le garder hors de la voie de commits réguliers. Tout développeur peut avoir accès aux répertoires IDEA de quelqu'un d'autre.

Mise à jour 2: Étant donné que cette question a été écrit, je l'ai changé ma pratique à pas vérifier dans tous les fichiers IntelliJ dans le contrôle de version, comme conseillé par de nombreux intervenants. Ceci est ma pratique courante pour les Maven et Gradle. Les outils se sont développés au point que les informations critiques peuvent toujours être reproduites à partir du .POM d'origine ou des fichiers .gradle. Lorsque les fichiers changent, l'IDE suit les changements de manière fiable de sorte que vous ne perdez pas vos fichiers IDE qui, souvent, il n'y a pas besoin de les enregistrer.

Mise à jour 3: 7 ans après avoir posé cette question, il semble être toujours d'actualité. Les mêmes meilleures pratiques applicables à Gradle et (probablement SBT, aussi). Ne vérifie pas les fichiers IDE dans, les recréer si nécessaire à partir du POM de base, les fichiers .gradle ou SBT

Answer 1

Réponse courte: ne pas mettre ces fichiers dans le référentiel de contrôle de source que vous pouvez « générer » les (et cela est encore plus vrai si vous n'avez pas besoin, s'ils sont ennuyeux, si elles peuvent briser environnement autres ).

j'utilise les valeurs suivantes pour svn:ignore:

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

Answer 2

L'une des grandes choses au sujet Maven est que le support d'outil existe pour transformer un POM dans un projet natif dans Eclipse, Idée et Netbeans. Si vous avez un pom, vous pouvez créer un projet natif assez rapidement.

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

Answer 3

Je pense que vous devriez mettre .idea répertoire dans le contrôle de version. La plupart de la configuration contenu il devrait être la version objet d'un suivi, par exemple configs du compilateur.

Le seul fichier qui ne fait pas partie de contrôle de version est .idea / workspace.xml, car il ne contient que la configuration particulière à votre environnement local.

Idée IntelliJ met effectivement en workspace.xml ignorer la liste par défaut, donc si vous utilisez l'idée à l'arrivée, vous devez être tous ensemble sans changer quoi que ce soit.

Answer 4

Je vois que la réponse standard est « ne vérifie pas dans le fichier de projet, juste le .pom ». Mais les choses comme les fichiers .ipr contiennent beaucoup de paramètres utiles qui ne peuvent être dérivées du fichier .pom. Que faire si d'autres utilisateurs IntelliJ veulent partager ces paramètres? Je sais que les fichiers .ipr sont conçus pour être versionné (voir ce fil par exemple). Je voudrais avoir une réponse réelle, mais je ne l'ai pas encore trouvé de bonnes pratiques à ce sujet.

Answer 5

Mon opinion est que nous devrions conserver des fichiers spécifiques IDE de contrôle de version. L'idée est que nous devrions garder autant que possible des informations en IDE forme indépendante comme les fichiers pom Maven et ainsi de suite. Tous les paramètres critiques du projet peuvent y être conservés. Et que tous les principaux paramètres 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 toute autre configuration spécifique IDE. De plus, .idea style dossier configuration du projet pollue vraiment les journaux changeset. Et nous voulons toujours conserver les paramètres du projet IDEA dans le contrôle de version, nous pouvons au moins les stocker au format de fichier .ipr unique.

Answer 6

Je suis en retard à ce parti, mais cette question précise a été me affligent. Et je viens inspiré avec ce que je pense qu'elle pourrait travailler, au moins avec notre système de contrôle de code source.

Les fichiers IntelliJ ne doivent pas être stockés « ensemble » avec le pom.xml faisant autorité et la source. si les non-source des changements liés sont enregistrés L'historique de contrôle de version est pas « polluée » à un endroit différent dans l'arbre source.

Je vais donc essayer de déplacer les fichiers IntelliJ à un endroit en parallèle dans le système de contrôle de version, utilisez un simple fichier / cartographie répertoire pour réunifier la source et les fichiers projet sur la machine de développement, et de surveiller les changements dans le système de contrôle de version qui sont purement à fichiers qui modifieront la construction.