¿Qué poner bajo control de versión?

Casi cualquier IDE crea muchos files que no tienen nada que ver con la aplicación que se está desarrollando, son generados y mantenidos por el IDE para que sepa cómo crear la aplicación, dónde está el depósito de control de versiones, etc.

¿Deberían esos files mantenerse bajo control de versión junto con los files que realmente tienen algo que ver con la aplicación (código fuente, files de configuration de la aplicación, …)?

Las cosas son: en algunos IDE si crea un nuevo proyecto y luego lo importa en el repository de control de versiones utilizando el cliente / commands de control de versiones integrados en el IDE, todos esos files se envían al respitory. Y no estoy seguro de que sea correcto: ¿qué dos desarrolladores diferentes que trabajan en el mismo proyecto quieren usar dos IDEs diferentes?


Quiero que esta pregunta sea independiente de las references a un IDE en particular, un lenguaje de progtwigción o un sistema de control de versiones. Entonces esta pregunta no es exactamente la misma que estas:

  • SVN y binarys , pero esto habla de binarys y SVN
  • ¿Mantiene sus herramientas de compilation en control de versiones? – pero esto habla sobre las herramientas de compilation (por ejemplo, poner el jdk bajo control de versión)
  • ¿Qué files de proyecto no deberían registrarse en SVN ? Pero esto habla de SVN y dll
  • ¿Mantiene sus files de proyecto bajo control de versión? – Muy similar (no lo he encontrado antes), gracias VonC

Reglas de juego:

  1. Incluye todo lo que influye en el resultado de compilation (opciones de compilation, codificaciones de files, configuration ASCII / binaria, etc.)
  2. Incluya todo para que sea posible abrir el proyecto desde un process de finalización de session limpio y poder comstackr / ejecutar / probar / depurar / implementar sin ninguna otra intervención manual
  3. No incluya files que contengan routes absolutas
  4. Evite include preferences personales (tamaño de pestaña, colors, posiciones de window)

Sigue las reglas en este order.

[Actualización] Siempre está la pregunta de qué debería pasar con el código generado. Como regla general, siempre los pongo bajo control de versiones. Como siempre, tome esta regla con un grano de sal.

Mis razones:

El código generado por el control de versiones parece una pérdida de time. Se genera ¿verdad? ¡Puedo recuperarlo presionando un button!

De Verdad?

Si tuviera que morder la bala y generar la misma versión exacta de alguna versión anterior sin falta, ¿cuánto esfuerzo sería? Al generar código, no solo tiene que get todos los files de input correctos, sino que también debe volver el time atrás para el generador de código. ¿Puedes hacer eso? ¿Siempre? ¿Tan fácil como sería verificar una cierta versión del código generado si lo pusiera bajo control de versión?

E incluso si pudiera, ¿alguna vez podría estar seguro de que no se perdió algo?

Por lo tanto, por un lado, poner código generado bajo control de versiones tiene sentido, ya que hace que sea más fácil hacer lo que VCS significa: retroceder en el time.

También hace que sea fácil ver las diferencias. Los generadores de código también tienen errores. Si soluciono un error y tengo 150'000 files generados, me ayuda mucho cuando puedo compararlos con la versión anterior para ver que a) el error desapareció yb) nada más cambió inesperadamente. Es la parte inesperada de la que debes preocuparte. Si no lo hace, hágamelo saber y me aseguraré de que nunca trabaje para mi empresa 🙂

El principal punto de dolor de los generadores de código es la estabilidad. No funciona cuando el generador de código simplemente escupe un desorder aleatorio de bytes cada vez que se ejecuta (bueno, a less que no le importe la calidad). Los generadores de código deben ser estables y deterministas . Los ejecuta dos veces con la misma input y la salida debe ser idéntica a un bit less significativo.

Entonces, si no puede verificar el código generado porque cada ejecución del generador crea diferencias que no existen, entonces su generador de código tiene un error. Arreglalo. Ordene el código cuando sea necesario. Usa maps hash que conservan el order. Haga todo lo necesario para que la salida no sea aleatoria. Al igual que lo haces en cualquier otro lugar en tu código.

El código generado que podría no poner bajo control de versión sería documentation. La documentation es algo así como un objective suave. No importa tanto cuando regenero la versión incorrecta de los documentos (por ejemplo, tiene más o less errores tipocharts). Pero para las versiones, podría hacer eso de todos modos para poder ver las diferencias entre lanzamientos. Puede ser útil, por ejemplo, para asegurarse de que las notas de la versión estén completas.

Tampoco reviso los files JAR. Como tengo el control total sobre la versión completa y la confianza total de que puedo recuperar cualquier versión de las fonts en un minuto y sé que tengo todo lo necesario para comstackrlo sin ninguna otra intervención manual , ¿por qué necesitaría los ejecutables para ? Una vez más, podría tener sentido includelos en un repository de publicación especial, pero luego, mejor mantener una copy de los últimos tres años en el server web de su compañía para download. Piensa: Comparar binarys es difícil y no te dice mucho.

Creo que es mejor poner cualquier cosa bajo control de versiones que ayude a los desarrolladores a comenzar rápidamente, ignorando todo lo que pueda generar automáticamente un IDE o herramientas de compilation (por ejemplo, el plugin de eclips de Maven genera .project y .classpath; no es necesario verificarlos en ) Especialmente evite los files que cambian a menudo, que no contienen nada más que las preferences del usuario, o que el conflicto entre IDEs (por ejemplo, otro IDE que utiliza .project como eclipse lo hace).

Para los usuarios de eclipse, me resulta especialmente útil agregar estilo de código (.settings / org.eclipse.jdt.core.prefs – formateado automático al save activado) para get un código con formatting constante.

Aquí es donde entran en juego los files de compilation y automation .

Por ejemplo, aún puedes build el proyecto (los dos desarrolladores necesitarán obviamente el mismo software de compilation) pero a su vez podrían usar dos IDE diferentes.

En cuanto a la 'basura' que se genera, tiendo a ignorar a la mayoría si lo hace. Sé que esto pretende ser independiente del lenguaje, pero considere Visual Studio. Genera files de usuario (configuration de usuario, etc.) esto no debería estar bajo control de fuente.

Por otro lado, los files de proyecto (utilizados por el process de compilation) deberían serlo. Debo agregar que si está en un equipo y todos han acordado un IDE, entonces el control de los files IDE específicos está bien siempre que sean globales y no sean específicos del usuario y / o no sean necesarios.

Esas otras preguntas hacen un buen trabajo al explicar lo que se debe o no controlar en el control de la fuente, así que no las repetiré.

¡Todo lo que se puede generar automáticamente a partir de los files de configuration fuente + no debe estar bajo el control de la versión! Solo causa problemas y limitaciones (como el que usted indicó, utilizando 2 files de proyecto diferentes por diferentes progtwigdores).

Es cierto no solo para IDE "files basura" sino también para files intermedios (como .pyc en python, .o en c, etc.).

En mi opinión, depende del proyecto y el entorno. En un entorno de empresa donde todo el mundo utiliza el mismo IDE, puede tener sentido agregar los files IDE al repository. Si bien esto depende un poco del IDE, ya que algunos incluyen paths absolutos a las cosas.

Para un proyecto que se desarrolla en diferentes entornos, no tiene sentido y será doloroso a la larga ya que los files del proyecto no son mantenidos por todos los desarrolladores y hacen que sea más difícil encontrar cosas "relevantes".

Cualquier cosa que sería devastadora si se perdiera, debería estar bajo control de versión.

En mi opinión, todo lo que se necesita para build el proyecto (código, crear files, medios, bases de datos con la información del progtwig requerida, etc.) debe estar en repositorys. Me doy count de que, especialmente para los files de medios / bases de datos, esto es fantástico, pero para mí, si no puedes realizar una bifurcación y luego golpear build, el control fuente no está haciendo su trabajo. Esto se duplica para sistemas distribuidos con creación / fusión de sucursales baratas.

¿Algo más? Guárdelo en otro lugar diferente. Los desarrolladores deben elegir su propio entorno de trabajo tanto como sea posible.

Por lo que he estado viendo con el control de versiones, parece que la mayoría de las cosas deberían includese, por ejemplo, el código fuente, etc. Sin embargo, el problema al que se enfrentan muchos VCS es cuando intentan manejar files grandes, generalmente binarys, y en ocasiones cosas como files de audio y charts. Por lo tanto, mi forma personal de hacerlo es poner el código fuente bajo control de versión, junto con charts generales de pequeño tamaño, y dejar los binarys a otros sistemas de administración. Si se trata de un file binary que creé utilizando el sistema de compilation del IDE, entonces definitivamente se puede ignorar, porque se va a regenerar en cada compilation. Para las bibliotecas de dependencia, bueno, aquí es donde entran en juego los administradores de packages de dependencies.

En cuanto a los files generados por IDE (supongo que estos no se generan durante el process de compilation, como los files de solución para Visual Studio), bueno, creo que dependerá de si está trabajando solo o no. Si trabaja solo, continúe y añádalo: le permitirán revertir la configuration en la solución o lo que sea que haga. Lo mismo ocurre con otros files que no son de solución también. Sin embargo, si está queueborando, entonces mi recomendación es no – la mayoría de los files generados por IDE tienden a ser, bueno, específicos del usuario – también funcionan en su máquina, pero no necesariamente en otros. Por lo tanto, es mejor que no incluya files generados por IDE en ese caso.

Debería poner la mayoría de las cosas relacionadas con su progtwig en el control de versiones, excluyendo las dependencies (cosas como bibliotecas, charts y audio deberían ser manejados por algún otro sistema de administración de dependencies). En cuanto a las cosas generadas directamente por el IDE, bueno, dependerá de si está trabajando solo o con otras personas.