Meilleures pratiques pour IntelliJ IDEA 9 + Maven + Contrôle de version

Question

Le projet est à l'aide de Maven de sorte que le POM fichiers sont les principales sources d'informations de projet. Il y a certains paramètres dans les fichiers de projet qui serait bien de le garder.

Otoh, que l'IDÉE semble créer trop redondant des changements dans la structure des fichiers du projet qui pollue le SVN de l'histoire et crée parfois des conflits.

Dois-je garder le .idée de répertoire et de l' *.iml fichiers sous contrôle de version? en entier? dans la partie?

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

1. Vérifiez dans tous les IDÉE de fichiers, *.iml et .idée répertoires. Ils contiennent des informations importantes et c'est un gaspillage de temps pour recréer à chaque fois que vous mettez à jour.
2. Créer private branch pour tous les développeurs
3. cd dans .idée répertoire
4. svn switch à sa branche privé homologue
5. Ne cochez pas dans l'IDÉE de fichiers ordinaire s'engage -- ils polluent l'histoire. Vérifier sur spécial s'engage.

De cette façon, vous gardez le contenu de .idée de répertoire dans le contrôle de version, mais la garder hors de l'ordinaire s'engage. N'importe quel développeur peut avoir accès à n'importe qui d'autre IDÉE répertoires.

Answer 1

Réponse courte: ne mettez pas ces fichiers dans le référentiel de contrôle de code source car vous pouvez les "générer" (et ceci est encore plus vrai si vous n'en avez pas besoin, s'ils sont ennuyeux, s'ils peuvent détruire l'environnement des autres).

Personnellement, j'utilise les valeurs suivantes pour svn:ignore :

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

Answer 2

L’un des grands avantages de Maven réside dans le fait qu’il existe un outil permettant de transformer un POM en projet natif sous Eclipse, Idea et Netbeans. Si vous avez un pom, vous pouvez créer un projet natif assez rapidement.

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

Answer 3

Je pense que vous devriez mettre le répertoire .idea dans le contrôle de version. La plupart de la configuration qui y est contenue devrait faire l'objet d'un suivi de version, par exemple les configurations du compilateur.

Le fichier .idea / workspace.xml est le seul fichier qui n'appartient pas au contrôle de version, car il ne contient que la configuration propre à votre environnement local.

En fait, IntelliJ Idea place le fichier workspace.xml dans la liste des ignorés par défaut. Par conséquent, si vous utilisez Idea pour vous enregistrer, vous devez être configuré sans rien changer.

Answer 4

Je vois que la réponse standard est "ne pas cocher dans le fichier de projet, juste le .pom". Mais des éléments tels que les fichiers .ipr contiennent de nombreux paramètres utiles qui ne peuvent PAS être dérivés du fichier .pom. Et si d'autres utilisateurs d'IntelliJ souhaitaient partager ces paramètres? Je sais que les fichiers .ipr sont conçus pour être versionnés (voir ce fil par exemple). J'aimerais avoir une réponse réelle, mais je n'ai pas encore trouvé de bonne pratique dans ce domaine.

Answer 5

Mon avis est que nous devons nous garder de toute IDE de fichiers spécifiques de Contrôle de Version. L'idée est que nous devons nous garder autant que possible de l'information dans l'IDE indépendant formulaire comme pom Maven fichiers et ainsi de suite. Tous les paramètres du projet peut être qui y sont conservés. Et avoir 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 l'IDÉE de configuration du projet, mais tout autre IDE configuration spécifique. En outre, l' .idée dossier de style de la configuration d'un projet vraiment pollue la révision des journaux. Et nous voulons toujours garder l'IDÉE de projet, les paramètres de contrôle de version, nous pouvons au moins de les stocker dans une seule .dpi format de fichier.