Las mejores prácticas para IntelliJ IDEA 9 Control + Maven + Versión

Question

El proyecto es el uso de Maven para que los archivos de POM son las principales fuentes de información del proyecto. Hay algunos ajustes útiles en los archivos de proyecto que estaría bien para mantener.

IDEA otoh parece crear demasiados cambios redundantes en la estructura de archivo de proyecto que contamina la historia SVN y, a veces crea conflictos.

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

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

1. El registro de todos los archivos de IDEA, * .iml y .idea directorios. Contienen información valiosa y es una pérdida de tiempo para volver a crear cada vez que se actualice.
2. Crear rama privada para todos los desarrolladores
3. cd en el directorio .idea
4. SVN cambiar a su contraparte rama privada
5. No comprobar en los archivos idea de confirmaciones regulares - contaminan la historia. Compruebe en el commit especiales.

De esta manera, se mantiene el contenido de .idea directorio en el control de versiones, pero mantenerlo fuera del camino de confirmaciones regulares. Cualquier desarrollador puede tener acceso a los directorios de IDEA de nadie más.

Actualización 2: Dado que esta cuestión fue escrito, he cambiado mi práctica a no en la comprobación de los archivos IntelliJ en el control de versiones, según lo aconsejado por muchos respondedores. Este es mi práctica actual, tanto para Maven y Gradle. Las herramientas se han desarrollado hasta el punto de que la información crítica siempre se puede reproducir desde el .POM original o archivos .gradle. Cuando los archivos cambian, el IDE seguimiento de los cambios fiabilidad, de manera que no pierda sus archivos IDE que a menudo lo que no hay necesidad de comprobar en.

Actualización 3: 7 años después de hacer esta pregunta parece ser todavía relevante. Las mismas se aplican a las mejores prácticas, así Gradle (probablemente SBT, también.): No marque los archivos IDE en, volver a crearlos como sea necesario desde el POM básica, archivos .gradle o SBT

Answer 1

Respuesta corta: no poner estos archivos en el repositorio de control de código fuente como se puede "generar" ellos (y esto es aún más cierto si usted no los necesita, si son molestos, si se puede romper otras entorno ).

Yo personalmente uso los siguientes valores para svn:ignore:

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

Answer 2

Una de las mejores cosas de Maven es que existe el apoyo de herramientas para convertir una POM en un proyecto nativa en Eclipse, Idea y Netbeans. Si usted tiene un pom, puede crear un proyecto nativa con bastante rapidez.

Por esa razón, no me echa en .idea o archivos * .iml bajo control de código, más de lo que me gustaría comprobar en talones de RMI o archivos de clase.

Answer 3

Creo que se debería poner .idea directorio en el control de versiones. La mayor parte de la configuración de contenido no debe ser de la versión sobre orugas, por ejemplo, configuraciones de compilador.

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

IntelliJ IDEA pone realmente workspace.xml en la lista por defecto ignorar, así que si usa Idea para el registro, que debe ser fijado todo sin cambiar nada.

Answer 4

veo que la respuesta estándar es "No comprobar en el archivo de proyecto, sólo el .pom". Pero cosas como los archivos .ipr contienen gran cantidad de funciones muy útiles que no pueden derivarse a partir del archivo .pom. ¿Qué pasa si los usuarios compañero de IntelliJ quieren compartir esos valores? Yo sé que los archivos .ipr están diseñados para ser versionado (ver este hilo por ejemplo). Me gustaría tener una respuesta real, pero todavía no he encontrado una buena práctica en esta materia.

Answer 5

Mi opinión es que debemos mantener ningún tipo IDE archivos específicos de control de versiones. La idea es que debemos mantener la mayor cantidad posible de información en el IDE de forma independiente como archivos pom Maven y así sucesivamente. Todos los ajustes críticos del proyecto pueden mantenerse allí. Y tener todos los ajustes del proyecto importantes guardados en el archivo POM no veo ninguna razón seria para comprobar no sólo en la configuración del proyecto IDEA, pero cualquier otra configuración específica del IDE. Además, la configuración del proyecto .idea estilo carpeta realmente contamina los registros de cambios. Y todavía queremos mantener la configuración del proyecto IDEA en el control de versiones, por lo menos podemos almacenarlos en formato de archivo .ipr sola.

Answer 6

llego tarde a la fiesta, pero esta cuestión exacta me ha estado plagando. Y yo estaba inspirado con lo que creo que podría funcionar, al menos con nuestro sistema de control de código fuente.

Los archivos de IntelliJ no tienen que ser almacenados "en conjunto" con el pom.xml autorizada y la fuente. La historia de control de versiones no está "contaminado" si los cambios relacionados con los de origen no se graban en un lugar diferente en el árbol de origen.

Así que voy a tratar de mover los archivos IntelliJ a un lugar paralelo en el sistema de control de versiones, utilice una correlación de archivo / directorio sencilla para la reunificación de los archivos de origen y de proyectos en ordenador de desarrollo, y monitorear los cambios en el sistema de control de versiones que son puramente de archivos que afectan a la construcción.