Sugerencias sobre cómo manejar las twigs en git para historias de usuarios inacabadas

Esto está relacionado con tratar de lidiar con historias de usuario inacabadas. Un ejemplo:

En sprint 1, hay una historia de usuario n. ° 100. Así que creamos una twig de sprint (sprint-1) y luego de esa twig una twig de historia de usuario (us-100). Al final del sprint, la historia del usuario no se completa. El process normal es que las historias de usuario usan requestes de extracción para fusionarse en la twig de sprint y, después de la revisión, la twig de sprint se fusiona en desarrollo (utilizando una request de extracción). Luego, la twig de sprint se elimina. Como us-100 no se completó, no se combinó en sprint-1 y cuando se borra Sprint-1, no estoy seguro de qué está pasando con nosotros-100.

Lo que me gustaría hacer es "mover" la twig us-100 a otro sprint, por ejemplo, a la twig sprint-2. es posible? ¿Cómo? ¿O hay un mejor path?

Simplemente vuelva a establecer la base de su twig en la nueva twig compartida de sprint.

Por ejemplo:

git checkout us-100 git fetch git rebase origin/sprint-2 git push -f origin us-100 

Tenga en count que el uso de -f ( --force ) está reescribiendo el historial de la twig sprint-2 . OMI, esto es lo correcto, pero si hay otros que también están usando esa twig, deberán ajustarse, ya que su versión de sprint-2 ahora será diferente.

Ellos pueden hacer:

 git checkout us-100 git fetch git rebase origin/us-100 

Ahora, la twig sprint-2 se basará en tu nueva twig de sprint y puedes continuar con ella como de costumbre.

Su enfoque está retrasando las fusiones de código y muy posiblemente ocultando problemas hasta el último minuto.

Por ejemplo, supongamos que hace una revisión y decide continuar con una fusión de código. En ese caso, podría haber problemas de fusión que incluso pueden hacer que sea necesaria una refactorización. Además, esta sería la primera vez que ejecutaría testings de regresión en la base de código fusionada.

Existe un riesgo real de dar una falsa printing de progreso al mostrar historias 'terminadas' que de hecho todavía están en progreso.

Por lo less, recomendaría con este enfoque hacer fusiones regulares desde la cabeza a cada twig de código. De esta forma, detectará posibles conflictos de fusión a medida que avance. Sin embargo, eso no mitiga el riesgo de las testings de regresión. Quizás podría tener un trabajo de construcción de continuous integration para cada sucursal que realice una fusión nocturna con la cabeza y ejecute testings de regresión automáticas en su contra.