Sobre la mejora de las prácticas de compromiso

Estaba pensando en formas de mejorar mis prácticas de compromiso.

¿Hay alguna correlación entre el no. de líneas de código fuente y no. de commits?

En un proyecto reciente en el que participé, iba a 30 confirmaciones por 1000 líneas.

Un archivo típico del proyecto tiene estas estadísticas

language: JavaScript
total commits that include this file: 32

total lines: 1408
source lines: 1140
comment lines: 98

no. of function declarations: 28
other declarations: 8

Otro archivo tiene estos ...

Language: Python
total commits that include this file: 17

total lines: 933
source lines: 730
comment lines: 80

classes: 1
methods: 10

También pienso que no. de commits está más relacionado con el no. de características o no. de cambios al código y menos al no. de lineas.

El lema general de la comunidad git es hacer compromisos cortos y comprometerse a menudo.

Entonces, ¿realmente piensa en su estrategia de compromiso antes de comenzar el proyecto? Para el caso, ¿hay algo como la estrategia de compromiso? Si es así, ¿cuál es el tuyo?

Si está utilizando un DVCS, debe comprometerse muy a menudo. Me comprometo cada vez que mi código está en un estado estable, que no está relacionado con líneas de código. Desea un árbol de muchos pequeños compromisos atómicos que facilite ver lo que hizo en cada uno. Si está tratando de rastrear una regresión que encontró al probar, esto hace que sea mucho más fácil hacer una búsqueda binaria y rastrear la confirmación exacta, ya que tendrá menos cambios por confirmación. Solo me comprometo cuando mi código se compila; mi idea de "atómico" es que se compila, pasa las pruebas de unidad de regresión y pasa una prueba de integración rápida. Algunas veces se incluye una prueba unitaria, y otras no.

Cuando presiona, debe presionar funciones completas. El resto del mundo no quiere ver su "comprobación perdida en este archivo" se compromete todos los días. Git proporciona rebase, que le permite limpiar su árbol de confirmación al aplastar varias confirmaciones juntas. La comunidad parece estar insegura sobre la cantidad de historia que debe comprometer. Diría que deberías juntar los commits que no muestran nada del historial, como "archivo perdido" o "regresión tonta". Desea presentar un historial tan limpio como sea posible para que todos puedan ver fácilmente lo que hizo.

En un sistema de control de versiones centralizado, debe comprometerse mucho más si desea mantener un buen historial. Mi recomendación es que trabaje en funciones más pequeñas y las complete tanto como pueda antes de comprometerse. Su concepto de "atómico" aquí debería ser una característica que funcione y se pruebe. No desea comprometer nada que rompa los espacios de trabajo de otros desarrolladores, ya que se actualizarán con frecuencia y es mucho más difícil trabajar en características independientes que se superponen. Te comprometerás menos, pero esas confirmaciones generalmente serán más carnosas que tu DVCS promedio.

Puede ver que la proporción de líneas de código a la cantidad de confirmaciones depende de cuán grandes sean sus características y del flujo de trabajo que utilice. Su flujo de trabajo será diferente según el sistema de control de versiones que utilice, por lo que generalmente no puede predecir cómo se verán sus confirmaciones. Cada institución tiene su propio estándar y debe determinar por sí misma cuál debería ser su flujo de trabajo idealmente.

He tenido confirmaciones para corregir errores que cambiaron un personaje . El tamaño no es realmente el factor determinante aquí. Una buena regla general es comprometerse siempre que pueda pensar en un mensaje de confirmación que tenga sentido. Cuándo compartir tus commits es una pregunta diferente. Varía según la cultura de su grupo, pero generalmente implica que tiene una confianza razonable de que sus cambios funcionan según lo previsto.

No creo que el número de confirmaciones deba estar relacionado con el número de líneas. Más probabilidades de problemas resueltos / características introducidas. Utilizo este enfoque bastante simple (git):

• Comprometerse a menudo con la sucursal local, pero solo cuando algo relevante cambia (problema resuelto, se agregaron algunos archivos / funciones importantes). De esta manera, puede navegar fácilmente entre los pasos que lo llevaron a la solución final de lo que estaba trabajando en un momento dado.
• Combine los commits locales en un commit relacionado con una característica / problema al enviarlos al repositorio remoto / público. De esta manera, todo lo que hiciste que se hace público, está bien descrito y es coherente, para que todos sepan lo que estabas haciendo (o al menos tengan una breve idea).

En general, lo que sea que hagas localmente es para ti: sigue el enfoque que funcione para ti. Los compromisos públicos deberían pensarse más, pero no desarrollaría una estrategia completamente nueva si el equipo ya tiene un enfoque de trabajo. Mantente consistente con los demás.

Para la posteridad, confirme todos los archivos relacionados con un error / característica en una revisión. Esto lo ayudará inmensamente más adelante cuando necesite saber qué archivos se tocaron para corregir un error.

Será más fácil regresar y ver lo que hizo para ver 5 archivos registrados bajo el error # 783, en lugar de tratar de rastrear 5 confirmaciones (una para cada archivo). Esto puede aliviarse si tiene una mejor integración de control de fuente / flujo de trabajo que coincida con un registro a un elemento de trabajo / error / característica / retraso. Todavía se compromete con frecuencia, pero coloca los archivos / características relacionados en el mismo check-in cada vez.

Si tiene su CI configurado para "compilar cada confirmación", eso lo ayudará a hacer esto.