¿Debo mantener los archivos de mi proyecto bajo control de versiones? [cerrado]

¿Debo mantener archivos de proyecto como .project, .classpath, .settings de Eclipse, bajo control de versiones (por ejemplo, Subversion, GitHub, CVS, Mercurial, etc.)?

Desea mantener en control de versiones cualquier archivo de configuración portátil , es
decir:
cualquier archivo que no tenga una ruta absoluta.
Eso incluye:

• .proyecto,
• .classpath ( si no se utiliza una ruta absoluta , lo cual es posible con el uso de variables IDE o variables de entorno de usuario)
• Configuración del IDE (que es donde no estoy de acuerdo con la respuesta 'aceptada'). Esas configuraciones a menudo incluyen reglas de análisis de código estático que son de vital importancia para hacer cumplir consistentemente para cualquier usuario que cargue este proyecto en su espacio de trabajo.
• Las recomendaciones de configuración específicas de IDE deben escribirse en un archivo README grande (y también, por supuesto, versionado).

Regla de oro para mí:
debe poder cargar un proyecto en un espacio de trabajo y tener todo lo que necesita para configurarlo correctamente en su IDE y comenzar en minutos.
No hay documentación adicional, páginas wiki para leer o lo que no.
Cárgalo, configúralo, listo.

Archivos .project y .classpath sí. Sin embargo, no mantenemos nuestra configuración IDE en control de versiones. Hay algunos complementos que no hacen un buen trabajo al conservar la configuración y descubrimos que algunas configuraciones no eran muy portátiles de una máquina de desarrollo a la siguiente. Entonces, en cambio, tenemos una página Wiki que destaca los pasos necesarios para que un desarrollador configure su IDE.

Estos son los que considero archivos generados y, como tales, nunca los pongo bajo control de versiones. Pueden ser diferentes de una máquina a otra y de un desarrollador a otro, por ejemplo, cuando las personas tienen diferentes complementos de Eclipse instalados.

En su lugar, utilizo una herramienta de compilación (Maven) que puede generar versiones iniciales de estos archivos cuando realiza una nueva compra.

Estoy dividido entre dos opciones aquí.

Por un lado, creo que todos deberían tener la libertad de utilizar el conjunto de herramientas de desarrollo con las que son más productivos, siempre que todos los artefactos de origen estén almacenados en el control de versiones y el script de compilación (por ejemplo, ANT o Maven) garantice el cumplimiento de los estándares por parte de especificar exactamente qué JDK usar, qué versiones de qué bibliotecas de terceros depender, ejecutar verificaciones de estilo (por ejemplo, estilo de verificación) y ejecutar pruebas unitarias, etc.

Por otro lado, creo que muchas personas usan las mismas herramientas (por ejemplo, Eclipse) y, a menudo, es mucho mejor tener algunas cosas estandarizadas en el momento del diseño en lugar del tiempo de compilación; por ejemplo, Checkstyle es mucho más útil como un complemento de Eclipse que como una tarea ANT o Maven, que es mejor estandarizar en el conjunto de herramientas de desarrollo y un conjunto común de complementos.

Trabajé en un proyecto en el que todos usaban exactamente el mismo JDK, la misma versión de Maven, la misma versión de Eclipse, el mismo conjunto de complementos de Eclipse y los mismos archivos de configuración (por ejemplo, perfiles de Checkstyle, reglas de formateador de código, etc.). Todos estos se mantuvieron en el control de fuente: .project, .classpath y todo en la carpeta .settings. Hizo la vida realmente fácil durante las fases iniciales del proyecto, cuando la gente estaba ajustando continuamente las dependencias o el proceso de construcción. También ayudó enormemente a la hora de agregar nuevos principiantes al proyecto.

En general, creo que si no hay demasiadas posibilidades de una guerra religiosa, debería estandarizar el conjunto básico de herramientas de desarrollo y complementos y garantizar el cumplimiento de la versión en sus scripts de compilación (por ejemplo, especificando explícitamente la versión de Java). No crea que es muy beneficioso almacenar el JDK y la instalación de Eclipse en el control de código fuente. Todo lo demás que no sea un artefacto derivado, incluidos los archivos de su proyecto, la configuración y las preferencias de complementos (en particular, el formateador de código y las reglas de estilo) debe pasar al control de código fuente.

PD Si usa Maven, hay un argumento para decir que los archivos .project y .classpath son artefactos derivados. Esto solo es cierto si los genera cada vez que hace una compilación, y si nunca ha tenido que modificarlos a mano (o cambiarlos inadvertidamente cambiando algunas preferencias) después de generarlos desde el POM

No, porque solo controlo las versiones de los archivos necesarios para crear el software. Además, los desarrolladores individuales pueden tener su propia configuración específica del proyecto.

No, soy un gran usuario de Maven y uso el complemento Q para Eclipse que crea y mantiene .project y .classpath actualizados. Para otras cosas, como la configuración de complementos, normalmente mantengo un archivo README o una página Wiki sobre eso.

También aquellos con los que he trabajado que prefieren otros IDE solo usan los complementos de Maven para generar los archivos necesarios para mantener felices a su IDE (y a ellos mismos).

Todo esto es una opinión, supongo, pero las mejores prácticas a lo largo de los años indican que los archivos específicos de un IDE determinado no deben almacenarse en el control de fuente, a menos que toda su organización esté estandarizada en un IDE y nunca tenga la intención de cambiar.

De cualquier manera, definitivamente no desea que se almacene la configuración del usuario, y .project puede contener configuraciones que son realmente específicas del desarrollador.

Recomiendo usar algo como Maven o Ant como sistema de compilación estandarizado. Cualquier desarrollador puede configurar una ruta de clase en su IDE en unos segundos.

Sí, excepto por la carpeta .settings. Confirmar los otros archivos nos funciona bien. Hay una pregunta similar aquí .

Aunque generalmente estoy de acuerdo con el enfoque de "no versión de archivos generados", tenemos problemas con él y tenemos que volver a cambiar.

Nota: También estoy interesado en la respuesta de VonC , particularmente sobre el punto de "poner en marcha Eclipse en minutos". Pero no es decisivo para nosotros.

Nuestro contexto es Eclipse + Maven, usando el complemento m2eclipse. Tenemos un entorno de desarrollo común, con directorios comunes tanto como sea posible. Pero a veces sucede que alguien probaba un complemento, o cambiaba pequeñas cosas en la configuración, o importaba un segundo espacio de trabajo para una rama diferente ...

Nuestro problema es que la generación de .project se realiza al importar un proyecto en Eclipse, pero no se actualiza en todos los casos posteriormente . Es triste, y probablemente no permanente, ya que el complemento m2eclipse mejorará, pero es cierto en este momento. Entonces terminamos teniendo diferentes configuraciones. Lo que tuvimos hoy fue eso: se agregaron varias naturalezas a muchos proyectos en alguna máquina, que luego se comportaron de manera muy diferente :-(

La única solución que vemos es la versión del archivo .project (para evitar riesgos, haremos lo mismo para .classpath y .settings). De esa manera, cuando un desarrollador cambia su pom, los archivos locales se actualizan usando m2eclipse, todos se comprometen juntos y otros desarrolladores verán todos los cambios.

Nota: en nuestro caso, usamos nombres de archivos relativos, por lo que no tenemos ningún problema para compartir esos archivos.

Entonces, para responder a su pregunta, digo que sí, confirme esos archivos.

También me gustó:

• Respuesta del vendedor rico

Parece que estos archivos de proyecto pueden cambiar con el tiempo a medida que trabaja en un proyecto, así que sí, los coloco bajo el control de versiones.

Si. Todo menos generar resultados.

Usamos IntelliJ IDEA y mantenemos las versiones '.sample' de los archivos del proyecto (.ipr) y del módulo (.iml) bajo control de versiones.

Algo más importante aquí es compartir y reutilizar que el control de versiones, en mi humilde opinión. Pero si vas a compartir estas configuraciones, qué mejor lugar para ponerlas que el repositorio, junto a todo lo demás.

Algunas ventajas de los archivos de proyecto compartidos y versionados:

• Puede consultar cualquier etiqueta / rama y comenzar a trabajar en ella rápidamente
• Hace que sea más fácil para un nuevo desarrollador configurar primero el entorno de desarrollo y ponerse al día
• Esto se adhiere mejor a DRY, que siempre es profundamente satisfactorio. Antes de esto, todos los desarrolladores tenían que configurar estas cosas de vez en cuando, esencialmente haciendo un trabajo repetido. Por supuesto, todos tenían sus propias pequeñas formas de evitar repetirse, pero mirando al equipo como un todo, hubo mucho esfuerzo duplicado.

Tenga en cuenta que en IDEA estos archivos contienen configuraciones tales como: cuáles son los directorios "fuente" y "fuente de prueba"; todo sobre las dependencias externas (dónde se encuentran los archivos jar de la biblioteca, así como las fuentes relacionadas o javadocs); opciones de compilación, etc. Esto es algo que no varía de un desarrollador a otro (no estoy de acuerdo con esto ). IDEA almacena configuraciones IDE más personales en otros lugares, así como cualquier configuración de complementos. (No conozco a Eclipse tan bien; esto puede o no ser muy diferente).

Estoy de acuerdo con esta respuesta que dice:

Debe poder cargar un proyecto en un espacio de trabajo y tener todo lo que necesita para configurarlo correctamente en su IDE y comenzar en minutos. [...] Cárgalo, configúralo, listo.

Y lo tenemos así, gracias a archivos de proyecto versionados.