Las twigs de características de Git y las mejoras menores del código

Acabamos de empezar a usar git para nuestro código de producción, y nos encontramos con un pequeño problema en nuestro flujo de trabajo. Necesitamos encontrar la forma de manejar las mejoras generales de código / reparaciones técnicas de deudas que surgen mientras trabajamos en una característica.

El flujo de trabajo que hemos adoptado es usar 'desarrollar' como la twig de integración principal y desarrollar todas las características en las twigs de características fuera de 'desarrollar'. Cuando se completa una característica, el desarrollador crea una request de extracción y todos la revisan para proporcionar comentarios antes de que se fusione de nuevo en su desarrollo. Esto parece estar funcionando muy bien.

El problema que tenemos es que durante el desarrollo de rutina de una característica, el desarrollador puede querer modificar / refactorizar algún código común para mejorar el sistema o eliminar alguna deuda técnica. Este cambio es valioso, pero no está directamente relacionado con la característica en desarrollo.

De acuerdo con nuestro flujo de trabajo, realmente debería hacerse en una twig diferente que pasa por su propia request de extracción y revisión de código antes de entrar en desarrollo. Sin embargo, si los hacemos hacer esto, ¿cómo pueden get el cambio nuevamente en su twig de características mientras esperan que suceda la revisión completa del código y se desarrolle el código para fusionarse?

Las ideas que tenemos son:

1) selecciona los cambios desde la twig 'refactorX' en nuestra twig de características. Continúa desarrollando y deja que git (con suerte) descubra cuándo nos fusionamos para desarrollar que ya tiene el cambio de la twig de refactorización.

2) Combina la twig 'refactorX' en nuestra twig de características y continúa el desarrollo. (Nota: la ramificación desarrollada para 'refactorX' puede haber estado más adelante en la historia del desarrollo, por lo que creemos que esto puede tener problemas)

3) Alguna otra opción más inteligente que aún no conocemos. 🙂

Lo que estamos buscando es una guía de mejores prácticas sobre cómo manejar esta parte del flujo de trabajo. Después de hablar más sobre esto, sabemos que popupá con frecuencia y queremos encontrar una manera fácil y eficiente de manejarlo en nuestro flujo de trabajo.

¿Alguna recomendación?

Parece que está intentando evitar fusionar la twig de desarrollo de nuevo en la twig de características. Es beneficioso evitar este paso, pero a veces es necesario, especialmente en situaciones como esta.

Una técnica que estamos empezando a usar también es git rebase --onto . En lugar de fusionar la twig de desarrollo en la twig de características, la twig de características se puede mover al final de la twig de desarrollo para adquirir las nuevas características.

Cuando está utilizando un repository central, probablemente sea más útil crear un nuevo nombre de twig de característica. Por ejemplo, agregamos -v2 al nuevo nombre de la twig.

El process de movimiento típico podría verse como

 git checkout feature git branch -m feature-v2 git rebase --onto develop develop git push -u origin feature-v2 

Ahora tiene un nuevo código en su twig de características pero no ha fusionado la twig de desarrollo en la twig de características.

Una tercera opción es que el desarrollador vuelva a establecer una base de todas sus twigs de características en la twig que se ha refactorizado (para que los cambios de refactorización se incorporen en todo su trabajo). A continuación, asegúrese de que la twig de refactorización se revise primero y vuelva a fusionarla en la twig de desarrollo. Todas las twigs de características se basarán en el desarrollo y puede fusionarlas como lo haría normalmente (es decir, fusionar una, volver a establecer las demás en el desarrollo, repetir).

En arte ASCII, antes de revisar la refactorización:

 --- development \ --- refactoring \ --- feature1 --- feature2 

Y después:

 ------ development|refactoring \ --- feature1 --- feature2 

Luego, si finaliza feature1 y lo fusiona en:

 ------ refactoring --- development|feature1 \ --- feature2 

Rebase feature2 en desarrollo nuevamente:

 ------ refactoring --- development|feature1 \ --- feature2 

Y luego puedes combinar feature2 como de costumbre:

 ------ refactoring --- feature1 --- development|feature2