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 code source afin que nous puissions 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 à peu près n'importe quoi dans IDEA. Il y a un problème dans la base de données des problèmes d' IDEA ( IDEA-64312 ), alors peut-être que l'on pourrait considérer cela comme un bogue dans IDEA, mais c'est un bogue avec lequel nous devrons vivre dans un avenir prévisible.
Jusqu'à récemment, nous utilisions Subversion, mais nous sommes récemment passés à Git. Chacun de nous venait de s'habituer à avoir une liste de modifications de fichiers de projet que nous ignorions et que nous ne archivions pas à moins qu'il y ait des modifications de fichier de projet que nous voulions partager avec d'autres. Mais avec Git, le vrai pouvoir semble être (d'après ce que nous explorons) le branchement continu qu'il encourage, et le basculement entre les branches est une douleur avec les fichiers de projet ayant toujours été modifiés. Souvent, il peut simplement fusionner les modifications d'une manière ou d'une autre et essaie de gérer les modifications du fichier de projet actuellement appliquées à la nouvelle branche. Cependant, si la nouvelle branche a changé les fichiers du projet (par exemple, la branche travaille sur un nouveau module qui n'est pas encore dans les autres branches), git lève simplement une erreur indiquant que ce n'est pas le cas. Cela n'a aucun sens de fusionner les fichiers lorsque la branche a des modifications et que vous avez des modifications localement, et je peux plutôt comprendre son point. Depuis la ligne de commande, on peut utiliser "-f" sur la commande "git checkout" pour le forcer à rejeter les modifications locales et à utiliser la branche à la place, mais (1) la commande Git Checkout GUI dans IDEA (10.5.1) ne semble pas avoir cela comme une option que nous pouvons trouver, nous aurions donc besoin de passer régulièrement à la ligne de commande, et (2) Nous ne sommes pas sûrs de vouloir avoir l'habitude de l'utiliser flag et dire à Git de rejeter nos modifications locales.
Alors, voici quelques réflexions que nous avons sur les options que nous devons gérer:
- Retirez complètement les fichiers de projet du contrôle de code source. Mettez-les dans le .gitignore, et distribuez-les à chaque personne et à TeamCity via d'autres moyens, peut-être en les mettant sous contrôle de code source ailleurs ou sous d'autres noms. Notre équipe est suffisamment petite pour que cette option soit suffisamment envisageable, mais cela ne semble pas génial.
- Continuez à vivre avec, en essayant d'être sûr de gérer quels fichiers nous avons sur quelles branches à un moment donné. Dans ce cadre, nous pourrions encourager chaque développeur à avoir plus d'une copie de chaque projet sur son système, afin qu'ils puissent avoir chacun extrait 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 code source, avec les fichiers de module (.iml) pas dans le contrôle de code source et dans le fichier .gitignore. La principale chose qui semble changer régulièrement dans le .ipr est l'ordre des configurations de construction partagées, mais peut-être pouvons-nous simplement partager les informations séparément sur la façon de les configurer. Je ne sais pas trop comment IDEA gère ce genre de chose en ne disposant que de certains de ses fichiers, en particulier lors d'une nouvelle extraction.
J'espère que j'espère qu'il y a une solution évidente (ou non) que nous avons manquée, peut-être traitant de l'énorme personnalisabilité que Git et IDEA semblent tous deux 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 Stack Overflow incluent 3495191 , 1000512 et 3873872 , mais je ne sais pas car il s'agit exactement du même problème, et peut-être que quelqu'un peut trouver les avantages et les inconvénients des différentes approches que j'ai décrites, les approches énumérées dans les réponses à ces questions, ou les approches qu'ils recommandent.