paint-brush
¿Son las ramas de características la forma definitiva de hacerlo?por@vbakin
1,166 lecturas
1,166 lecturas

¿Son las ramas de características la forma definitiva de hacerlo?

por Vladislav Bakin3m2023/05/19
Read on Terminal Reader

Demasiado Largo; Para Leer

El flujo de trabajo común para git (git flow) usa ramas de funciones, donde se crea una rama separada para cada nueva función. Desafortunadamente, esta estrategia tiene una desventaja significativa: conflictos de fusión. Sin embargo, no es la única estrategia posible, y este artículo cubrirá una forma alternativa de administrar nuevas funciones sin estas desventajas.
featured image - ¿Son las ramas de características la forma definitiva de hacerlo?
Vladislav Bakin HackerNoon profile picture

El flujo de trabajo común para git (git flow) usa ramas de funciones, donde se crea una rama separada para cada nueva función. Los desarrolladores implementan nuevas funciones en estas ramas aisladas y luego fusionan sus cambios nuevamente en la rama main o master .


Los beneficios de ese flujo de trabajo son claros: una rama separada se puede implementar y probar convenientemente en el entorno de control de calidad, y si se detectan errores críticos, simplemente no se fusionará con la rama main . Los problemas se pueden solucionar y mejorar el código en la misma rama.


Mientras tanto, la rama principal permanece constantemente desplegable y protegida de esos problemas.


Desafortunadamente, esta estrategia tiene una desventaja significativa: conflictos de fusión. Con las ramas de larga duración, que en algún momento son inevitables, estos conflictos pueden ser demasiado difíciles de resolver, por lo que es más fácil deshacerse de la rama por completo y comenzar desde cero.


Además, cuando hay muchos conflictos, el resultado de la combinación puede ser impredecible.


Sin embargo, no es la única estrategia posible, y este artículo cubrirá una forma alternativa de administrar las funciones de nuevos productos sin las desventajas enumeradas anteriormente.

¿Por qué ocurren los conflictos de fusión?

De acuerdo con el diseño de Git, los conflictos de fusión ocurren durante la fusión cuando las ramas tienen contenido diferente en la misma línea de archivo.


Para ilustrar esto, consideremos un escenario en el que dos equipos están implementando actualizaciones para el mismo servicio. El equipo A está integrando la compatibilidad con tarjetas de crédito, mientras que el equipo B está renovando la página de perfil de usuario. Parece que estas características no tienen nada que ver entre sí.


Sin embargo, resulta que el código relacionado con el pago se encontraba previamente en el mismo lugar que el código de la página de perfil. Entonces, ambos equipos extrajeron su código en ramas separadas y reescribieron la integración.


Ahora la pregunta es, ¿quién será el primero en fusionar sus cambios en la rama main y pretender que el problema no está de su lado mientras el otro equipo intenta resolver el conflicto resultante?


La última fusión fue complicada y tuvo tres conflictos.


Desarrollo basado en troncales

En total, es imposible evitar los conflictos de combinación, pero ciertamente podemos hacerlos más fáciles de resolver usando la siguiente regla bien conocida:


Si una acción es difícil y da miedo, hazla con más frecuencia.


En términos de Git, esto significaría que debemos fusionarnos con la mayor frecuencia posible (idealmente en cada confirmación). Y, por supuesto, los conflictos ocurrirán con más frecuencia en ese caso, pero resolverlos será mucho más fácil.


Se llama desarrollo basado en troncos y significa enviar cambios directamente a la rama main y evitar el uso de ramas cuando no sea necesario.


En el ejemplo anterior, si ambos equipos enviaran regularmente sus cambios a la rama main , notarían rápidamente que estaban tratando de modificar el mismo archivo.


Aún más, podrían haber evitado problemas por completo. El segundo equipo habría comenzado a realizar sus cambios después de que el primer equipo ya hubiera modificado el archivo, teniendo en cuenta esas actualizaciones.


El uso del desarrollo basado en troncales resolvió un conflicto para el ejemplo anterior.



Un lector atento podría preguntarse: todo suena muy bien, pero ¿cómo hacemos las pruebas? Las ramas por característica permiten probar la nueva funcionalidad completa de forma aislada antes del lanzamiento; si integramos cambios continuamente en la rama main , no habrá posibilidad de eso.

Presentación de indicadores de características

Un indicador de función, o un conmutador de función, es un indicador dinámico simple que permite alternar la función particular en tiempo de ejecución. Por lo general, los indicadores de funciones también permiten habilitar o deshabilitar funciones para grupos específicos de usuarios, como ingenieros de control de calidad, personal, clientes específicos, etc.


Uso típico de indicadores de características.


Las banderas de características tienen varias ventajas adicionales:


  • Despliegue sin riesgos


  • Pruebas más fiables directamente en producción


  • Revertir rápidamente los cambios cuando sea necesario.


El uso de indicadores de función hace que los cambios de inserción en la rama main sean más seguros. Mientras el indicador de función esté desactivado, los cambios no afectarán a nadie.


Esta técnica permite trabajar directamente con la rama main o crear ramas de vida corta. Entonces, los conflictos de fusión se vuelven bastante raros y se resuelven rápidamente.

Conclusión

En resumen, el desarrollo basado en troncales combinado con indicadores de características es una técnica excelente que ayuda a evitar muchos problemas provocados por cambios conflictivos en las ramas de características.


Sin embargo, como siempre, no hay una talla única para todos. Funciona para una pequeña cantidad de equipos que trabajan en el mismo repositorio; aumentar este número generalmente requiere algunos ajustes.


Además, siempre es posible usar ambos métodos: usar ramas de características o indicadores de características según la situación y la tarea específicas.