¿Una revisión grande o varias más pequeñas?

Question

Ayer, cuando revisé la última versión de nuestra herramienta interna, vi más de 30 nuevas versiones. Esto me dio curiosidad ya que pensé que alguien finalmente solucionó esos molestos errores y agregó esa característica que estaba esperando tanto tiempo ... ¿y adivinen qué? Nada de esto sucedió, alguien simplemente pensó que sería bueno actualizar algunos encabezados y hacer un ajuste menor de dos o tres funciones. Todo en un compromiso separado. Estupendo.

Esto generó una discusión en nuestro equipo, ¿debería considerarse correcto o deberíamos prohibir dicho "abuso"? Podría decirse que esto realmente podría caber en uno o dos commits, pero 30 parece mucho. ¿Cómo debe manejarse esto? ¿Cuál es la mejor práctica?

Answer 1

Debe comprometerse en cualquier momento que realice un cambio y esté a punto de pasar al siguiente.

No debe cometer nada que impida la construcción del proyecto.

Debe completar el mensaje de confirmación para que la gente sepa qué cambios se han realizado.

que va a hacer por mí .. No asumo algo se ha hecho menos que lo veo en el mensaje de confirmación ...

Answer 2

no me importa el número de confirmaciones como cada confirmación mantiene consistencia del proyecto (la construcción aún tendrá éxito). Este es un recuento interno que no debería molestarlo. Si quiere cambiar algo aquí, mejor dígale a la gente que use algunos mensajes de confirmación estructurados (como "[corrección de errores] ...", "[función] ...", "[corrección menor]").

Por cierto, si quiere saber si se han solucionado los errores o se han agregado características, usar un sistema de localización de fallos es mucho mejor que comprobar las confirmaciones en una herramienta similar a SVN.

Answer 3

Generalmente, creo que una confirmación debe estar relacionada con una tarea lógica, p. solucionando el error # 103 o agregando una nueva función de impresión. Esto podría ser un archivo o varios, de esa manera puede ver todos los cambios realizados para una tarea en particular. También es más fácil deshacer el cambio si es necesario.

Si cada archivo se marca uno por uno, no es fácil ver los cambios realizados para una actualización/tarea en particular.

Además, si se completan varias tareas en una confirmación, no es fácil ver qué cambios pertenecen a cada tarea.

Answer 4

La batalla contra la entropía del código es un esfuerzo constante del equipo. Los registros menores donde uno solo 'arregla las ventanas rotas' a lo largo de un camino deben ser alentados, no desaprobados. El repositorio fuente es la herramienta incorrecta para realizar un seguimiento de las correcciones de errores, para eso es un rastreador de errores, por lo que la inconveniencia de localizar arreglos al escanear el depósito de código y no el repositorio de errores me parece totalmente despreciable.

Trabajo en un equipo de tamaño moderado en una base de código grande (~ 1M LOC) con un gran historia (~ 20Y). Una gran parte del código es un montón de desorden: lógica de rama podrida, API obsoleta, convenciones de nomenclatura, incluso indentación aleatoria a menudo hace que leer sea un misterio. Inicié un hábito de mejoras de legibilidad menores "drive-by", para tratar de luchar contra la podredumbre total del código, y estoy tratando de conseguir que los compañeros de equipo adopten el mismo hábito.

A menos que sus circunstancias sean radicalmente diferentes, trataría de pensar favorablemente sobre cualquier iniciativa de este tipo. La alternativa (con la que estoy muy familiarizado) es el estancamiento temeroso, que condena a cualquier código a pudrirse.