jbrain - Mejores prácticas para IntelliJ IDEA 9+Maven+control de la versión

intellij idea para linux

Question

El proyecto utiliza Maven para que los archivos POM sean las principales fuentes de información del proyecto. Hay algunos ajustes útiles en los archivos del proyecto que sería bueno mantener.

OTOH IDEA parece crear demasiados cambios redundantes en la estructura del archivo de proyecto que contamina el historial SVN y, a veces crea conflictos.

¿Debo mantener el directorio .idea y los archivos * .iml bajo control de versión? ¿en su totalidad? ¿en parte?

Actualización: Entonces, la mejor práctica que he encontrado trabajando para mí y para mi equipo es hasta ahora:

1. Verifique en todos los archivos IDEA, directorios * .iml y .idea. Contienen información valiosa y es una pérdida de tiempo volver a crearla cada vez que actualice.
2. Crear una sucursal privada para cada desarrollador
3. cd en el directorio .idea
4. svn cambiarlo a su contraparte de rama privada
5. No verifique los archivos de IDEA en confirmaciones regulares: contaminan la historia. Verifíquelos en compromisos especiales.

De esta manera, mantienes el contenido del directorio .idea en el control de versiones pero lo mantienes fuera del camino de las confirmaciones regulares. Cualquier desarrollador puede tener acceso a los directorios de IDEA de otra persona.

Actualización 2: desde que se escribió esta pregunta, he cambiado mi práctica para no registrar ningún archivo IntelliJ en el control de la versión, como aconsejaron muchos respondedores. Esta es mi práctica actual tanto para Maven como para Gradle. Las herramientas se han desarrollado hasta el punto de que la información crítica siempre se puede reproducir a partir de los archivos .POM o .gradle originales. Cuando los archivos cambian, el IDE realiza un seguimiento de los cambios de manera confiable para que no pierda sus archivos IDE a menudo, por lo que no es necesario registrarlos.

Actualización 3: 7 años después de hacer esta pregunta, parece ser relevante. Las mismas mejores prácticas también se aplican a Gradle (probablemente SBT): no revise los archivos IDE, recíclelos según sea necesario desde los archivos básicos POM, .gradle o SBT.

Answer 1

Creo que deberías poner el directorio .idea en control de versiones. La mayor parte de la configuración que contiene debe tener seguimiento de versión, por ejemplo, las configuraciones del compilador.

El único archivo que no pertenece al control de versión es .idea / workspace.xml, ya que solo contiene la configuración particular de su entorno local.

IntelliJ Idea realmente pone workspace.xml en la lista de ignorar por defecto, por lo que si usa Idea para registrar, debe estar todo listo sin cambiar nada.

Answer 2

Llego tarde a esta fiesta, pero este problema exacto me ha estado atormentando. Y me inspiré con lo que creo que podría funcionar, al menos con nuestro sistema de control de fuente.

Los archivos IntelliJ no tienen que almacenarse "juntos" con el autoritario pom.xml y la fuente. El historial de control de versiones no está "contaminado" si esos cambios no relacionados con la fuente se registran en un lugar diferente en el árbol de fuentes.

Intentaré mover los archivos IntelliJ a un lugar paralelo en el sistema de control de versiones, usaré un mapeo sencillo de archivos / directorios para reunir los archivos de origen y proyecto en la máquina del desarrollador y supervisaré los cambios en el sistema de control de versiones que son puramente archivos que afectan La construcción.

Answer 3

Mi opinión es que deberíamos mantener cualquier archivo IDE específico fuera del Control de versiones. La idea es que debemos mantener la mayor cantidad de información posible en forma independiente de IDE, como los archivos Maven pom, y así sucesivamente. Todos los ajustes críticos del proyecto pueden mantenerse allí. Y teniendo todas las configuraciones principales del proyecto guardadas en el archivo pom, no veo ninguna razón seria para registrar no solo la configuración del proyecto IDEA, sino también cualquier otra configuración IDE específica. Además, la configuración del proyecto de estilo de carpeta .idea realmente contamina los registros del conjunto de cambios. Y aún queremos mantener la configuración del proyecto IDEA en control de versiones, al menos podemos almacenarlas en formato de archivo .ipr.

Answer 4

Respuesta corta: no coloque estos archivos en el repositorio de control de origen ya que puede "generarlos" (y esto es aún más cierto si no los necesita, si son molestos, si pueden romper el entorno de los demás).

Yo personalmente uso los siguientes valores para svn:ignore :

target 
*~ 
*.log 
.classpath 
.project 
*.ipr 
*.iws 
*.iml 
.settings 

Answer 5

Una de las mejores cosas de Maven es que existe el soporte de herramientas para convertir un POM en un proyecto nativo en Eclipse, Idea y Netbeans. Si tienes un pom, puedes crear un proyecto nativo bastante rápido.

Por ese motivo, no verificaría los archivos .idea o * .iml bajo el control de código fuente más de lo que verificaría en los resguardos de RMI o en los archivos de clase.

Answer 6

Veo que la respuesta estándar es "no verificar en el archivo del proyecto, solo el .pom". Pero cosas como los archivos .ipr contienen muchas configuraciones útiles que NO se pueden derivar del archivo .pom. ¿Qué sucede si otros usuarios de IntelliJ desean compartir esa configuración? Sé que los archivos .ipr están diseñados para ser versionados (ver este hilo, por ejemplo). Desearía tener una respuesta real, pero aún no he encontrado una buena práctica en este asunto.