¿Dónde pertenece la refactorización en el modelo de nombres de rama de GitFlow?

22

Recientemente comencé a trabajar con el modelo GitFlow implementado por bitbucket. Y hay una cosa que no me queda completamente clara.

Intentamos abordar regularmente nuestra deuda técnica acumulando, planificando e implementando las tareas de refactorización. Dichas ramas de refactorización terminan con solicitudes de extracción que se fusionan develop. Mi pregunta es ¿a dónde pertenecen las ramas de refactorización en GitFlow ?

  • El uso del featureprefijo parece lo más lógico, sin embargo, no parece del todo correcto, porque la refactorización no agrega ninguna funcionalidad nueva.
  • Sin embargo, el uso del bugfixprefijo no parece correcto, así como tampoco hay correcciones reales de refactorización de errores.
  • Crear un prefijo personalizado, por otro lado, parece complicado si no se hace una ingeniería excesiva de las cosas.

¿Tuviste tal situación? ¿Qué práctica utilizas para abordar esto? Por favor explique por qué.

git  refactoring  branching  gitflow 
— AMA
fuente
¿Por qué necesitas una sucursal para refactores? No alteran la funcionalidad del producto por definición, por lo que debería poder hacerlo directamente en el desarrollo.
— jonrsharpe
@jonrsharpe en resumen, es más conveniente y controlable. Por lo general, hay un ticket de Jira para la refactorización y también se revisa el código durante la solicitud de extracción. Además, se ejecutan compilaciones y pruebas antes de fusionarse. Tratamos de mantener el desarrollo de la rama verde.
— AMA
44
Estás sobre-diseñando cosas, en este caso, el proceso. Refactorice mientras trabaja en el sistema, no como un paquete de trabajo discreto.
— Sr. Cochese
2
En ese caso: 1. Tienes mis simpatías; y 2. Diría que usar refactor, entonces está claro qué transformación se espera que haga cada fusión al producto (corrección de errores: corregir el comportamiento roto, característica: agregar un nuevo comportamiento, refactorizar: conservar el comportamiento anterior). Pero @MrCochese tiene razón, realmente debería ser parte del otro trabajo que está haciendo, no una tarea separada. Tenga en cuenta también que si sus refactores rompen la construcción, ¡ no son refactores!
— jonrsharpe
Parte del trabajo de refactorización que está haciendo realmente debería ser parte del trabajo principal propiamente dicho. Ciertamente no haría ramas de refactorización de forma rutinaria, sino solo como parte de un esfuerzo de limpieza mayor. Hacer de esto un hábito fomentará otros malos hábitos, como diferir el trabajo de limpieza a la rama "refactor".
— Robert Harvey

Respuestas:

27

El trabajo de refactorización debe ir en una rama de características.

El prefijo "característica" es solo una palabra para describir una tarea de programación discreta, puede elegir cualquier palabra que desee, cualquier rama del desarrollo es una rama "característica" o una rama "lanzamiento"

Agregar un nuevo prefijo como "refactorizar" es problemático. Como a menudo refactorizará al agregar una función, simplemente se está dando un problema de nomenclatura y agregando confusión. es decir. "Algunas de nuestras ramas de características se denominan 'refactorización', no, no contienen todo el trabajo de refactorización y a veces tienen correcciones de errores o características '

de manera similar, las ramas "hotfix" no se llaman hotfix porque contienen hotfix, sino porque se ramifican desde el maestro en lugar de desarrollarse

— Ewan
fuente
1
gracias. Esto suena razonable. Esperaré un poco más, y si no hay otras respuestas, aceptaré la suya.
— AMA
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.