version-control - modules - intellij gitignore template
Se funde en los archivos IntelliJ IDEA.IPR y.IWS (4)
"Conservamos nuestros archivos IntelliJ .IPR e .IWS en nuestro control de fuente, pero IntelliJ los sigue modificando simplemente abriéndolos, incluso sin que se haya realizado ningún trabajo en el proyecto".
El archivo .IWS es definitivamente un archivo por desarrollador, por lo que no debe estar bajo control de fuente.
En cuanto al archivo .IPR en un proyecto reciente, inicialmente intentamos versionar este archivo acercándolo conceptualmente como lo haría con un proyecto .Net y el archivo VS.Net .SLN. Nuestro objetivo era conseguir que un desarrollador se ejecutara en una PC limpia en 15 minutos, incluido el tiempo que lleva instalar un software dependiente como el IDE o una base de datos local. Al final, nos acercamos un tiempo para ajustar la configuración local como se muestra a continuación.
El problema es que el archivo .IPR almacena más configuraciones que un archivo .sln -eg configuraciones para complementos individuales. Entonces, una de las principales causas de sobrescritura es que si un desarrollador con una configuración de complemento diferente abre el archivo IPR, algunas configuraciones predeterminadas para el complemento se escriben en el archivo. Sentimos que los desarrolladores no deberían tener que restringirse a un superconjunto de plugin dado (solo una configuración mínima).
La forma en que alivió el problema (aunque no se resolvió del todo) fue cambiar al formato de carpeta .idea. Esto toma el contenido del archivo .IPR y divide muchos de los nodos en archivos y carpetas individuales en la subcarpeta .idea. Desde aquí, pudimos excluir muchos de los archivos escritos frecuentemente en el control de origen. Algunos de los archivos que excluimos fueron:
- workspace.xml
- dataSources.xml
- sqlDataSources.xml
- dynamic.xml
Algunos archivos que nos gustaría que IntelliJ deje en paz son (aunque la culpa también puede ser para los desarrolladores de complementos y no solo para Jetbrains):
- projectCodeStyle.xml (para que podamos obtener un formato de código coherente en el proyecto; una vez más, esto puede sobrescribirse en función de la combinación de complementos locales de un desarrollador).
- cualquier archivo en la carpeta runConfigurations. Puede llevar mucho tiempo configurar configuraciones de ejecución, especialmente si tiene una aplicación compleja con muchas facetas. La cosa más comúnmente estúpida que se modifica simplemente abriendo el IDE o la construcción es la opción "DEBUG_PORT" en RunnerSettings. Mi opinión es si se asigna de forma dinámica ¿por qué no tener un valor de "Dinámico"?
- misc.xml. Este archivo también contiene configuración de complemento. Algunas configuraciones parecen prácticas para compartir y otras buscan más configuraciones personales. Por ejemplo, el complemento IvyIDEA pone una ruta absoluta a su archivo de configuración ivy.
- Los archivos del módulo. En su mayoría, se los deja solos, pero un ejemplo de sobrescritura innecesaria es el complemento IvyIDEA que incluye detalles de la ubicación del caché ivy local en este archivo. Pero de nuevo, esto es culpa del plugin y no Jetbrains en realidad.
Espero que esto ayude.
Cristiano.
Mantenemos nuestros archivos IntelliJ .IPR e .IWS en nuestro control de fuente, pero IntelliJ los sigue modificando con solo abrirlos, incluso sin realizar ningún trabajo en el proyecto.
¿Qué estamos haciendo mal?
Agregamos una extensión a las que están marcadas en el control de origen (.deleteme). Entonces nuevas personas pueden verificar el proyecto, cambiar las extensiones e ir. Si hacemos cambios de configuración, actualizamos los archivos registrados.
Sin saber exactamente qué está cambiando, es un poco difícil responder con confianza, pero yo diría:
Los archivos IWS contienen información que describe cómo se organiza el IDE de un desarrollador para este proyecto (incluyendo cosas como el historial de cambios recientes, el estado actual de cada ventana del editor, qué ventanas acoplables están visibles y cuáles se han colapsado). Dado que a cada desarrollador se le debe permitir organizar su espacio de trabajo como prefiera, estos no deberían estar en control de fuente.
Los archivos IPR describen la estructura del código del proyecto. Con esto quiero decir cosas como qué módulos son parte del proyecto, qué archivos build.xml usar, dónde encontrar bibliotecas para compilar su código, etc. Esto puede estar en control de fuente, pero Si permite que estas configuraciones varíen de una copia del proyecto del desarrollador a la siguiente, tendrá una experiencia difícil.
Si tiene un componente libraryTable dentro de su archivo de IPR:
Casi con certeza, lo que está sucediendo es que cada desarrollador mantiene bibliotecas compartidas (JAR), necesarias para construir su código, en su máquina local en diferentes lugares; cuando realizan cambios, la ubicación de sus bibliotecas se escribe en el archivo IPR. Si tuviera que hacer esto, cuando actualicé el proyecto, mi copia del IPR y la suya entrarían en conflicto con la ubicación de estos JAR.
Solucionamos este problema ubicando archivos JAR en una ubicación compartida (como una unidad de red mapeada) y luego aseguramos que cada desarrollador descargue estos archivos al mismo lugar (una subcarpeta lib bajo la raíz del proyecto funciona bien). La desventaja es que terminas con copias múltiples del mismo JAR en todos los proyectos (cada proyecto hará referencia a su propia carpeta lib), pero al alza, como cada desarrollador está usando la misma estructura de proyecto, la actualización de IPR debería funcionar mucho mejor.
De otra manera:
Eche un vistazo para ver qué está intentando fusionar IntelliJ (cuando actualice, se le debe dar la opción de combinar manualmente los archivos o ver las diferencias; de lo contrario, use su herramienta diff favorita). Si pudieras actualizar tu pregunta con un poco más de información sobre cómo son tus conflictos de fusión, podría ser más fácil ver de dónde vienen las ruedas.
Una solución es no poner sus proyectos IntelliJ en control de fuente. Esto implica que son fáciles de recrear.
Puede decirle a Subversion sobre los archivos que debe ignorar. Agregue sus archivos IntelliJ a esa lista.
"... incluso sin que se haya realizado ningún trabajo en el proyecto ...", esto sugiere que abra frecuentemente IntelliJ sin hacer ningún trabajo útil en el proyecto. Tal vez ese es el verdadero problema. No veo por qué abriría el IDE sin hacer ALGO que valiera la pena consultar. ¿Y cuál es el costo de un creciente número de revisión? Pequeño, en mi opinión.
Así que ahora he cambiado de opinión. Verifique los archivos del proyecto IntelliJ y no se preocupe por el aumento de los números de revisión. No te están costando mucho.