git – múltiples tareas JIRA, múltiples twigs, mismo file

Tengo tres tareas jira, que en realidad es una que se dividió en tres (paso 1,2,3 para crear un perfil de usuario) (no subtareas). Entonces me orderaron crear twigs para cada tarea jira. Mi problema es que para la segunda twig necesito mis códigos de la primera twig, y ​​la tercera twig necesita mis códigos de la primera y la segunda twig.

Ejemplo:

Rama 1 – controller.php creado
Branch 2 – controller.php modificado
Branch 3 – controller.php modificado
(nótese que no agregué nuevas líneas en la twig 2 y 3, sino que también cambié algunas existentes)

Para que esto funcione, lo que hice fue ramificarme de la anterior siempre para poder get mis cambios. Así que la twig 2 se bifurcó desde la twig 1 y la twig 3 se ramificó desde la twig 2.

¿Debería haber creado una sola twig? ¿O cuál sería la mejor manera para que haga esto con git?

Los pros y los contras:

  • La ventaja de tener una sucursal para cada set de cambios es que puede mantener los cambios separados el uno del otro.
  • La desventaja de tener una twig para cada set de cambios es que debe mantenerlos separados el uno del otro.

Permítanme explicarlo: si necesita mantener estos cambios separados y modulares para que pueda aplicar solo los cambios necesarios para cada tarea de JIRA a otra cosa en el futuro, o puede necesitar eliminar solo los cambios relacionados con una tarea de JIRA determinada, entonces bifurcar cada uno de ellos es realmente bueno porque tendrás un set de compromisos agrupados visualmente y, al usar una herramienta visual de git, será fácil ver lo que está sucediendo. También puede volver a establecer una base de reference en una serie de estos cambios mucho más fácil, en lugar de hacer selects random de una sola twig para get exactamente los cambios que necesita.

La desventaja de separar cada twig es que eventualmente tendrá que fusionar las 3 juntas, y dependiendo de cuánto estén cambiando las mismas líneas de código y cuáles son las interdependencies, es muy posible que ambos tengan conflictos entre ellos que tendrán para que se resuelvan en el momento de la fusión (en lugar de desarrollar los cambios), y también es posible que termine teniendo que hacer los mismos cambios en cada una de las 3 twigs, en lugar de simplemente reutilizar los últimos cambios a medida que avanza a través de las 3 tareas.

Git simplifica las ramificaciones

Pero, seamos claros, Git hace que sea súper fácil de ramificar, y hay muy poca sobrecarga para hacerlo, y la mayoría de las fusiones son bastante indoloras (incluso cuando hay conflictos …). Tener 3 sucursales separadas también significa que puede ejecutar testings y CI / CD en las 3 sucursales en paralelo, según sea necesario, y es muy claro para el equipo si alguien más está involucrado en solo uno o dos de los 3 sets de cambios donde y cómo agregar a su trabajo (digamos un defecto arreglado por otro miembro del equipo, etc.).

Recomendación

Dicho todo esto, con la información dada, no creo que podamos darle una respuesta sobre qué método es mejor en su situación particular. Debe hacer esa llamada usted mismo en function de los factores anteriores y similares que son específicos del producto y el flujo de trabajo de su equipo.

Una recomendación que puedo dar: ser ágil sobre esto. Hágalo de la forma en que su equipo lo dice, luego encuentre un pequeño caso en el que no le tome mucho time reimplementar los cambios, y trate de juntar 2 o 3 tareas, intercaladas en una única twig. Esa experiencia le mostrará los pros y los contras mucho mejor que yo tratando de decidir por usted sin el beneficio de todos los factores locales involucrados. Bono adicional: si resulta ser mejor, tendrá una demostración de producto de trabajo real que puede mostrar a su equipo como testing, o una demostración que puede mostrar y preguntar sus opiniones sobre si probarlo para el siguiente function / sprint / etc. o hacer una demostración más grande de ese método alternativo, etc.

Aquí está mi sugerencia. Queremos simplificar las cosas y, sin embargo, trataremos de satisfacer lo que tu jefe intenta hacerte. Por lo que puedo ver, él / ella solo quiere diferentes twigs para diferentes tareas para que pueda rastrear su trabajo. Mientras sea posible, no creo que crear tres twigs diferentes sea la mejor manera. Lo que puedes hacer es crear subtareas en tu tarea. Usted crea 1 twig en la tarea principal. Luego, en git, asegúrese de que su post de confirmación mencione la subtarea . En tu caso, tendrás tres commits. Digamos que al crear las 3 subtareas en Jira tienes subtask-001, subtask-002, subtask-003. Entonces, en su twig deberá comprometerse:

"subtask-001 created controller.php" - this is one commit "subtask-002 modified controller.php to blah blah" - and another commit "subtask-003 modified controller.php agan.." - another one 

Todos estarán en la única twig que creaste y luego podrás hacer una request de extracción. En jira, esos tres commits aparecerán en CADA subtareas mientras la id de la subtarea coincida con lo que mencionaste en el post de confirmación. Es mucho más simple y todavía puedes seguir las revisiones en Jira.