Mejores prácticas para IntelliJ IDEA 9 + Maven + Control de versión

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.Mejores prácticas para IntelliJ IDEA 9 + Maven + Control de versión

OTOH IDEA parece crear demasiados cambios redundantes en la estructura del archivo de proyecto que contamina el historial de 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: Así que la mejor práctica he encontrado trabajando para mí y mi equipo es hasta ahora:

Comprobar en todos los archivos de IDEA, * .iml y .idea directorios. Contienen información valiosa y es una pérdida de tiempo volver a crearla cada vez que actualice.
Crear rama privada para todos los desarrolladores
cd al directorio .idea cambiar
SVN a su contraparte rama privada
No marque en archivos idea de confirmaciones regulares - contaminan la historia. Verifíquelos en compromisos especiales.

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

Actualización 2: Dado que esta cuestión fue escrito, he cambiado mi práctica a no comprobar en cualquier archivo de IntelliJ en el control de versiones, según lo aconsejado por 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 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 aun 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.

Fuente

2009-10-31 Sasha O

Gracias a todos por sus sugerencias. Mientras tanto, mi mejor práctica es verificar los archivos de IDEA, pero como un conjunto de cambios por separado para que no estropee tanto la historia de SVN. Por lo general les doy a estos changesets el nombre "locura IDEA" :-) –

ver http://stackoverflow.com/questions/3041154/intellij-idea-9-10-what-folders-to-check-into-or-not- check-in-source-contro -> Preguntas frecuentes sobre IDEA: http://devnet.jetbrains.com/docs/DOC-1186 –

@MatthewCornell ¿Tal vez actualice su comentario para responder? –

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 otros ambiente).

Yo personalmente uso los siguientes valores para svn:ignore:

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

Fuente

2009-10-31 20:09:16

Esta respuesta ignora el valor de tener archivos iml justo después de la salida/actualización. He visto una gran cantidad de tiempo desperdiciado por los desarrolladores, que tuvieron que descubrir, que necesitan regenerar imls después de la actualización. Ponerlos en el CV es realmente amable con los demás. Seguir ciegamente la regla general de "no cometer cosas generadas" solo hace daño aquí. –

A menos que esté lejos de la base aquí, muchas de las configuraciones en el directorio .idea no pueden simplemente regenerarse. Estamos hablando de cómo un proyecto se divide en módulos, qué módulos tienen qué facetas adjuntas, qué artefactos deben generarse, qué es el proceso de compilación, etc. Esta es información clave. Ahora, si puede generar toda esta información desde otros archivos, entonces considere ir por esa ruta, pero para la pregunta aquí, no estoy viendo eso. –

Eso no es válido para grandes proyectos que involucran a muchas personas. En nuestro caso, por ejemplo, también almacenamos allí las inspecciones que realiza la idea y el estilo del formato del código. – Mikel

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 tienes un pom, puedes crear un proyecto nativo bastante rápido.

Por esa razón, no controlaría los archivos .idea o * .iml bajo el control de código fuente más de lo que verificaría en los talones de RMI o en los archivos de clase.

Fuente

2009-11-01 02:37:14 sal

+1 por mencionar los beneficios cuando se usan IDEs múltiples en un equipo –

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 this thread por ejemplo). Desearía tener una respuesta real, pero aún no he encontrado una buena práctica en este asunto.

Fuente

2009-12-07 02:08:19 mcherm

Estoy usando el diseño de directorio .idea que se supone que es más compatible con VC.Todavía hay muchos cambios cada vez que contaminan el historial de VC si no tienes cuidado. Una posibilidad que quiero probar es poner .idea bajo svn: ignorar pero revisarlo manualmente bajo demanda de vez en cuando. Lo mismo ocurre con los archivos .classpath y .project Eclipse. –

Esto parece ser más una pregunta que una respuesta. Creo que esto pertenece como un comentario a otra respuesta. (Lo siento, sé que decir esto me hace un poco como la "Policía procesal de Stack Overflow" pero el sistema funciona muy bien si la gente usa el sistema correctamente. Así que elige la respuesta que crees que es incorrecta y vota las que te gusten. Creo que Alexei obtuvo esta pregunta más correctamente que los demás, así que lo voté a él y a los demás.) –

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, p. configuraciones del compilador

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

IntelliJ Idea en realidad 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.

Fuente

2009-12-13 18:27:12

Este fue el motivo de la pregunta original: .idea es lo que uso (sin workspace.xml por supuesto) y genera cambios todo el tiempo. Estos cambian la historia del desorden y me hacen lidiar con ellos demasiado. ¿Cómo puedo reducir estos cambios? –

Utilicé este enfoque durante unos días y no noté ningún cambio no deseado en esa área. ¿Tiene ejemplos de lo que llama cambios redundantes que contaminan el historial SVN, que se encuentran en el directorio .idea pero fuera de workspace.xml? –

Alexei, aquí hay un ejemplo de verificación redundante. No se hicieron cambios al proyecto. http://ow.ly/d/1g7 –

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.

Fuente

2010-01-18 11:57:52

Si un objetivo es ayudar a un equipo de desarrollo a usar una configuración de IDE compartida, poner la mayoría de los archivos .idea en el control de código fuente es una gran idea. Veo que alexi.vidmich entiende esto en su respuesta. –

Puedo estar parcialmente de acuerdo con esto, pero solo es correcto para la configuración que no involucra ningún detalle del sistema subyacente, como rutas absolutas, entornos de tiempo de ejecución, etc. –

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.

Así que intentaré mover los archivos IntelliJ a un lugar paralelo en el sistema de control de versiones, usar un simple mapeo de archivos/directorios para reunificar los archivos fuente y proyecto en la máquina del desarrollador y monitorear los cambios en el sistema de control de versiones que son puramente a los archivos que afectan la construcción.

Fuente

2012-07-13 04:50:56 baliset

¿Cómo te va? – Shanimal

Mejores prácticas para IntelliJ IDEA 9 + Maven + Control de versión

Respuesta

Cuestiones relacionadas