Android studio: ¿debería ignorar todo el directorio .idea en git?


137

Vi muchos ejemplos de .gitignorearchivos para AndroidStudio , algunos tienen .ideaen ellos y otros no.

¿Hay una buena razón para no agregar todo el directorio .idea a .gitignore?

Si no se debe ignorar por completo, ¿hay archivos específicos dentro de .idea (como .iml) que deberían estar en .gitignore?


Ignoro a .ideaexcepción de algunos de los archivos debajo .idea/runConfigurations/.
Daniel

Respuestas:


104

Puedes echar un vistazo a esta página:

IntelliJ doc sobre archivos de configuración del proyecto

En el "formato basado en directorio", una línea particular es interesante:

El directorio .idea contiene un conjunto de archivos de configuración (.xml). Cada archivo contiene sólo una parte de los datos de configuración relativos a un determinado área funcional que se refleja en el nombre de un archivo, por ejemplo, compiler.xml, encodings.xml, modules.xml.

Casi todos los archivos contienen información básica del proyecto en sí, como nombres y ubicaciones de sus módulos componentes, configuraciones del compilador, etc. Por lo tanto, estos archivos pueden (y deben) mantenerse bajo control de versión.

Sin embargo, ODIO correctamente hacer que el proyecto dependa de IDE (actualmente estoy trabajando en un proyecto hecho con NetBeans y me duele usarlo con Eclipse, que se convierte en el estándar de mi empresa).

Entonces, para responder a su pregunta:

  1. Si no usa algo como Maven o Gradle para administrar dependencias y compilar: mantenga el directorio bajo control de versiones . De esta manera, la configuración correcta del proyecto y las dependencias estarán disponibles para todos. En la contraparte, todos los desarrolladores tendrán que configurar su entorno exactamente de la misma manera que lo define en los archivos de configuración.
  2. Si usa algo como Maven o Gradle: configure correctamente estas herramientas y no mantenga el directorio bajo control de versiones . En realidad, toda la información contenida dentro de los archivos de configuración debe almacenarse en archivos Maven / Gradle. Luego, permita que sus desarrolladores configuren su IDE dependiendo de su entorno. De esta manera, usar Eclipse, IntelliJ, Linux, Windows ... ya no será un problema.

9
Sin embargo, tenga en cuenta el siguiente párrafo: "La excepción es el archivo workspace.xml. Almacena su configuración personal ... Por lo tanto, es poco probable que desee compartir este archivo con sus colegas".
Dalbergia

40

OK, así que después de algunas respuestas "Sí" y "No", agrego una respuesta "Sí y no" :)

El problema es que .idease usa tanto para la configuración de compilación del proyecto (declaración de dependencias) como para la configuración del proyecto (inspecciones, etc.).

Definitivamente no desea utilizar su IDE para su configuración de compilación, pero es posible que desee compartir la configuración entre el equipo. Es por eso que necesita hacer caso omiso de sólo una parte del .ideacontenido (como la librariescarpeta y el modules.xmlarchivo), pero mantener a otros en el control de versiones (por ejemplo, la copyright, dictionariesy inspectionProfileslas carpetas y los archivos bajo .ideacomo dynamic.xml, codeStyleSettings.xml, etc.).


¿Cómo abordaría específicamente los archivos iml?
Dors

1
Los archivos iml definitivamente deben ser ignorados.
JBaruch

1
Todavía estoy pensando que las configuraciones no deben mantenerse en archivos dependientes de IDE, por lo que Maven / Gradle es mejor hacerlo.
mithrop

@mithrop es que no puedes declarar este tipo de configuración en el archivo Maven / Gradle. Es el formato propio de Idea y no tiene alternativas portátiles en Maven / Gradle.
JBaruch

Oh sí, tienes razón. De todos modos, si no puede ponerlo en archivos maven / gradle, tendrá un problema la próxima vez que importe el proyecto en otro IDE (que es el problema que odio manejar). Pero estoy totalmente de acuerdo con usted (si lee mi respuesta, verá que realmente lo estoy): incluye los archivos o no dependiendo de sus necesidades :)
mithrop

7

El concepto de mantener la configuración del proyecto en VC es válido. Hice esto con mi equipo porque todos nuestros desarrolladores utilizaron PHPStorm para nuestros proyectos, por lo que tenía sentido mantener una configuración común ... en concepto. Queríamos usar los mismos archivos de diccionario, las mismas reglas estándar de codificación y las mismas configuraciones de complementos.

La razón por la que califico esto con "en concepto" es porque hubo problemas con la carpeta .idea de JetBrains que nos llevaron a no poder usarla. Probablemente se trata de problemas que podrían haberse evitado o solucionado, pero no teníamos claro cómo hacerlo bien, y creemos que es culpa de JetBrains porque, como desarrolladores, no tenemos tiempo ni ganas de buscar soluciones sobre cómo hacer Nuestro IDE funciona correctamente.

Dicho esto, los problemas que se tuvieron son los siguientes:

  • Las carpetas de proyectos de Symlinking no funcionan bien. Cuando configuro mis proyectos, los enlace simbólicamente en mi directorio de inicio. Lo que descubrimos fue que el proyecto se configuró para usar el enlace simbólico exacto en lugar de solo tratarlo como un directorio concreto. Esto significa que si otro desarrollador mantiene su proyecto en un lugar diferente, o simplemente no usa enlaces simbólicos, faltará todo el directorio del navegador del proyecto porque literalmente está buscando el enlace simbólico. Lo peor es que nunca pude encontrar este valor de ruta en la configuración. No pudimos encontrar la configuración exacta en los archivos que constituyen nuestra carpeta .idea.
  • Los archivos de definición están particionados para los usuarios de manera predeterminada. Esto significa que si quiero agregar una palabra a mi diccionario, aparecerá como una definición para mí, jgreathouse, pero otros usuarios tendrán su propia sección de definición. Las palabras marcadas seguirán apareciendo como un error ortográfico para otros usuarios. Esto no es deseable. La razón por la que lo agrego a mi archivo de definición es porque el IDE está mal. Quiero que estas definiciones se compartan intuitivamente con otros usuarios.
  • Los colegas siguieron sobrescribiendo las configuraciones porque su IDE sobrescribiría las configuraciones con su configuración actualmente en la memoria. Lo que quiero decir es que un desarrollador estaría trabajando y fusionaría su repositorio desde el origen, que contendría un cambio en la configuración del proyecto, en lugar de que su IDE cambie las configuraciones, o incluso dándoles una opción, sobrescribiría automáticamente la configuración .idea con La configuración actual en memoria de su IDE. En mi opinión, esto hace que la configuración .idea sea inutilizable como una configuración compartida. Para evitar esto, el desarrollador literalmente tendría que cerrar esa instancia de su IDE, extraer el repositorio y volver a abrir su IDE. No tiene sentido mantener una configuración compartida si el IDE la sobrescribe instantáneamente con la configuración actualmente en memoria. Eso'

He hecho este tipo de configuraciones IDE compartidas en VC antes con Visual Studio y Netbeans y siempre estuvo bien; pero con .idea se siente simplemente inutilizable, lo cual es decepcionante. Desearía que JetBrains se pusiera al día y lo convirtiera en una mejor experiencia de usuario.


> en lugar de que sus configuraciones de IDE cambien, o incluso de darles una opción, sobrescribirá automáticamente la configuración .idea con la configuración actual en memoria de su IDE. Wow, eso es realmente desafortunado. ¡Bueno saber!
Greg Price
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.