¿Debo mantener mis archivos de proyecto bajo control de versión?

Question

¿Debo mantener los archivos del proyecto como el proyecto .clickse, .classpath, .settings de Eclipse, bajo el control de la versión (por ejemplo, Subversion, GitHub, CVS, Mercurial, etc.)?

Answer 1

Usted quiere mantener el control versión los archivos portátiles de ajuste,
significado:
Cualquier archivo que no tiene ruta absoluta en él.
que incluye:

• .project,
• .classpath (si no hay ruta absoluta utiliza, que es posible con el uso de variables IDE, o variables de entorno de usuario)
• configuración IDE (que es donde discrepo fuertemente 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 sistemáticamente para cualquier usuario que cargue este proyecto en su espacio de trabajo.
• Las recomendaciones de configuraciones específicas de IDE deben escribirse en un gran archivo README (y también versiones, por supuesto).

La regla de oro para mí:
Usted debe ser capaz de cargar un proyecto en un espacio de trabajo y tienen en ella todo lo necesario para configurar correctamente en el IDE y ponerse en marcha en cuestión de minutos.
Sin documentación adicional, páginas wiki para leer o no.
Cargalo, configúralo, listo.

Answer 2

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

Answer 3

Sí, excepto la carpeta .settings. Cometer los otros archivos funciona bien para nosotros. Hay una pregunta similar here.

Answer 4

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 de configuración persistente y encontramos que algunas configuraciones no eran muy portátiles de una máquina de desarrollo a la siguiente. Entonces, tenemos una página Wiki que destaca los pasos necesarios para que un desarrollador configure su IDE.

Answer 5

Esto es lo que considero que son archivos generados, y como tal nunca los coloco 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 instalados diferentes plugins de Eclipse.

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

Answer 6

No, soy un usuario pesado Maven y uso el complemento Q for Eclipse que crea y mantiene actualizado .project y .classpath. Para otras cosas, como la configuración de los complementos, generalmente mantengo un README o Wiki-page sobre eso.

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

Answer 7

No, porque solo los archivos de control de versiones que se necesitan para compilar el software. Además, los desarrolladores individuales pueden tener su propia configuración específica del proyecto.

Answer 8

Esto es toda la opinión, pero las mejores prácticas a lo largo de los años indican que los archivos específicos de un IDE determinado no deberían almacenarse en control de fuente, a menos que toda su organización esté estandarizada en un IDE y nunca tenga ninguna intención en el cambio

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

Recomiendo usar algo como Maven o Ant como un sistema de compilación estandarizado. Cualquier desarrollador puede obtener una classpath configurada en su IDE en unos segundos.

Answer 9

Estoy dividido entre dos opciones aquí. Por un lado, creo que todos deberían tener la libertad de usar el conjunto de herramientas desarrolladas con las que son más productivos, siempre y cuando todos los artefactos de origen estén almacenados en el control de versiones y el script de construcción (por ejemplo, ANT o Maven). asegura el cumplimiento de estándares especificando exactamente qué JDK usar, de qué versiones dependen las bibliotecas de terceros, ejecutando verificaciones de estilo (por ejemplo, checkstyle) y pruebas de unidades en ejecución, etc.

Por otro lado, creo que mucha gente usa las mismas herramientas (por ejemplo, Eclipse) y, a menudo, es mejor tener algunas cosas estandarizadas en tiempo de diseño en lugar de tiempo de compilación (por ejemplo, Checkstyle es mucho más útil como plugin de Eclipse que como 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 donde todos usaban exactamente el mismo JDK, la misma versión de Maven, la misma versión de Eclipse, el mismo conjunto de plugins de Eclipse y los mismos archivos de configuración (por ejemplo, perfiles Checkstyle, reglas de formateador de código, etc.) . Todos estos se mantuvieron en control de fuente - .project, .classpath y todo en la carpeta .settings. Hizo la vida realmente fácil durante las fases iniciales del proyecto cuando las personas continuamente modificaban las dependencias o el proceso de compilación. También ayudó inmensamente cuando se agregaron nuevos iniciadores al proyecto.

En resumen, creo que si no hay demasiadas posibilidades de una guerra religiosa, debe 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 el Java versión). No creo que haya mucho beneficio para almacenar el JDK y la instalación de Eclipse en el control de la fuente. Todo lo demás que no sea un artefacto derivado, incluidos los archivos de tu proyecto, la configuración y las preferencias de los complementos (en particular, el formateador de códigos y las reglas de estilo), debe pasar al control de código fuente.

P.S. Si usa Maven, existe 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 los tuvo que modificar a mano (o los cambió inadvertidamente al cambiar algunas preferencias) después de generarlos desde el POM

Answer 10

Sí. Todo menos producción de compilación.

Answer 11

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

Algo más grande aquí es compartiendo y reutilizando que versionando, en mi humilde opinión. Pero si va a compartir estas configuraciones, ¿qué mejor lugar para colocarlas que el repositorio, justo al lado de todo lo demás?

Algunas ventajas de & archivos de proyecto con versiones compartidas:

• Se puede extraer de cualquier etiqueta/sucursal y comenzar a trabajar en él rápidamente
• hace más fácil para un nuevo desarrollador que estableció por primera vez el entorno de desarrollo y ponerse al día
• Esto se adhiere mejor a DRY, que siempre es muy satisfactorio. Antes de esto, todos los desarrolladores de tenían que configurar estas cosas de vez en cuando, esencialmente haciendo un trabajo repetido. Por supuesto, todos tenían sus propias pequeñas maneras de evitar repetirse, pero mirando al equipo como un todo, había un montón de esfuerzos duplicados.

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 fuentes relacionadas o javadocs); opciones de compilación, etc. Esto es lo que hace que no varíe de desarrollador a desarrollador (no estoy de acuerdo con this con mucha fuerza). IDEA almacena configuraciones de IDE más personales en otros lugares, así como también configuraciones de complementos. (No sé Eclipse que así, lo que puede o no puede ser muy diferente.)

Estoy de acuerdo con this answer que dice:

Usted debe ser capaz de cargar un proyecto en un espacio de trabajo y tiene en él todo lo que necesita para configurarlo correctamente en su IDE y ponerse en marcha en minutos. [...] Cargalo, configúralo, listo.

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

Answer 12

Aunque generalmente estoy de acuerdo con el enfoque de "no generar archivos de versión", tenemos problemas y tenemos que volver.

Nota: También estoy interesado en VonC's answer, particularmente sobre el punto "get Eclipse up within minutes". Pero no es decisivo para nosotros.

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

Nuestro problema es que la generación de .project se hace al importar un proyecto en Eclipse, pero es no actualizado en todos los casos más adelante en. Es triste, y probablemente no permanente, ya que el plug-in m2eclipse mejorará, pero es cierto ahora mismo. Así que terminamos teniendo diferentes configuraciones. Lo que tuvimos hoy fue que: varias naturalezas se añadieron a muchos proyectos en alguna máquina, que luego se comportaron de manera muy diferente :-(

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

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

Por lo tanto, para responder a su pregunta, respondo que sí, confirme esos archivos.

---

También me gustó:

• rico del vendedor answer