Comment traiter les fichiers de projet IntelliJ IDEA sous contrôle de source Git en constante évolution?)
Tous les membres de notre équipe utilisent IntelliJ IDEA et nous trouvons utile de placer ses fichiers de projet (.ipr et .iml) dans le contrôle de source afin de pouvoir partager les configurations de construction, les paramètres et les inspections. De plus, nous pouvons ensuite utiliser ces paramètres d'inspection sur notre serveur d'intégration continue avec TeamCity. (Nous avons le fichier .iws de l'espace de travail par utilisateur dans le fichier .gitignore et non dans le contrôle de code source.)
Cependant, ces fichiers changent peu lorsque vous faites pratiquement n'importe quoi dans IDEA. Il y a un problème dans la base de données d'IDEA pour ce problème ( IDEA-64312 ), donc on pourrait peut-être considérer cela comme un bogue dans IDEA, mais c'est un problème avec lequel nous devrons vivre dans un avenir proche.
Jusqu'à récemment, nous utilisions Subversion, mais nous sommes récemment passés à Git. Chacun de nous venait juste de prendre l'habitude d'avoir une liste de modifications de fichiers de projet que nous avons ignorée et que nous n'avons pas archivée, à moins qu'il y ait des modifications de fichiers de projet que nous souhaitons partager avec d'autres. Mais avec Git, le vrai pouvoir semble provenir (de ce que nous explorons) du branchement continu qu’il encourage, et passer d’une branche à l’autre est une tâche ardue, les fichiers de projet ayant toujours été modifiés. Souvent, il peut simplement fusionner les modifications et tenter de gérer les modifications du fichier de projet actuellement appliquées à la nouvelle branche. Cependant, si la nouvelle branche a modifié les fichiers du projet (par exemple, la branche travaille sur un nouveau module qui ne figure pas encore dans les autres branches), git génère simplement une erreur indiquant qu'il n'est pas logique de fusionner les fichiers. lorsque la branche a des modifications et que vous avez des modifications localement, je comprends mieux son propos. A partir de la ligne de commande, vous pouvez utiliser "-f" dans la commande "git checkout" pour le forcer à annuler les modifications locales et à utiliser celle de la branche, mais (1) la commande Git Checkout GUI dans IDEA (10.5.1) ne semble pas avoir cette option à notre disposition. Nous devons donc passer régulièrement à la ligne de commande et (2) nous ne sommes pas certains de vouloir être l'habitude d'utiliser ce drapeau et de dire à Git de rejeter nos modifications locales.
Alors, voici quelques réflexions sur les options que nous devons prendre en charge:
- Retirez complètement les fichiers du projet du contrôle de source. Mettez-les dans le répertoire .gitignore et distribuez-les à chaque personne et à TeamCity par un autre moyen, en les mettant éventuellement sous le contrôle du code source, ou sous d'autres noms. Notre équipe est suffisamment petite pour que cette option soit envisageable, mais elle ne semble pas géniale.
- Continuez à vivre avec, en essayant de vous assurer de gérer quels fichiers nous avons dans quelles branches à un moment donné. Dans ce cadre, nous pourrions encourager chaque développeur à avoir plusieurs copies de chaque projet sur son système, afin de pouvoir les extraire dans une branche différente avec éventuellement des ensembles de fichiers de projet différents.
- Essayez d’avoir uniquement le projet (.ipr) dans le contrôle de source, avec les fichiers de module (.iml) absents du contrôle de source et dans le fichier .gitignore. La principale chose qui semble basculer d'elle-même dans le .ipr régulièrement est l'ordre des configurations de build partagées, mais peut-être pourrions-nous simplement partager les informations séparément sur la manière de les configurer. Je ne suis pas tout à fait sûr de savoir comment IDEA gère ce genre de choses en ne conservant que certains de ses fichiers, en particulier lors d'une nouvelle extraction.
J'espère que nous avons oublié une solution évidente (ou non évidente), peut-être en ce qui concerne l'énorme possibilité de personnalisation que Git et IDEA semblent avoir. Mais il semble que nous ne pourrions pas être la seule équipe à avoir ce problème. Les questions qui sont un peu similaires sur StackOverflow incluent 495191 , 1000512 , et 873872 , mais je ne sais pas car elles sont exactement les mêmes. problème, et peut-être que quelqu'un peut présenter le pour et le contre des diverses approches que j'ai décrites, des approches énumérées dans les réponses à ces questions ou des approches qu'ils recommandent.
Je vous remercie.
Vous pouvez utiliser la structure de projet basée sur les répertoires d'IDEA , où les paramètres sont stockés dans le répertoire .idea au lieu du fichier .ipr. Cela donne plus un contrôle fin sur ce qui est stocké dans le contrôle de version. Les fichiers .iml seront toujours présents, ce qui ne résoudra pas les modifications aléatoires de ceux-ci (gardez-les peut-être hors du contrôle des sources?), Mais il est facile de partager des éléments tels que le style de code et les profils d'inspection. dans son propre fichier sous le répertoire .idea.
Du DOC officiel: http://devnet.jetbrains.com/docs/DOC-1186
Selon le format de projet IntelliJ IDEA (basé sur un fichier .ipr ou sur un répertoire .idea)), vous devez placer les fichiers IntelliJ IDEA sous le contrôle de version) :
Format de fichier .ipr
Partagez le fichier .ipr du projet et tous les fichiers de module .iml. Ne partagez pas le fichier .iws car il stocke les paramètres spécifiques à l'utilisateur.
Format basé sur le répertoire .idea
Partagez tous les fichiers du répertoire .idea à la racine du projet, à l'exception des fichiers workspace.xml et tasks.xml, qui stockent les paramètres spécifiques à l'utilisateur, partagent également tous les fichiers de module .iml.
Je le mets dans mon .gitignore:
#Project
workspace.xml
tasks.xml
Un réponse officielle disponible . En supposant que vous utilisez le format de projet de dossier moderne (et maintenant par défaut) .idea:
- Ajouter tout ...
- Sauf
.idea/workspace.xml(Qui est spécifique à l'utilisateur) - Sauf
.idea/tasks.xml(Qui est spécifique à l'utilisateur) - Sauf quelques autres fichiers pouvant contenir des mots de passe/clés/etc. (voir le lien ci-dessus pour plus de détails)
Ce exemple de fichier .gitignore peut constituer une référence utile, mais vous devez tout de même lire le lien ci-dessus pour comprendre pourquoi ces entrées apparaissent et décider si vous en avez besoin.
Personnellement, j'ignore aussi le fichier .idea/find.xml, Car il semble que cela change chaque fois que vous effectuez une opération de recherche.
J'ai sorti workspace.xml du contrôle de code source (+ ajouté à .gitignore).
Notre équipe ne contrôle pas les fichiers IntelliJ spécifiques au chemin. Nous supposons que les utilisateurs savent utiliser IDE et configurer un projet. Les fichiers IntelliJ entrent dans la liste des modifications "ignorées".
MISE À JOUR:
La réponse est plus facile maintenant que j'utilise Maven et sa structure de répertoires par défaut.
IntelliJ doit être invité à ignorer tous les fichiers de /.svn, /.idea et /target Dossiers. Tout ce qui concerne les informations de chemin d'un individu est stocké dans /.idea.
Tout le reste est un jeu juste pour être engagé à Subversion ou Git.
Juste pour partager une autre approche utilisée par mon équipe: déplacez simplement les fichiers connexes IDE) vers un autre emplacement non reconnu par IntelliJ, et créez un script pour les copier à l'emplacement "actif" souhaité. est ignoré par GIT.
L’avantage de cette approche est que vous avez conservé l’option de partage des paramètres IDE via le contrôle de version. Le seul inconvénient est que vous devez décider quand exécuter le script (probablement une fois par clone d’espace de travail ou lorsque des modifications sont apportées). sont souhaités), et vous pouvez l’automatiser en incorporant le script dans votre processus de construction ou votre point d’accès post-fusion.
Cette approche repose sur le fait qu'IntelliJ ne recherche ses fichiers de paramètres que dans des emplacements particuliers. Elle s'applique donc également aux fichiers de configuration de la structure. En fait, nous avons ignoré le fichier .properties de Grails de la même manière, afin que les développeurs ne archivent pas accidentellement leurs modifications de configuration locales.