Estudio de Android: ¿debería ignorar todo el directory .idea en git?

Vi muchos ejemplos de files .gitignore para .gitignore , algunos tienen .idea en ellos, y otros no.

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

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

Puedes echarle un vistazo a esta página:

IntelliJ doc sobre los files de configuration del proyecto

En el "Formato basado en el directory", una línea en particular es interesante:

El directory .idea contiene un set de files de configuration (.xml). Cada file contiene solo una parte de los datos de configuration pertenecientes a un área funcional determinada que se refleja en el nombre de un file, por ejemplo, compiler.xml , encodings.xml , modules.xml .

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

Sin embargo, ODIO de forma adecuada el proyecto IDE-dependiente (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).

Por lo tanto, para responder a su pregunta:

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

OK, entonces después de algunas respuestas "Sí" y "No", agrego una respuesta "Sí y no" 🙂

El problema es que .idea se usa tanto para la configuration de compilation del proyecto (statement de dependencies) como para la configuration del proyecto (inspecciones, etc.).

Definitivamente no quiere usar su IDE para su configuration de compilation, pero es posible que desee compartir las configuraciones entre el equipo. Es por eso que debe ignorar solo una parte del contenido .idea (como la carpeta libraries y el file modules.xml ), pero mantener a otros en el control de la versión (por ejemplo, copyright , dictionaries y inspectionProfiles carpetas y files en .idea como dynamic.xml , codeStyleSettings.xml , etc.).

El concepto de mantener la configuration del proyecto en VC es válido. Hice esto con mi equipo porque todos nuestros desarrolladores usaron PHPStorm para nuestros proyectos, por lo que tenía sentido mantener una configuration común … en concepto. Queríamos utilizar los mismos files de dictionary, las mismas reglas estándar de encoding y las mismas configuraciones de complementos.

La razón por la cual califico esto con "en concepto" es porque hubo problemas con la carpeta .idea de JetBrains que nos llevaron a no poder usarlo. Probablemente estos fueron problemas que podrían haberse evitado o corregido, pero no estaba claro cómo hacerlo bien, y creemos que es culpa de JetBrains porque como desarrolladores no tenemos time ni deseo de search soluciones sobre cómo hacer nuestro IDE funciona correctamente

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

  • El enlace simbólico de las carpetas de proyectos no funciona bien. Cuando configuro mis proyectos, los enlace simbólicamente a mi directory personal. Lo que descubrimos fue que el proyecto estaba configurado para utilizar el enlace simbólico exacto en lugar de tratarlo como un directory concreto. Esto significa que si otro desarrollador mantiene su proyecto en un lugar diferente, o simplemente no usa enlaces simbólicos, el directory completo no estará presente en el browser del proyecto porque literalmente está buscando el enlace simbólico. Lo que es peor es que nunca pude encontrar el valor de esta ruta en la configuration. No pudimos encontrar la configuration exacta en los files que constituyen nuestra carpeta .idea.
  • Los files de definición están particionados a los usuarios de forma pnetworkingeterminada. Esto significa que si quiero agregar una palabra a mi dictionary, se includeá 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 de ortografía para otros usuarios. Esto no es deseable. La razón por la que lo agrego a mi file de definición es porque el IDE está equivocado. Quiero que estas definiciones se compartan intuitivamente con otros usuarios.
  • Los colegas continuaron sobrescribiendo las configuraciones porque su IDE sobrescribiría las configuraciones con su configuration actualmente en la Memoria. Lo que quiero decir es que un desarrollador estaría trabajando y fusionar su repository desde el origen, que contendría un cambio en la configuration del proyecto, en lugar de cambiar las configuraciones de IDE, o incluso dándoles una opción, sobrescribiría automáticamente la configuration .idea con la configuration actual en memory de su IDE. En mi opinión, esto hace que la configuration .idea no se pueda utilizar como una configuration compartida. Para evitar esto, el desarrollador tendría que cerrar literalmente esa instancia de su IDE, extraer el repository y volver a abrir su IDE. No tiene sentido mantener una configuration compartida si el IDE la sobrescribe instantáneamente con la configuration actualmente en la memory. Es como no tener una configuration compartida en absoluto.

He hecho estos types 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. Ojalá JetBrains se pusiera al stream y mejorara la experiencia del usuario.

Siempre agrego este directory en gitignore. Todos los files que contiene se generan cada vez que reconstruye el proyecto. Estos files no juegan un papel importante en el proyecto, pero puede tener errores o problemas durante el ensamblado en el futuro.