¿Cuáles son las buenas estrategias de control de control de fuente para tareas grandes?

La regla general es mantener los registros pequeños y los registros frecuentes. Pero a veces la tarea requiere grandes cambios en el marco subyacente. Luego, al registrarse antes de completar la tarea, se interrumpirá el proyecto hasta que se registre el trabajo terminado.

Entonces, ¿qué estrategias utilizan las personas para reducir el riesgo de perder el trabajo, o decidir que algo que estás haciendo es el enfoque incorrecto, luego cambiar de opinión después de eliminar el código y probar otro enfoque?

Cuando pueda, haré el check-in a la mitad del trabajo comentado, o si se compila y nada está usando archivos nuevos, los revisaré. Cuanto mayor sea el cambio, más probabilidades tengo de ramificar el proyecto y luego volver a fusionarlo. cuando tengo todo funcionando de nuevo. Otra opción si el sistema de control de origen lo permite son los conjuntos de estantes, que son básicamente ramas pequeñas. Entonces, cuando termine el día o llegue a un punto de decisión, archivaré mis cambios, y luego, si sucede algo catastrófico, o quiero volver a ese punto, puedo hacerlo.

Yo uso git, así que mi respuesta es "rama". Bifurca y comete una comida a medida que completas las diversas partes.

Empuje sus confirmaciones en sentido ascendente a medida que esté contento, para que sus colegas puedan revisar los cambios sin interrumpir la troncal.

Cuando todos estén contentos con el código, ¡únete y listo!

(Lo que tiendo a hacer para ramas relativamente largas es fusionar periódicamente el tronco (maestro, en terminología git) en mi rama, para que las dos ramas no diverjan demasiado radicalmente).

Creo que la respuesta variará según el tipo de sistema de control de versiones que esté utilizando: centralizado (por ejemplo, subversión) o distribuido (por ejemplo, git). No tengo ninguna experiencia en el mundo real con el uso de un sistema de control de fuente distribuido, por lo que mi respuesta se basa en lo que hacemos con la subversión.

Si hay un gran cambio en progreso que romperá la construcción de nuestro tronco durante un período de tiempo, o eso realmente interrumpirá al resto del equipo de alguna otra manera, entonces crearemos una rama. Sin embargo, diría que debe hacer todo lo posible para evitar tener que hacer eso; la mayoría de los cambios pueden sentarse junto al resto del código con poco esfuerzo. Por ejemplo, podría activar rutas de código en el nuevo código (con instrucciones if simples o podría inyectar las nuevas versiones basadas en la configuración de configuración si está utilizando un marco DI). Luego, cuando haya terminado, simplemente cambie la configuración a la nueva versión, pruebe todo, elimine el código no utilizado, pruebe nuevamente y finalmente elimine la configuración. No siempre puede hacer eso, pero debido a la sobrecarga de mantener una sucursal, creo que siempre debe verificar si eso es posible.

Si haces una rama, creo que el error que a menudo veo que la gente comete es no mantener su rama actualizada con el tronco. Debe fusionar constantemente los cambios del tronco a la rama mientras exista, de modo que cuando haya terminado la fusión inversa de todo de nuevo sea bastante trivial.

En nuestro equipo usamos subversión, y normalmente cometemos pequeños cambios directamente en el tronco. Para tareas más grandes, el desarrollador que trabaja en él generalmente crea una rama privada, que se fusiona en el tronco una vez que se hace. Luego se elimina la rama privada. Naturalmente, mientras exista la rama privada, su propietario debe verificarla a menudo.

Tratamos de evitar tener ramas de larga duración y fusiones de tronco a rama, porque eso requiere una contabilidad cuidadosa. En cambio, tenemos ramas de vida relativamente corta que solo se fusionan con el tronco una vez y se eliminan poco después.

Y tenemos una regla de que nada se puede comprometer o fusionar con el tronco hasta que al menos otra persona revise los cambios y los apruebe.

Al igual que el comentario habitual de la gente del servidor SQL "depende"

Si puede, le sugiero que cree una rama en el código para que pueda continuar aplicando pequeños registros de su trabajo. Una vez completado, realice una fusión en el tronco principal.

Sí, hay alguna posibilidad de que se duplique el esfuerzo al hacer esto. pero al menos mantendrás un rastro de trabajo que puedes revertir, resulta ser un callejón sin salida.