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

ignore file git android studio (3)

El concepto de mantener la configuración 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 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 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 tiempo ni deseo de buscar 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 directorio personal. Lo que descubrimos fue que el proyecto estaba configurado para utilizar el enlace simbólico exacto en lugar de 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, el directorio completo no estará presente en el navegador 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 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 a los usuarios de forma predeterminada. Esto significa que si quiero agregar una palabra a mi diccionario, se incluirá 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 archivo 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 configuración actualmente en la Memoria. Lo que quiero decir es que un desarrollador estaría trabajando y fusionar su repositorio desde el origen, que contendría un cambio en la configuración del proyecto, en lugar de cambiar las configuraciones de IDE, 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 no se pueda utilizar como una configuración compartida. Para evitar esto, el desarrollador tendría que cerrar literalmente 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 la memoria. Es como no tener una configuración compartida en absoluto.

He hecho estos tipos 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 corriente y mejorara la experiencia del usuario.

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

¿Hay alguna 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?

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 configuración de compilación del proyecto (declaración de dependencias) como para la configuración del proyecto (inspecciones, etc.).

Definitivamente no quiere usar su IDE para su configuración de compilación, 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 archivo modules.xml ), pero mantener a otros en el control de la versión (por ejemplo, copyright , dictionaries y inspectionProfiles carpetas y archivos en .idea como dynamic.xml , codeStyleSettings.xml , etc.).

Puedes echarle un vistazo a esta página:

IntelliJ doc sobre los archivos de configuración del proyecto

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

El directorio .idea contiene un conjunto de archivos de configuración (.xml). Cada archivo contiene solo una parte de los datos de configuración pertenecientes a un área funcional determinada 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 de componentes, configuraciones del compilador, etc. Por lo tanto, estos archivos 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:

Si no utiliza 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 establecer su entorno exactamente de la misma manera que lo define en los archivos de configuración.
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 en los archivos de configuración debe almacenarse en los archivos 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.