update - ¿Cómo lidiar con los archivos de proyectos de IntelliJ IDEA bajo el control de fuente de Git cambiando constantemente?

intellij idea github repository (6)

De DOC oficial: devnet.jetbrains.com/docs/DOC-1186

Según el formato del proyecto IntelliJ IDEA (archivo .ipr o directorio basado en .idea), debe colocar los siguientes archivos de proyecto IntelliJ IDEA bajo el control de la versión:
Formato basado en archivo .ipr
Comparta el archivo .ipr del proyecto y todos los archivos del módulo .iml, no comparta el archivo .iws ya que almacena la configuración específica del usuario.
Formato basado en el directorio .idea
Comparta todos los archivos en el directorio .idea en la raíz del proyecto, excepto los archivos workspace.xml y tasks.xml que almacenan las configuraciones específicas del usuario, también comparten todos los archivos del módulo .iml.

Lo puse en mi .gitignore:

#Project workspace.xml tasks.xml

Todos en nuestro equipo usan IntelliJ IDEA, y nos resulta útil poner sus archivos de proyecto (.ipr y .iml) en control de fuente para que podamos compartir configuraciones de compilación, configuraciones e inspecciones. Además, podemos usar esos ajustes de inspección en nuestro servidor de integración continua con TeamCity. (Tenemos el archivo .iws del espacio de trabajo por usuario en el archivo .gitignore y no en el control de fuente).

Sin embargo, esos archivos cambian de pequeñas maneras cuando hace casi cualquier cosa en IDEA. Existe un problema en la base de datos de problemas de IDEA-64312 ( IDEA-64312 ), por lo que quizás uno considere que esto es un error en IDEA, pero es uno con el que tendremos que vivir en el futuro previsible.

Hasta hace poco, estábamos usando Subversion, pero recientemente cambiamos a Git. Nos acabábamos de acostumbrar a tener una lista de cambios de los archivos del proyecto que ignoramos y no registramos a menos que hubiera cambios en los archivos del proyecto que queríamos compartir con los demás. Pero con Git, el poder real parece ser (de lo que estamos explorando) la ramificación continua que fomenta, y cambiar de rama es una molestia ya que los archivos del proyecto siempre han sido modificados. A menudo, puede fusionarse en los cambios de alguna manera e intenta lidiar con los cambios en el archivo de proyecto que se están aplicando a la nueva rama. Sin embargo, si la nueva sucursal ha cambiado los archivos del proyecto (como la sucursal está trabajando en un nuevo módulo que todavía no está en las otras ramas), git simplemente arroja un error que no tiene sentido fusionarse en los archivos cuando tanto la rama tiene cambios como usted tienen cambios a nivel local, y puedo entender mejor su punto. Desde la línea de comando, se puede usar "-f" en el comando "git checkout" para forzarlo a descartar los cambios locales y usar la rama en su lugar, pero (1) el comando GUI de Git Checkout en IDEA (10.5.1) no parece tener eso como una opción que podemos encontrar, por lo que tendríamos que cambiar a la línea de comandos de forma regular, y (2) no estamos seguros de que queremos tener el hábito de usar ese bandera y decirle a Git que descarte nuestros cambios locales.

Entonces, aquí hay algunas ideas que tenemos sobre las opciones que tenemos para tratar con esto:

Saque por completo los archivos del proyecto del control de la fuente. Póngalos en .gitignore y distribúyalos a cada persona y TeamCity por otros medios, tal vez poniéndolos en control de la fuente en otro lugar o bajo otros nombres. Nuestro equipo es lo suficientemente pequeño como para tener en cuenta esta opción, pero no parece genial.
Continúa viviendo con él, tratando de asegurarte de administrar qué archivos tenemos en qué ramas en un momento dado. Como parte de esto, podemos alentar a cada desarrollador a tener más de una copia de cada proyecto en su sistema, de modo que cada uno de ellos pueda verificar en una rama diferente con conjuntos posiblemente diferentes de archivos de proyecto.
Intente tener solo el proyecto (.ipr) en control de fuente, con los archivos del módulo (.iml) no en control de fuente y en el archivo .gitignore. Lo principal que parece cambiar por sí solo en el .ipr de forma regular es el orden de las configuraciones de compilación compartida, pero tal vez solo podamos compartir la información por separado sobre cómo configurarlas. No estoy muy seguro de cómo IDEA se ocupa de este tipo de cosas de solo tener algunos de sus archivos, especialmente en un nuevo pago.

Supongo que espero que haya alguna solución obvia (o no obvia) que hayamos olvidado, tal vez lidiando con la enorme personalización que parecen tener Git e IDEA. Pero parece que no podríamos ser el único equipo que tenga este problema. Las preguntas que son similares en StackOverflow incluyen 3495191 , 1000512 y 3873872 , pero no sé, ya que son exactamente el mismo problema, y tal vez alguien puede llegar a los pros y los contras de los diversos enfoques que he delineado , enfoques enumerados en las respuestas a esas preguntas o enfoques que recomiendan.

Gracias.

Nuestro equipo no verifica los archivos IntelliJ específicos de la ruta. Suponemos que las personas saben cómo usar el IDE y configurar un proyecto. Los archivos IntelliJ van a la lista de cambios "ignorados".

ACTUALIZAR:

La respuesta es más fácil ahora que estoy usando Maven y su estructura de directorio predeterminada.

Debería pedirse a IntelliJ que ignore todos los archivos en las carpetas /.svn , /.idea y /target . Todo lo que pertenece a la información de ruta de un individuo se almacena en /.idea .

Todo lo demás es un juego justo para estar comprometido con Subversion o Git.

Puede usar la estructura de proyectos basada en directorios de IDEA, donde la configuración se almacena en el directorio .idea en lugar del archivo .ipr. Da un control más detallado sobre lo que está almacenado en el control de la versión. Los archivos .iml seguirán existiendo, por lo que no resuelve los cambios aleatorios en ellos (¿quizás los mantenga fuera del control de la fuente?), Pero compartir cosas como el estilo del código y los perfiles de inspección es fácil, ya que cada uno de ellos será en su propio archivo en el directorio .idea.

Saqué workspace.xml del control de fuente (+ agregado a .gitignore).

Solo para compartir otro enfoque que mi equipo haya utilizado: simplemente mueva los archivos relacionados con IDE a una ubicación diferente donde IntelliJ no reconoce, y cree una secuencia de comandos para copiarlos en la ubicación ''activa'' deseada que GIT ignora.

El beneficio de este enfoque es que mantuvo la opción de compartir configuraciones IDE a través del control de versiones. El único inconveniente es que debe decidir cuándo ejecutar el script (probablemente una vez por clon de espacio de trabajo o cuando se desean cambios), y puede automatizarlo incorporando el script en su proceso de compilación o en el enlace posterior a la fusión.

Este enfoque se basa en que IntelliJ busca únicamente ubicaciones particulares para sus archivos de configuración, por lo que también se aplica a los archivos de configuración de la estructura. De hecho, ignoramos el archivo .properties de Grails de la misma manera, por lo que los desarrolladores no verifican accidentalmente sus cambios de configuración local.

Una respuesta oficial está disponible . Suponiendo que está utilizando el formato de proyecto de carpeta moderno (y ahora predeterminado) .idea :

Agrega todo ...
Excepto .idea/workspaces.xml (que es específico del usuario)
Excepto .idea/tasks.xml (que es específico del usuario)
Excepto algunos otros archivos que pueden contener contraseñas / claves / etc. (ver el enlace de arriba para más detalles)

Este ejemplo de archivo .gitignore puede ser una referencia útil, aunque debe leer el enlace anterior para comprender por qué aparecen estas entradas y decidir si las necesita.

Personalmente, también ignoro el archivo .idea/find.xml ya que esto parece cambiar cada vez que realiza una operación de búsqueda.