Studio Android – Le répertoire .idea entier devrait-il être ignoré?

J’ai vu beaucoup d’exemples de fichiers .gitignore pour AndroidStudio , certains ont .idea et d’autres non.

Y a-t-il une bonne raison pour ne pas append l’intégralité du répertoire .idea à .gitignore?

S’il ne doit pas être complètement ignoré, y a-t-il des fichiers spécifiques à l’intérieur de .idea (tels que .iml) qui devraient être dans .gitignore?

Vous pouvez consulter cette page:

IntelliJ doc sur les fichiers de configuration du projet

Dans le “format basé sur l’annuaire”, une ligne particulière est intéressante:

Le répertoire .idea contient un ensemble de fichiers de configuration (.xml). Chaque fichier ne contient qu’une partie des données de configuration relatives à un domaine fonctionnel donné, qui se reflète dans le nom d’un fichier, par exemple, comstackr.xml , encodings.xml , modules.xml .

Presque tous les fichiers contiennent des informations de base sur le projet lui-même, telles que les noms et emplacements de ses modules composants, les parameters du compilateur, etc. Ainsi, ces fichiers peuvent (et doivent) être conservés sous contrôle de version.

Cependant, je HATE correctement pour rendre le projet dépendant de l’IDE (je travaille actuellement sur un projet réalisé avec NetBeans et il est difficile de l’utiliser avec Eclipse qui devient le standard de mon entreprise).

Donc, pour répondre à votre question :

  1. Si vous n’utilisez pas quelque chose comme Maven ou Gradle pour gérer des dépendances et générer: conservez le répertoire sous contrôle de version . De cette façon, la configuration correcte du projet et des dépendances sera disponible pour tout le monde. Dans la contrepartie, tous les développeurs devront définir leur environnement de la même manière que vous le définissez dans les fichiers de configuration.
  2. Si vous utilisez quelque chose comme Maven ou Gradle: configurez correctement ces outils et ne conservez pas le répertoire sous contrôle de version . En fait, toutes les informations contenues dans les fichiers de configuration doivent être stockées dans des fichiers Maven / Gradle. Laissez ensuite vos développeurs configurer leur IDE en fonction de leur environnement. De cette façon, utiliser Eclipse, IntelliJ, Linux, Windows … ne sera plus un problème.

OK, donc après quelques réponses “Oui” et “Non”, j’ajoute une réponse “Oui et non” 🙂

Le problème est que .idea est utilisé à la fois pour la configuration du projet (déclaration de dépendances) et pour les parameters du projet (inspections, etc.).

Vous ne voulez certainement pas utiliser votre IDE pour votre configuration de build, mais vous voudrez peut-être partager les parameters au sein de l’équipe. C’est pourquoi vous ne devez ignorer qu’une partie du contenu .idea (comme le dossier libraries et le fichier modules.xml ), mais en garder d’autres dans le contrôle de version (par exemple, inspectionProfiles dossiers copyright , dictionaries et inspectionProfiles et fichiers .idea comme dynamic.xml , codeStyleSettings.xml , etc.).

Le concept de maintien de la configuration du projet dans VC est valide. Je l’ai fait avec mon équipe car tous nos développeurs utilisaient PHPStorm pour nos projets et il était donc logique de garder une configuration commune… dans le concept. Nous voulions utiliser les mêmes fichiers de dictionnaire, les mêmes règles de codage standard et les mêmes configurations de plug-in.

La raison pour laquelle je qualifie cela de «in concept» est qu’il ya eu des problèmes avec le dossier .idea de JetBrains qui nous a empêchés de l’utiliser. Ce sont probablement des problèmes qui auraient pu être évités ou résolus, mais nous ne savions pas comment faire les choses correctement et nous pensons que cela est une faute de JetBrains car en tant que développeurs, nous n’avons ni le temps ni l’envie de rechercher des solutions notre IDE fonctionne correctement.

Cela étant dit, les problèmes ont été les suivants:

  • Les dossiers de projet Symlinking ne fonctionnent pas correctement. Lorsque je configure mes projets, je les connecte à mon répertoire personnel. Ce que nous avons découvert, c’est que le projet a été configuré pour utiliser le lien symbolique exact plutôt que de simplement le traiter comme un répertoire concret. Cela signifie que si un autre développeur conserve son projet dans un endroit différent ou n’utilise tout simplement pas de liens symboliques, tout le répertoire sera absent du navigateur de projet car il recherche littéralement le lien symbolique. Ce qui est pire, c’est que je ne pourrais jamais trouver cette valeur de chemin dans la configuration. Nous n’avons pas pu trouver la configuration exacte dans les fichiers constituant notre dossier .idea.
  • Les fichiers de définition sont partitionnés aux utilisateurs par défaut. Cela signifie que si je veux append un mot à mon dictionnaire, celui-ci sera répertorié comme une définition pour moi, jgreathouse, mais les autres utilisateurs auront leur propre section de définition. Les mots marqués apparaîtront toujours comme une faute d’orthographe pour les autres utilisateurs. Ce n’est pas souhaitable. La raison pour laquelle je l’ajoute à mon fichier de définition est que l’EDI est incorrect. Je souhaite que ces définitions soient partagées de manière intuitive avec les autres utilisateurs.
  • Les collègues ont continué à écraser les configurations car leur IDE remplaçait les configurations avec leur configuration actuellement en mémoire. Ce que je veux dire, c’est qu’un développeur travaillerait et fusionnerait son référentiel d’origine, ce qui contiendrait une modification de la configuration du projet, au lieu que leurs configurations de modification de l’EDI, ou même leur donnant le choix, écraseraient automatiquement la configuration .idea avec la configuration actuelle en mémoire de leur IDE. À mon avis, cela rend la configuration .idea inutilisable en tant que configuration partagée. Pour contourner ce problème, le développeur devrait littéralement fermer cette instance de son IDE, extraire le repository et rouvrir son IDE. Cela n’a aucun sens de conserver une configuration partagée si l’EDI le remplace instantanément par la configuration actuellement en mémoire. C’est comme ne pas avoir de configuration partagée du tout.

J’ai déjà effectué ces types de configurations IDE partagées dans VC avec Visual Studio et Netbeans et cela s’est toujours bien passé. mais avec .idea, cela semble tout simplement inutilisable, ce qui est décevant. Je souhaite que JetBrains soit au top et en fasse une meilleure expérience utilisateur.