No estoy de acuerdo con esta regla y estoy de acuerdo con lo que dijo Mason Wheeler . me gustaría
Me gusta añadir algunas ideas.
Intento comprometerme cada vez que tengo un significativo
cambio para confirmar: esto puede ser varias veces al día si soluciono varios errores pequeños,
o una vez a la semana si estoy trabajando en un software más grande que no puede ser
utilizado por el resto del código de manera significativa hasta que alcance un
estado consistente.
También, interpreto a cometer como publicar una revisión significativa que
Aporta nueva funcionalidad a la base de código.
Creo que uno debería tratar de limpiar el código antes de comprometerse para que
Otros desarrolladores pueden entender el significado y el propósito del cambio.
Cuando miran el historial de revisiones. Cuantos menos cambios tengan otros desarrolladores.
ver en la historia, mejor: cuando miro el historial de revisiones quiero
para ver incrementos que agreguen alguna funcionalidad significativa; No me interesa
En cada pequeña idea que cada desarrollador tenía y quería probar antes de
llegó a la solución.
Además, no creo que sea una buena idea usar el servidor SVN
(o cualquier sistema de control de versiones) como una instalación de copia de seguridad a la que
la instantánea actual del código se confirma (siempre que se compile):
puede utilizar una memoria USB o una unidad USB externa o un disco de red
para reflejar su código actual para que no se pierda si su
la computadora se descompone El control de revisión y la copia de seguridad de datos son dos diferentes
cosas. Publicar una revisión no es lo mismo que guardar una instantánea
de tu código.
Finalmente, creo que no debería ser un problema cometer de vez en cuando
y luego (es decir, solo cuando uno está realmente satisfecho con el estado actual de
El código) y evitar conflictos de fusión no es una buena justificación para
cometer (demasiado) a menudo.
Muchos conflictos de combinación ocurren cuando diferentes personas trabajan en los mismos archivos
al mismo tiempo, lo que es una mala práctica (consulte, por ejemplo, este artículo , señale
7).
Los conflictos de fusión deben reducirse dividiendo un proyecto en módulos con
interfaces claras y tan pocas dependencias como sea posible, y coordinando
El trabajo de los desarrolladores para que el código en el que trabajan se solape tan poco.
como sea posible.
Sólo mis 2 centavos.
EDIT
Otra razón contra los compromisos prematuros que vinieron a mi mente es que
Una versión (muy) con errores no puede ser probada. Si estás cometiendo en el maletero.
y su equipo de pruebas está probando todos los días, es posible que no tengan una versión comprobable
Por unas horas (o por un día). Incluso si no intenta solucionar el error y
simplemente revertir los cambios, una reconstrucción puede tardar un par de horas. Con, digamos,
cinco evaluadores que trabajan en tu equipo, has perdido 5 x 2 = 10 horas de
El tiempo del equipo por inactividad. Me pasó una vez, así que realmente lo intento.
para evitar compromisos prematuros en nombre de cometer lo antes posible .