Studio Android - Le répertoire .idea entier doit-il être ignoré dans git?

137

J'ai vu beaucoup d'exemples de .gitignorefichiers pour AndroidStudio , certains en contiennent .ideaet d'autres non.

Y a-t-il une bonne raison de ne pas ajouter tout le répertoire .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 être dans .gitignore?

dors
la source
J'ignore .ideasauf pour certains des fichiers ci-dessous .idea/runConfigurations/.
Daniel
1
superset: stackoverflow.com/questions/16736856/…
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

Réponses:

104

Vous pouvez consulter cette page:

IntelliJ doc sur les fichiers de configuration de 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 contient uniquement une partie des données de configuration se rapportant à un certain domaine fonctionnel qui se reflète 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 les emplacements de ses modules composants, les paramètres du compilateur, etc. Ainsi, ces fichiers peuvent (et doivent) être conservés sous contrôle de version.

Cependant, je déteste correctement rendre le projet dépendant de l'EDI (je travaille actuellement sur un projet réalisé avec NetBeans et ça fait mal 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 les dépendances et construire: gardez 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 exactement 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 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. 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.
mithrop
la source
9
Notez cependant le paragraphe suivant: "L'exception est le fichier workspace.xml. Il stocke vos paramètres personnels ... Il est donc peu probable que vous souhaitiez partager ce fichier avec vos collègues."
Dalbergia
40

OK, donc après quelques réponses «Oui» et «Non», j'ajoute une réponse «Oui et non» :)

Le problème est qu'il .ideaest utilisé à la fois pour la configuration de construction du projet (déclaration des dépendances) et les paramètres du projet (inspections, etc.).

Vous ne souhaitez certainement pas utiliser votre IDE pour la configuration de votre build, mais vous souhaiterez peut-être partager les paramètres entre l'équipe. Voilà pourquoi vous devez ignorer qu'une partie du .ideacontenu (comme le librariesdossier et le modules.xmlfichier), mais garder les autres dans le contrôle de version (par exemple copyright, dictionarieset les inspectionProfilesdossiers et fichiers sous .ideacomme dynamic.xml, codeStyleSettings.xml, etc.).

JBaruch
la source
Comment traiteraient spécifiquement les fichiers iml?
dors
1
Les fichiers iml doivent absolument être ignorés.
JBaruch
1
Je pense toujours que les configurations ne doivent pas être conservées dans des fichiers dépendants de l'IDE et que Maven / Gradle est donc préférable de le faire.
mithrop
@mithrop la chose est - vous ne pouvez pas déclarer ce type de configuration dans le fichier Maven / Gradle. C'est le format propriétaire d'Idea et il n'a pas d'alternatives portables dans Maven / Gradle.
JBaruch
Oh oui, tu as raison. Quoi qu'il en soit, si vous ne pouvez pas le mettre dans des fichiers maven / gradle, vous aurez un problème avec la prochaine fois que vous importerez le projet dans un autre IDE (ce qui est le problème que je déteste gérer). Mais je suis tout à fait d'accord avec vous (si vous lisez ma réponse, vous verrez que je le suis vraiment): vous incluez les fichiers ou non en fonction de vos besoins :)
mithrop
7

Le concept de conservation de la configuration du projet dans VC est valide. Je l'ai fait avec mon équipe parce que 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 standard de codage et les mêmes configurations de plugin.

La raison pour laquelle je qualifie cela par "in concept" est qu'il y avait 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 corrigés, 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 pas le temps ni le désir de rechercher des solutions sur la façon de faire. notre IDE fonctionne correctement.

Cela étant dit, les problèmes rencontrés sont les suivants:

  • La mise en symétrie des dossiers de projet ne fonctionne pas correctement. Lorsque je configure mes projets, je les lie dans 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 garde son projet dans un endroit différent, ou n'utilise tout simplement pas de liens symboliques, le répertoire entier sera absent du navigateur de projet car il recherche littéralement le lien symbolique. Ce qui est pire, c'est que je n'ai jamais pu 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 entre les 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 l'EDI est erroné. Je souhaite que ces définitions soient partagées intuitivement avec d'autres utilisateurs.
  • Les collègues ont continué à écraser les configurations parce que leur IDE écraserait 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, qui contiendrait un changement de configuration de projet, au lieu de modifier les configurations de son IDE, ou même de leur donner un choix, il remplacerait automatiquement 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. Afin de contourner ce problème, le développeur devrait littéralement arrêter cette instance de son IDE, extraire le dépôt et rouvrir son IDE. Cela n'a aucun sens de conserver une configuration partagée si l'EDI l'écrase instantanément avec la configuration actuellement en mémoire. Il'

J'ai déjà fait ces types de configurations IDE partagées dans VC avec Visual Studio et Netbeans et c'était toujours bien; mais avec .idea il se sent tout simplement inutilisable, ce qui est décevant. Je souhaite que JetBrains s'en occupe et en fasse une meilleure expérience utilisateur.

Jesse Greathouse
la source
> au lieu que leur IDE change de configuration, ou même leur donne un choix, il écraserait automatiquement la configuration .idea par la configuration actuelle en mémoire de leur IDE. Wow, c'est vraiment dommage. Bon à savoir!
Greg Price