1333 votes

Que doit contenir mon fichier .gitignore pour un projet Android Studio ?

Quels fichiers devraient se trouver dans mon .gitignore pour un projet Android Studio ?

J'ai vu plusieurs exemples qui comprennent tous .iml mais les documents d'IntelliJ disent que .iml doit être inclus dans votre contrôle de source.

10 votes

0 votes

0 votes

1385voto

Lior Iluz Points 4348

Mise à jour vers Android Studio 3.0 Veuillez partager les éléments manquants dans les commentaires.

Une réponse tardive mais este La réponse alternative n'était pas la bonne pour nous ...

Donc, voici notre fichier gitignore :

#built application files
*.apk
*.ap_
*.aab

# files for the dex VM
*.dex

# Java class files
*.class

# generated files
bin/
gen/

# Local configuration file (sdk path, etc)
local.properties

# Windows thumbnail db
Thumbs.db

# OSX files
.DS_Store

# Android Studio
*.iml
.idea
#.idea/workspace.xml - remove # and delete .idea if it better suit your needs.
.gradle
build/
.navigation
captures/
output.json 

#NDK
obj/
.externalNativeBuild

Depuis Android Studio 2.2 et jusqu'à 3.0, les nouveaux projets sont créés avec ce fichier gitignore :

*.iml
.gradle
/local.properties
/.idea/workspace.xml
/.idea/libraries
.DS_Store
/build
/captures
.externalNativeBuild

Déprécié - pour un format de projet plus ancien, ajoutez cette section à votre fichier gitignore :

/*/out
/*/*/build
/*/*/production
*.iws
*.ipr
*~
*.swp

Ce fichier doit être situé dans le dossier racine du projet et non dans le dossier du module du projet.

Notes d'édition :

  1. Depuis la version 0.3+, il semble que vous pouvez commiter et pousser *. .iml y build.gradle fichiers. Si votre projet est basé sur Gradle : dans le nouveau dialogue d'ouverture/importation, vous devez cocher l'option "use auto import" et cochez la case "use default gradle wrapper (recommended)" bouton radio. Tous les chemins sont maintenant relatifs comme @George l'a suggéré.

  2. Réponse actualisée d'après @128KB source jointe et les suggestions de @Skela

8 votes

Pourquoi devons-nous importer le projet et ajouter manuellement les dépendances des librairies et des modules ? Existe-t-il un moyen de conserver ces éléments dans le repo et lorsque nous clonons le repo, il suffit d'ouvrir le projet ?

0 votes

@Justin nous n'avons pas trouvé de moyen de préserver les dépendances car elles sont écrites avec leur chemin complet et c'est un chemin différent pour chacun des membres de notre équipe... si vous trouvez un moyen, merci de partager :)

13 votes

La bonne façon de procéder est de vérifier les fichiers *.iml et *.ipr, et de les ouvrir dans l'IDE. Pourquoi obliger les autres membres de votre équipe à recréer ces fichiers, et pourquoi leur permettre d'utiliser des paramètres éventuellement incorrects (comme la version du sdk) ?

156voto

Phil Points 11964

Construire sur mon Android normal .gitignore et après avoir lu la documentation sur le site Web d'Intellij IDEA et les messages sur StackOverflow, j'ai construit le fichier suivant :

# built application files
*.apk
*.ap_

# files for the dex VM
*.dex

# Java class files
*.class

# built native files (uncomment if you build your own)
# *.o
# *.so

# generated files
bin/
gen/

# Ignore gradle files
.gradle/
build/

# Local configuration file (sdk path, etc)
local.properties

# Proguard folder generated by Eclipse
proguard/

# Eclipse Metadata
.metadata/

# Mac OS X clutter
*.DS_Store

# Windows clutter
Thumbs.db

# Intellij IDEA (see https://intellij-support.jetbrains.com/entries/23393067)
.idea/workspace.xml
.idea/tasks.xml
.idea/datasources.xml
.idea/dataSources.ids

Notez également que, comme cela a été souligné, le fichiers natifs construits est principalement utile lorsque vous créez votre propre code natif avec le NDK Android. Si, par contre, vous utilisez une bibliothèque tierce qui inclut ces fichiers, vous pouvez supprimer ces lignes (*.o et *.so) de votre fichier .gitignore.

10 votes

C'est presque ça. Je ne pense pas que ce soit une bonne idée d'ignorer *.so car vous ne pourrez pas travailler avec des projets qui ont des dépendances liées aux bibliothèques NDK. Mais c'est un très bon point de départ à tous points de vue !

0 votes

@Skela bon point. J'avais ces éléments à l'époque où je créais mes propres fichiers natifs, mais j'ai également travaillé sur des projets qui nécessitaient un simple copier-coller de fichiers préconstruits. J'ai ajouté une note à ce sujet dans la réponse ci-dessus.

0 votes

@Phil Avez-vous des opinions sur les fichiers XML dans .idea/libraries ? Devraient-ils être partagés ou exclus à votre avis ?

83voto

Sky Kelsey Points 3405

Mise à jour 7/2015 :

Voici le source définitive de JetBrains


Format de projet basé sur un répertoire (répertoire .idea)

Ce format est utilisé par défaut par toutes les versions récentes de l'IDE. Voici ce que vous devez partager :

  • Tous les fichiers sous .idea dans le répertoire Root du projet sauf le site workspace.xml y tasks.xml les fichiers qui stockent les paramètres spécifiques de l'utilisateur
  • Tous les .iml des fichiers de modules qui peuvent être situés dans différents répertoires de modules (s'applique à IntelliJ IDEA)

Soyez prudent. de partager ce qui suit :

  • Artéfacts Android qui produisent une construction signée (contiendra les mots de passe du keystore)
  • Dans IDEA 13 et les versions antérieures dataSources.ids , datasources.xml peut contenir les mots de passe de la base de données. IDEA 14 résout ce problème .

Vous pouvez envisager de ne pas partager les éléments suivants :

  • gradle.xml, voir cette discussion
  • le dossier des dictionnaires de l'utilisateur (pour éviter les conflits si un autre développeur a le même nom)
  • Les fichiers XML sous .idea/libraries au cas où ils le seraient généré par Gradle projet

Format de projet hérité ( .ipr / .iml / .iws fichiers)

  • Partager le projet .ipr et tous les fichiers .iml les fichiers du module, ne pas partager le site .iws car il stocke les paramètres spécifiques de l'utilisateur

Bien que ces instructions concernent IntelliJ IDEA, elles s'appliquent à 100 % à Android Studio.


Voici un .gitignore qui incorpore toutes les règles ci-dessus :

# Android Studio / IntelliJ IDEA 
*.iws
.idea/libraries
.idea/tasks.xml
.idea/vcs.xml
.idea/workspace.xml

0 votes

Les SDK pris en charge sont définis dans le fichier AndroidManifest.xml (et également par Gradle). Tout SDK autorisé par ce paramètre doit être ok pour le développement. Concernant les styles de code : ce n'est pas quelque chose qui doit être maintenu dans chaque projet séparément, et de plus, cela devrait être clarifié indépendamment de l'IDE. En-têtes de copyright : avec un peu de chance, ceux-ci se trouvent dans votre base de code et non dans les fichiers de projet de l'IDE. Sinon, la construction en ligne de commande ne les inclurait tout simplement pas...

0 votes

@Risadinha 1) Les SDK sont également définis au niveau de l'IDE. Ils sont référencés dans le Manifest, mais le fichier du projet contient les définitions réelles du SDK. 2) Le style du code devrait être maintenu AU MOINS au niveau du projet. Idéalement, tout le monde devrait écrire du Java standard, mais bon. 3) Les en-têtes de copyright sont stockés dans le projet. Ils sont utilisés pour la création de nouveaux fichiers, et peuvent contenir des macros pour le nom, le nom de la société, le projet, la date, etc. Je vous recommande de les consulter ! En résumé, les fichiers du projet contiennent des méta-informations importantes sur le projet qui doivent être partagées et contrôlées par l'équipe.

0 votes

@SkyKelsey merci pour la clarification. 1) le SDK ne doit être défini que dans Gradle et AndroidManifest. Le SDK ne doit pas interférer. L'intégration continue est agnostique de tout IDE. 2)+3) Je comprends que ce sont les seules raisons de versionner les fichiers de projet IDE. Je préfère maintenir les fichiers d'exportation de configuration des différents IDE de manière indépendante du projet, au niveau de l'équipe ou de l'entreprise (leur propre dépôt). Le dossier .idea contient des plugins et des éléments spécifiques à l'utilisateur, des bibliothèques en cache et des chemins relatifs. Maintenir des entrées .gitignore pour cela - cela vaut-il la peine ?

38voto

helbaroudy Points 324

J'utilise ce .gitignore. Je l'ai trouvé à : http://th4t.net/Android-studio-gitignore.html

*.iml
*.iws
*.ipr
.idea/
.gradle/
local.properties

*/build/

*~
*.swp

1 votes

*/build/ n'ignore pas les fichiers inchangés dans mon répertoire de construction. des idées ? @Solved : j'ai dû ajouter */*/build/ car mon répertoire de construction était profond de quelques répertoires.

0 votes

Utilisez seulement build/ pour ignorer tout fichier dans un dossier nommé build, quel que soit l'endroit où il se trouve ou qu'il soit imbriqué dans le dossier que l'on a choisi. .gitignore est dans. Utilisation de /build/ n'ignorera qu'un dossier de construction directement dans le niveau supérieur. Utilisation de */build/ ne recherche que les dossiers de construction imbriqués à une profondeur de 1. Utilisation de **/build/ cherchera récursivement - je ne suis pas sûr si cela commence au niveau supérieur ou à un niveau de profondeur (si au niveau supérieur, alors ce serait la même chose que build/ cependant, donc...)

36voto

Siva Velusamy Points 1116

Dans le cas d'Android Studio, les seuls fichiers qui doivent être enregistrés dans le contrôle de version sont les fichiers nécessaires pour construire l'application à partir de la ligne de commande en utilisant gradle. Vous pouvez donc les ignorer :

  • *.iml
  • .idée
  • construire

Cependant, si vous enregistrez des paramètres de l'IDE, tels que des paramètres de style de code personnalisés, ils sont enregistrés dans le dossier .idea. Si vous souhaitez que ces modifications soient prises en compte dans le contrôle de version, vous devez également enregistrer les fichiers IDEA (*.iml et .idea).

3 votes

Merci de l'explication. D'après ce que j'ai lu, si vous voulez inclure .idea dans votre projet, vous devez ignorer */.idea/workspace.xml et */.idea/tasks.xml.

15 votes

N'ignorez pas le dossier .idea pour le moment. Le plugin Gradle n'a pas encore de tâche 'gradle idea' et l'importation de projet dans Android Studio est loin d'être parfaite.

2 votes

De plus, si vous travaillez en équipe, pensez à ignorer local.properties car il contient le chemin du sdk en code dur.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X