version control - usados - ¿Qué poner bajo control de versiones?

¿cuáles son los tipos de sistema control de versiones? (8)

¡Todo lo que se puede generar automáticamente desde los archivos de configuración fuente + no debe estar bajo el control de versión! Solo causa problemas y limitaciones (como la que mencionó, usando 2 archivos de proyecto diferentes por diferentes programadores).

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

Casi cualquier IDE crea una gran cantidad de archivos que no tienen nada que ver con la aplicación que se está desarrollando, el IDE los genera y los conserva para que sepa cómo construir la aplicación, donde se encuentra el repositorio de control de versiones, etc.

¿Deben mantenerse esos archivos bajo el control de versiones junto con los archivos que realmente tienen algo que ver con la aplicación (código fuente, archivos de configuración de la aplicación, ...)?

Las cosas son: en algunos IDE si creas un nuevo proyecto y luego lo importas al repositorio de control de versiones usando el cliente / comandos de control de versiones incrustados en el IDE, entonces todos esos archivos se envían al respetable. Y no estoy seguro de que sea correcto: ¿qué es lo que dos desarrolladores diferentes que trabajan en el mismo proyecto quieren usar dos IDE diferentes?

Quiero mantener esta pregunta sin tener en cuenta las referencias a cualquier IDE, lenguaje de programación o sistema de control de versiones en particular. Entonces esta pregunta no es exactamente la misma que estas:

SVN y binarios - pero esto habla de binarios y SVN
¿Mantienes tus herramientas de construcción en el control de versiones? - pero esto se refiere a las herramientas de compilación (por ejemplo, poner el jdk bajo el control de versión)
¿Qué archivos de proyecto no deberían registrarse en SVN , pero esto habla de SVN y dll''s?
¿Mantienes tus archivos de proyecto bajo control de versión? - Muy similar (no lo he encontrado antes), gracias VonC.

Aquí es donde la automatización de compilación y los archivos de compilación entran.

Por ejemplo, aún puede compilar el proyecto (los dos desarrolladores necesitarán obviamente el mismo software de compilación) pero luego podrían usar dos IDE diferentes.

En cuanto a la ''basura'' que se genera, tiendo a ignorar la mayoría si es así. Sé que se supone que es un lenguaje agnóstico, pero considere Visual Studio. Genera archivos de usuario (configuraciones de usuario, etc.) que no deberían estar bajo control de código fuente.

Por otro lado, los archivos de proyecto (utilizados por el proceso de compilación) seguramente deberían. Debo agregar que si usted está en un equipo y todos están de acuerdo con un IDE, el registro de los archivos específicos del IDE está bien siempre que sean globales y no específicos del usuario y / o que no sean necesarios.

Esas otras preguntas explican qué se debe y no se debe incluir en el control de fuente, por lo que no las repetiré.

Creo que es mejor poner cualquier cosa bajo el control de versión que ayude a los desarrolladores a comenzar rápidamente, ignorando cualquier cosa que pueda ser generada automáticamente por un IDE o herramientas de compilación (por ejemplo, el plugin de eclipse de Maven genera .project y .classpath; no es necesario revisarlos ). Evite especialmente los archivos que cambian a menudo, que no contienen nada más que las preferencias del usuario, o que entran en conflicto entre los IDE (por ejemplo, otro IDE que usa .project como eclipse).

Para los usuarios de eclipse, me resulta especialmente útil agregar el estilo de código (.settings / org.eclipse.jdt.core.prefs - el formato automático al guardar está activado) para obtener un código con formato consistente.

En mi opinión depende del proyecto y del entorno. En un entorno empresarial en el que todos utilizan el mismo IDE, puede tener sentido agregar los archivos IDE al repositorio. Si bien esto depende un poco del IDE, ya que algunos incluyen rutas absolutas hacia las cosas.

Para un proyecto que se desarrolla en diferentes entornos, no tiene sentido y será difícil a largo plazo, ya que los desarrolladores no mantienen los archivos del proyecto y hacen que sea más difícil encontrar cosas "relevantes".

En mi opinión, todo lo necesario para compilar el proyecto (código, crear archivos, medios, bases de datos con la información requerida del programa, etc.) debe estar en los repositorios. Me doy cuenta de que, especialmente para los archivos de medios / bases de datos, esto es contradictorio, pero para mí, si no puede bifurcar y luego hacer clic en construir, el control de fuente no está haciendo su trabajo. Esto se duplica en los sistemas distribuidos con creación / fusión de sucursales baratas.

¿Algo más? Guárdalo en un 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 ir en él, por ejemplo, el código fuente y así sucesivamente. Sin embargo, el problema con el que se encuentran muchos VCS es cuando intentamos manejar archivos grandes, normalmente binarios, y en ocasiones cosas como archivos de audio y gráficos. Por lo tanto, mi manera personal de hacerlo es poner el código fuente bajo control de versión, junto con gráficos generales de pequeño tamaño, y dejar cualquier binario a otros sistemas de administración. Si es un binario que yo mismo creé usando el sistema de compilación del IDE, entonces definitivamente se puede ignorar, porque se va a regenerar cada compilación. Para las bibliotecas de dependencia, bueno, aquí es donde entran los administradores de paquetes de dependencia.

En cuanto a los archivos generados por IDE (supongo que estos no se generaron durante el proceso de compilación, como los archivos de soluciones para Visual Studio), bueno, creo que dependería de si trabajas solo o no. Si está trabajando solo, entonces adelante y agréguelos, le permitirán revertir la configuración en la solución o lo que sea que haga. Lo mismo ocurre con otros archivos que no son soluciones, como también. Sin embargo, si está colaborando, mi recomendación es que no, la mayoría de los archivos generados por IDE suelen ser, bueno, específicos del usuario, es decir, que funcionan en su máquina, pero no necesariamente en otros. Por lo tanto, puede ser mejor que no incluya los archivos generados por IDE en ese caso.

tl; dr debe poner la mayoría de las cosas relacionadas con su programa en el control de versiones, excluyendo las dependencias (las bibliotecas, los gráficos y el audio deben ser manejados por algún otro sistema de administración de dependencias). En cuanto a las cosas generadas directamente por el IDE, bueno, dependería de si trabajas solo o con otras personas.

Reglas de juego:

Incluya todo lo que influye en el resultado de la compilación (opciones del compilador, codificaciones de archivos, configuraciones ASCII / binarias, etc.)
Incluya todo para que sea posible abrir el proyecto desde un proceso de pago limpio y poder compilar / ejecutar / probar / depurar / desplegarlo sin ninguna intervención manual adicional.
No incluya archivos que contengan rutas absolutas
Evite incluir preferencias personales (tamaño de pestaña, colores, posiciones de ventana)

Siga las reglas en este orden.

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

Mis razones:

Versionar el código generado parece ser una pérdida de tiempo. Se genera ¿verdad? ¡Puedo recuperarlo con solo presionar un botón!

De Verdad?

Si tuviera que morder la bala y generar la misma versión exacta de una versión anterior sin fallar, ¿cuánto esfuerzo supondría? Al generar el código, no solo debe corregir todos los archivos de entrada, sino que también debe retroceder el tiempo para el generador de código. ¿Puedes hacer eso? ¿Siempre? ¿Tan fácil como sería revisar una determinada versión del código generado si lo hubiera puesto bajo el control de versiones?

E incluso si pudieras, ¿podrías estar seguro de que no te perdiste algo?

Entonces, por un lado, poner el código generado bajo el control de versiones tiene sentido, ya que hace que sea muy fácil hacer lo que significa VCS: retroceder en el tiempo.

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 archivos 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 deberías preocuparte. Si no lo hace, avíseme 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 solo genera un lío aleatorio de bytes cada vez que se ejecuta (bueno, a menos que no te importe la calidad). Los generadores de código deben ser estables y deterministic . Los ejecuta dos veces con la misma entrada y la salida debe ser idéntica hasta el bit menos significativo.

Entonces, si no puede ingresar 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. Ordena el código cuando tengas que hacerlo. Utilice mapas hash que conservan el orden. Haz todo lo necesario para que la salida no sea aleatoria. Al igual que lo hace en cualquier otro lugar en su código.

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

Tampoco verifico en archivos JAR. Como tengo el control total sobre toda la compilación y la plena confianza de que puedo recuperar cualquier versión de las fuentes en un minuto, más sé que tengo todo lo necesario para compilarlo sin ninguna intervención manual adicional , ¿por qué necesitaría los ejecutables para ? Nuevamente, podría tener sentido colocarlos en un repositorio de lanzamiento especial, pero luego, es mejor que guarde una copia de los últimos tres años en el servidor web de su compañía para descargar. Piensa: comparar binarios es difícil y no te dice mucho.

Todo lo que sería devastador si se perdiera, debería estar bajo el control de versiones.