No cuesta casi nada usar el historial de confirmación mantenido por el sistema de control de versiones. Sin embargo, durante un esfuerzo importante de refactorización (o reorganización / limpieza) de un proyecto, se moverán funciones y clases e incluso espacios de nombres; a veces se fusionarán varios archivos y se dividirán otros archivos. Estos cambios a menudo conducen a la pérdida del historial de confirmación original de algunos archivos.
En mi opinión personal, mantener la organización del proyecto es más importante que mantener el historial del código fuente. La buena organización del proyecto permite que se agreguen continuamente nuevas funciones con un esfuerzo razonable, mientras que el valor del historial del código fuente parece ser dudoso.
Además, con el uso de pruebas unitarias, los problemas de regresión se identifican rápidamente. Mientras la última versión continúe satisfaciendo todos los requisitos de software, ¿realmente necesitamos preservar el historial del código fuente?
Entiendo que cualquier código fuente enviado debe conservarse debido a la necesidad de brindar soporte a los clientes sin requerirles que realicen una actualización importante de la versión. Pero aparte de esto, ¿hay algún valor en mantener el historial de confirmaciones del código fuente?
¿El historial de confirmación del código fuente juega algún papel en las comunicaciones entre los miembros del equipo? ¿Qué pasa si abolimos el historial de confirmación, pero en su lugar nos basamos en el "código fuente" + "código de prueba de la unidad" para la comunicación?
¿La existencia de un historial de compromiso hace que uno se sienta complacido con la documentación a largo plazo de información importante sobre el proyecto, como los principales cambios de diseño / requisitos y las corrientes de pensamiento que impulsaron esos cambios?
fuente
These changes often lead to the loss of the original commit history of a few files.Eche un vistazo, por ejemplo, a "culpar a git": no se pierde nada. A veces puede ser un poco más difícil de encontrar, pero siempre está ahí.Respuestas:
Para utilizar el historial de confirmaciones para más de "comentarios realizados" o comentarios de tipo "error corregido", debe estar vinculado con su sistema de seguimiento de problemas. Cada cambio, cada confirmación, debe tener algún problema asociado para que sepa qué cambió, por quién y por qué.
El software suficientemente complejo rara vez tiene todos los requisitos implementados y todos los errores corregidos por una multitud de razones, por lo que creo que su afirmación aquí es, digamos, optimista.
Supongamos que está en la versión 7.8 de su programa. Pero está apoyando, en el campo, 12 versiones activas diferentes, como 1.6, 2.2, 2.8, etc. Cada uno de estos no se actualizará a la última versión por una variedad de razones, por lo que está apoyando a todos con correcciones de errores. Un cliente encuentra un error en su última versión 7.8. Lo arreglas en 7.8. ¿Cómo sabes cuántos de los otros lanzamientos deben corregirse? Sin el historial de fuentes y el seguimiento de problemas, no lo hace.
fuente
He tenido ingenieros que se remontan varios años al código fuente buscando respuestas a por qué algo es así. A veces, la forma en que las cosas han evolucionado con el tiempo es importante para comprender un error, pero no es algo en lo que generalmente se piensa al documentar cosas (ni siquiera necesariamente documentable).
Además, puede haber muy buenas razones legales para mantener el historial del código fuente. La mayor parte del buceo en el contenedor de código fuente que he tenido que hacer (como ingeniero de construcción / SCM) ha sido a pedido del departamento legal de mi empresa.
fuente
Sí a los dos. Puede ser útil saber cuándo se cambió algo, quién lo hizo y por qué. Si pierde su historial, su capacidad para hacerlo se ve afectada.
Si lo hace El enfoque de "código fuente" + "código de prueba de unidad" solo no le dice quién / cuándo / por qué.
Supongo que se podría decir que sí. Pero pocos desarrolladores documentan a fondo los cambios en los requisitos / diseño. Y ciertamente, casi nadie registra la corriente de pensamiento que impulsó el desarrollo inicial o las modificaciones posteriores. Tener el historial de confirmación (y especialmente los mensajes de registro de confirmación) y los enlaces cruzados con el sistema de seguimiento de problemas / fallas al menos le brindan algo de dónde ir. Y eso es mejor que nada, o un conjunto de instantáneas de lanzamiento.
fuente