Git feature branches y minor code improvements

Question

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 utilizar 'develop' como la rama de integración principal y desarrollar todas las funciones en las ramas de características fuera de 'develop'. Cuando se completa una característica, el desarrollador crea una solicitud 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 en una función, el desarrollador puede terminar queriendo 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.

Según nuestro flujo de trabajo, realmente debería hacerse en una rama diferente que pase por su propia solicitud de extracción y revisión de código antes de entrar en desarrollo. Sin embargo, si los hacemos hacer esto, ¿cómo pueden obtener el cambio nuevamente en su rama 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) cereza recoger los cambios de la rama 'refactorX' en nuestra rama de la característica. Continúa desarrollando y deja que git (con suerte) descubra cuándo nos fusionamos para desarrollar que ya tiene el cambio de la rama de refactorización.

2) Fusiona la rama 'refactorX' en nuestra rama de características y continúa el desarrollo. (nota: la ramificación desarrollada para 'refactorX' puede haber estado más adelante en la historia de desarrollo, entonces 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 surgirá con frecuencia y queremos encontrar una manera fácil y eficiente de manejarlo en nuestro flujo de trabajo.

¿Alguna recomendación?

Answer 1

Parece que usted está tratando de evitar la fusión de la rama desarrollar de nuevo en la rama de la característica. Es beneficioso evitar este paso, pero a veces es necesario, especialmente en situaciones como esta.

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

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

El proceso de movimiento típico podría parecerse a

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

Ahora usted tienen nuevo código en su rama de la característica, pero no se han fusionado la rama convertirse en la rama de la característica.

Answer 2

Una tercera opción es que el desarrollador vuelva a establecer una base de todas sus ramas de características en la rama 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 rama de refactorización se revise primero y vuelva a fusionarla en la rama de desarrollo. Todas las ramas 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 el arte ASCII, antes de la revisión de la refactorización:

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

Y después:

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

Entonces, si se termina feature1 y fusionarla en:

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

Usted rebase feature2 en desarrollo nuevamente:

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

Y entonces se puede fusionar característica2 como de costumbre:

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