Control de versión: Tratar con código incompleto / roto

7

Parece ser una buena práctica generalmente aceptada no incluir un código no válido, roto o incompleto. Pero una de las grandes ventajas de los sistemas de control de versiones es que le proporciona un lugar remoto para su código, por lo que puede trabajar en la misma base de código desde más de un lugar.

Supongamos que está trabajando en una función con un par de otros desarrolladores y se anuncia una tormenta invernal adversa; todos están de acuerdo en ir a casa y seguir trabajando en lugar de quedar atrapados en la tormenta, pero nadie está en el lugar ideal para parar . ¿Qué haces?

  1. Cree diferentes sucursales para cada desarrollador y confirme sus cambios, empuje esas sucursales al control remoto y espere que pueda limpiarlo más adelante en el control remoto sin dificultar la vida.
  2. ¿Crear un remote diferente solo para el código incompleto?
  3. Copie su código en su unidad de memoria flash personal y espere que no lo pierda más tarde, o si lo atrapan violando la política de la empresa.
  4. ¿Algo más?

(Utilizamos git , pero espero que la respuesta sea general para cualquier sistema de control de versiones).

    
pregunta kojiro 28.01.2013 - 16:26

6 respuestas

14

Vaya un paso más allá que simplemente crear una rama para resolver este problema específico y pase a crear una rama para cada característica, corrección de errores, etc. que decida implementar. Se debe esperar que cada una de estas sucursales tenga un código roto en cualquier momento. Una vez que se completa el código, se puede combinar / probar en la rama principal de su repositorio.

Esto le permitirá resolver el problema actual de dónde almacenar el código incompleto y roto y le ayudará a organizar sus ideas e ideas. Si desea probar una nueva característica de locura en su tiempo libre, simplemente cree una rama para esa característica y comience a trabajar en ella. Puede guardarlo durante dos meses en un estado roto y recuperarlo en una fecha posterior mediante la fusión de los cambios que se han realizado en su sucursal principal.

Puede encontrar un buen resumen de una ramificación de esta manera utilizando la integración continua (CI): enlace

    
respondido por el Mike 28.01.2013 - 18:41
7

Si está utilizando un DVCS, es tan simple como "4. Cree un repositorio remoto para cada desarrollador".

Para la mayoría de los CVCSes, realmente tienes que usar sucursales. TFS ofrece estanterías que se pueden usar para este propósito.

    
respondido por el pdr 28.01.2013 - 16:34
4

Aquí es donde brillan las buenas estrategias de bifurcación: nada incompleto debería estar en master , pero no significa que el código de trabajo incompleto y incompleto no pueda llegar al repositorio compartido. Hay muchas buenas razones para hacerlo, como las máquinas de copia de seguridad / conmutación / ubicaciones de conmutación / help & revisa / nos da a los seniors una buena idea de que los juniors están haciendo más que jugar WoW.

    
respondido por el Wyatt Barnett 28.01.2013 - 17:12
2

Las ramas son tu mejor opción. La regla de oro es no romper la construcción. Suponiendo que ese es el tronco principal y se está construyendo correctamente, entonces está bien crear una rama y poner el trabajo temporal allí. Sin embargo, prefiero ver el trabajo incompleto almacenado en el control de versiones que dejarlo en una computadora que se destruye.

    
respondido por el Mark 13.03.2013 - 19:17
1

Si trabaja con CVCS, puede intentar rodar con un solo troncal. He visto esto hecho muy bien algunas veces. Lo que hay que hacer es tener una integración continua con las pruebas unitarias y pruebas contiguas en ese troncal.

Una regla: No rompa la compilación y no rompa la funcionalidad.

Pero, hay algunos checkins 'incompletos' que son aceptables. Por ejemplo, si va a agregar una característica y necesita revisar algunas clases modelo que no se usan en ningún lugar, está bien, solo mencione para qué sirven en los registros de confirmación. Si necesita ampliar una clase existente para tener más funcionalidad, también está bien.

Los registros frecuentes como este tienen 3 beneficios:

1) Todos verán su "dirección" temprano. Ellos podrán coordinarse con usted en su trabajo y usar sus cambios si ven valor en ellos. Un problema con la bifurcación de características es que las personas pueden inventar simultáneamente la misma rueda.

2) Tus cosas serán probadas temprano. Un problema con la bifurcación para todo es que debe haber 2 rondas de pruebas: una para la característica realizada en la bifurcación y otra para la característica después de la fusión.

3) Si las cosas se rompen, otros desarrolladores las atraparán incluso antes de que llegue al control de calidad. Los errores se resuelven mejor lo antes posible.

Una advertencia: esto funcionará en equipos pequeños y medianos. En algún momento, las personas comienzan a pisarse los dedos de los demás demasiado y se verá obligado a bifurcarse.

    
respondido por el MrFox 28.01.2013 - 20:56
0

En el uso normal, no cometería cambios en el control de origen hasta que una característica esté completa y probada. La "tormenta de invierno malo" parece ser una ocurrencia rara, que podría justificar reglas especiales. Si alguien no estuviera en el lugar ideal para detenerse, les pediría que guardaran esos cambios en otra unidad, o tal vez los comprimiran y los enviaran por correo electrónico al líder del equipo. Si ambos están prohibidos por su entorno de trabajo, entonces rompería el uso normal y solo les pediría que enviaran el código incompleto al control de código fuente. Si se rompe algo, entonces es bastante fácil de revertir. Y esto debería ser una ocurrencia rara en lugar de la norma.

    
respondido por el Shane 28.01.2013 - 16:35

Lea otras preguntas en las etiquetas