Todos en nuestro equipo usan IntelliJ IDEA, y nos resulta útil poner sus archivos de proyecto (.ipr y .iml) en el control de origen para que podamos compartir configuraciones, configuraciones e inspecciones de compilación. Además, podemos usar esas configuraciones 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 origen).
Sin embargo, esos archivos cambian en pequeñas formas cuando haces casi cualquier cosa en IDEA. Hay un problema en la base de datos de problemas de IDEA ( IDEA-64312 ), por lo que tal vez uno podría considerar esto 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. Cada uno de nosotros nos habíamos acostumbrado a tener una lista de cambios de archivos de proyectos que ignoramos y no registramos a menos que hubiera cambios en los archivos de proyectos que quisiéramos compartir con otros. Pero con Git, el verdadero poder parece ser (por lo que estamos explorando) la ramificación continua que fomenta, y cambiar entre ramas es una molestia ya que los archivos del proyecto siempre se han modificado. A menudo, puede fusionarse de alguna manera en los cambios e intenta lidiar con los cambios en el archivo del proyecto que ahora se aplican a la nueva rama. Sin embargo, si la nueva rama ha cambiado los archivos del proyecto (como que la rama está trabajando en un nuevo módulo que aún no está en las otras ramas), git solo arroja un error que no No tiene ningún sentido fusionarse en los archivos cuando tanto la rama tiene cambios como usted tiene cambios localmente, y puedo entender 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 Git Checkout GUI en IDEA (10.5.1) no parece tener eso como una opción que podamos encontrar, por lo que tendríamos que cambiar a la línea de comando de forma regular, y (2) No estamos seguros de querer tener el hábito de usar eso bandera y decirle a Git que descarte nuestros cambios locales.
Entonces, aquí hay algunas ideas que tenemos sobre las opciones que tenemos para lidiar con esto:
- Elimine completamente los archivos del proyecto del control de origen. Póngalos en .gitignore y distribúyalos a cada persona y TeamCity por algún otro medio, tal vez poniéndolos en el control de la fuente en otro lugar o bajo otros nombres. Nuestro equipo es lo suficientemente pequeño como para considerar esta opción, pero no parece excelente.
- Continúe viviendo con él, tratando de asegurarse de administrar qué archivos tenemos en qué ramas en un momento dado. Como parte de esto, podríamos alentar a cada desarrollador a que tenga más de una copia de cada proyecto en su sistema, para que puedan verificarse en una rama diferente con posiblemente diferentes conjuntos de archivos de proyecto.
- Intente tener solo el proyecto (.ipr) en el control de origen, con los archivos del módulo (.iml) no en el control de origen 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 compartidas, pero tal vez solo podamos compartir la información por separado sobre cómo configurarlas. Sin embargo, no estoy muy seguro de cómo IDEA se ocupa de este tipo de cosas de tener solo algunos de sus archivos, especialmente en un nuevo pago.
Supongo que espero que haya una solución obvia (o no obvia) que nos hemos perdido, tal vez lidiando con la enorme personalización que Git e IDEA parecen tener. Pero parece que no podríamos ser el único equipo que tiene este problema. Las preguntas que son algo similares en Stack Overflow incluyen 3495191 , 1000512 y 3873872 , pero no sé, ya que son exactamente el mismo problema, y tal vez alguien pueda proponer los pros y los contras de los diversos enfoques que he descritos, los enfoques enumerados en las respuestas a esas preguntas, o los enfoques que recomiendan.