Android studio – devrait tout le répertoire .idea être dans git ignorer?

J'ai vu beaucoup d'exemples pour les fichiers .gitignore pour AndroidStudio , certains ont .idea en eux, et d'autres pas.

Y a-t-il une bonne raison de ne pas ajouter l'entier .idea dir à .gitignore?

  • APKtools (APK Studio) Impossible décoder le fichier arsc
  • Android: l'élévation ne fonctionne pas en L Aperçu
  • Existe-t-il une règle de proguard valide pour RxJava et FasterXML?
  • Exécution de la simulation d'Android Visualizer
  • Puis-je passer différents types de paramètres à un AsyncTask dans Android?
  • Comportement ambigu du nouveau caractère de ligne
  • Si cela ne doit pas être complètement ignoré, y at-il des fichiers spécifiques à l'intérieur de .idea (tels que .iml) qui devraient être dans .gitignore?

  • Android Tablet - Obtenez un identifiant d'appareil unique
  • Vérifiez si le verrouillage a été activé ou non
  • Comment connecter une application Android à une base de données distante?
  • Est-il possible de rafraîchir la vue d'un fragment
  • Taille maximale de la base de données SQLite en mémoire d'une application Android?
  • La vue vidéo modifie 90 degrés dans l'Android
  • 4 Solutions collect form web for “Android studio – devrait tout le répertoire .idea être dans git ignorer?”

    Vous pouvez jeter un oeil à cette page:

    Documentation IntelliJ 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 ne contient qu'une partie des données de configuration relatives à une certaine zone fonctionnelle qui se reflète dans le nom d'un fichier, par exemple, compiler.xml , encodings.xml , modules.xml .

    La quasi-totalité des fichiers contiennent des informations essentielles au projet lui-même, telles que les noms et les emplacements de ses modules de composants, les paramètres du compilateur, etc. Ainsi, ces fichiers peuvent (et devraient) être conservés sous contrôle de version.

    Cependant, je déteste correctement le développement du projet IDE (je travaille actuellement sur un projet réalisé avec NetBeans et ça fait mal de l'utiliser avec Eclipse qui devient le standard de ma société).

    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: conservez le répertoire sous le contrôle de la version . De cette façon, la configuration correcte du projet et des dépendances sera disponible pour tous. Dans la contrepartie, tous les développeurs devront définir leur environnement exactement de la même façon 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 les fichiers Maven / Gradle. Ensuite, laissez vos développeurs configurer leur IDE en fonction de leur environnement. De cette façon, en utilisant 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é pour la configuration de la 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 votre configuration de construction, mais vous voudrez peut-être partager les paramètres de l'équipe. C'est pourquoi vous ne devez ignorer qu'une partie du contenu .idea (comme le dossier des libraries et le fichier modules.xml ), mais gardez les autres dans le contrôle de la version (p. Ex. Les copyright , les dictionaries et inspectionProfiles dossiers et les fichiers d' inspectionProfiles sous .idea comme dynamic.xml , codeStyleSettings.xml , etc.).

    La notion de maintien de la configuration du projet dans VC est valide. Je l'ai fait avec mon équipe parce que tous nos développeurs ont eu recours à PHPStorm pour nos projets et qu'il était logique de garder une configuration commune … en concept. Nous voulions utiliser les mêmes fichiers de dictionnaire, les mêmes règles standard de codage et les mêmes configurations de plugins.

    La raison pour laquelle je qualifier ceci avec "in concept" est parce qu'il y avait des problèmes avec le dossier .idea de JetBrains qui nous a amené à ne pas pouvoir l'utiliser. Ce sont probablement des problèmes qui auraient pu être évités ou corrigés, mais il ne nous a pas été clair de savoir 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 envie de rechercher des solutions sur la façon de créer Notre IDE fonctionne correctement.

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

    • Les dossiers de projet Symlinking ne fonctionnent pas correctement. Lorsque j'ai configuré mes projets, je les symbolise 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 le traiter comme un répertoire concret. Cela signifie que si un autre développeur conserve son projet à un endroit différent, ou tout simplement n'utilise pas de liens symboliques, l'intégralité du répertoire manquera au navigateur du 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 partagés aux 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 d'autres utilisateurs auront leur propre section de définition. Les mots marqués apparaîtront encore comme une erreur 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'IDE a tort. Je veux 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 que, un développeur fonctionnerait et fusionnerait son référentiel d'origine, qui contiendrait un changement de configuration de projet, au lieu de ses configurations changeantes IDE, ou même en leur donnant le choix, il remplacerait automatiquement la configuration .idea avec La configuration actuelle en mémoire de leur IDE. À mon avis, la configuration .idea est inutilisable en tant que configuration partagée. Afin de contourner cela, le développeur devrait littéralement fermer cette instance de leur IDE, retirer le compte de rechange et rouvrir leur IDE. Il est inutile de garder une configuration partagée si l'IDE l'écrase instantanément avec la configuration actuellement en mémoire. C'est comme ne pas avoir une configuration partagée du tout.

    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 souhaiterais que JetBrains soit sur le dessus et qu'il en soit une meilleure expérience utilisateur.

    J'ajoute toujours ce répertoire dans gitignore. Tous les fichiers qui le contiennent sont générés chaque fois que vous reconstruisez un projet. Ces fichiers ne jouent pas un rôle important dans le projet, mais vous pouvez avoir des problèmes ou des problèmes lors de l'assemblage dans un futur.

    coAndroid est un fan Android de Google, tout sur les téléphones Android, Android Wear, Android Dev et Android Games Apps.