Android studio - l'ensemble du répertoire .idea doit-il être ignoré?
J'ai vu beaucoup d'exemples de fichiers .gitignore pour AndroidStudio, certains contiennent .idea et d'autres pas.
Existe-t-il une bonne raison de ne pas ajouter l'intégralité du fichier .idea à .gitignore?
S'il ne doit pas être complètement ignoré, y a-t-il des fichiers spécifiques dans .idea (tels que .iml) qui devraient figurer dans .gitignore?
Vous pouvez jeter un oeil à cette page:
doc IntelliJ 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 à une zone fonctionnelle donnée, ce qui est reflété dans le nom d'un fichier, par exemple,
compiler.xml,encodings.xml,modules.xml.Presque tous les fichiers contiennent des informations essentielles au projet lui-même, telles que les noms et emplacements de ses modules composants, les paramètres du compilateur, etc. . Ainsi, ces fichiers peuvent (et doivent) être conservés sous la version. contrôle.
Cependant, j'ai HÂTEMENT de rendre le projet dépend 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 :
- Si vous n'utilisez pas quelque chose comme Maven ou Gradle pour gérer les dépendances et construire: conservez le répertoire sous contrôle de version . De cette façon, la configuration correcte du projet et des dépendances seront disponibles pour tout le monde. Dans la contrepartie, tous les développeurs devront définir leur environnement exactement de la même manière que vous le définissez dans les fichiers de configuration.
- Si vous utilisez quelque chose comme Maven ou Gradle: configurez correctement ces outils et ne gardez 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. Puis, laissez 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 de construction du projet (déclaration de dépendances) et pour les paramètres de projet (inspections, etc.).
Vous ne voulez certainement pas utiliser votre IDE pour votre configuration de construction, mais vous pouvez partager les paramètres avec 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 conserver d'autres dans le contrôle de version (par exemple, le copyright, dictionaries et inspectionProfiles dossiers et fichiers sous .idea comme dynamic.xml, codeStyleSettings.xml, etc.).
Le concept de conservation de la configuration du projet dans VC est valide. C'est ce que j'ai fait avec mon équipe, car tous nos développeurs ont utilisé PHPStorm pour nos projets. Il était donc logique de conserver une configuration commune ... conceptuelle. Nous voulions utiliser les mêmes fichiers de dictionnaire, les mêmes règles standard de codage et les mêmes configurations de plug-in.
La raison pour laquelle je qualifie cela de "in concept" est parce qu'il y a eu des problèmes avec le dossier .idea de JetBrains qui nous ont empêchés de l'utiliser. C'étaient probablement des problèmes qui auraient pu être évités ou résolus, mais nous ne savions pas comment le faire correctement, et nous pensons que c'est une faute de JetBrains, car en tant que développeurs, nous n'avons ni le temps ni le temps de chercher des solutions pour faire notre IDE fonctionne correctement.
Cela étant dit, les problèmes rencontrés sont les suivants:
- Symlinking dossiers de projet ne fonctionne pas correctement. Lorsque je configure mes projets, je les lie symboliquement vers mon répertoire personnel. Ce que nous avons découvert, c’est que le projet était configuré pour utiliser le lien symbolique exact plutôt que de le traiter comme un répertoire concret. Cela signifie que si un autre développeur conserve son projet à un endroit différent ou n'utilise tout simplement pas de liens symboliques, le répertoire entier sera manquant dans le navigateur de projet car il recherche littéralement le lien symbolique. Le pire est que je n'ai jamais pu trouver cette valeur de chemin dans la configuration. Nous n'avons pas trouvé la configuration exacte dans les fichiers constituant notre dossier .idea.
- Les fichiers de définition sont partitionnés en utilisateurs par défaut. Cela signifie que si je veux ajouter un mot à mon dictionnaire, il 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 le IDE est incorrect. Je souhaite que ces définitions soient partagées intuitivement avec d'autres utilisateurs.
- Les collègues ont continué à écraser les configurations car leur IDE écraserait les configurations avec leur configuration actuellement en mémoire. Ce que je veux dire, c’est qu’un développeur fonctionnerait et fusionnerait son référentiel d’Origin, qui contiendrait un changement de configuration du projet, au lieu de IDE changer les configurations, ou même en leur donnant le choix, cela se ferait automatiquement. écrasez la configuration .idea par 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 référentiel et rouvrir son IDE. Il n’a aucun sens de conserver une configuration partagée si le IDE l’écrase instantanément avec la configuration actuellement en mémoire. C'est comme ne pas avoir de configuration partagée du tout.
J'ai déjà utilisé ces types de configurations IDE partagées dans VC auparavant avec Visual Studio et Netbeans, et tout s'est toujours bien passé. mais avec .idea on se sent tout simplement inutilisable, ce qui est décevant. Je souhaite que JetBrains puisse en tirer le meilleur parti et en faire une meilleure expérience utilisateur.