Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Las ramificaciones en una estrategia de Gitflow

Una estrategia de ramificación de Gitflow suele tener las siguientes ramas.

rama de característica

Featurelas sucursales son ramas a corto plazo en las que se desarrollan funciones. La feature rama se crea al ramificarse a partir de la develop rama. Los desarrolladores iteran, confirman y prueban el código de la feature rama. Cuando la función está completa, el desarrollador la promociona. Solo hay dos caminos hacia adelante desde una rama de funciones:

rama sandbox

La sandbox rama es una rama no estándar y de corto plazo para Gitflow. Sin embargo, es útil para el desarrollo de canalizaciones de CI/CD. La sandbox rama se utiliza principalmente para los siguientes propósitos:

Sandboxlas sucursales son de naturaleza temporal y no están destinadas a ser duraderas. Deben borrarse una vez finalizadas las pruebas específicas.

desarrollar una rama

La develop sucursal es una rama de larga duración en la que las funciones se integran, crean, validan e implementan en el entorno de desarrollo. Todas las feature sucursales se fusionan en la develop sucursal. Las fusiones en la develop sucursal se realizan mediante una solicitud de fusión que requiere una compilación correcta y la aprobación de dos desarrolladores. Para evitar que se eliminen, habilita la protección de sucursales en la develop rama.

rama de lanzamiento

En Gitflow, las release ramas son ramas a corto plazo. Estas ramas son especiales porque puedes desplegarlas en múltiples entornos, adoptando la metodología de construir una vez y desplegar muchas veces. Releaselas sucursales pueden centrarse en los entornos de prueba, puesta en escena o producción. Una vez que un equipo de desarrollo ha decidido promover funciones en entornos superiores, crea una nueva release rama y utiliza un aumento del número de versión con respecto a la versión anterior. En las puertas de cada entorno, las implementaciones requieren aprobaciones manuales para poder llevarse a cabo. Releaselas sucursales deberían requerir que se modifique una solicitud de fusión.

Una vez que la release rama se haya implementado en producción, se debe volver a fusionar con las main ramas develop y para garantizar que las correcciones de errores o revisiones se fusionen de nuevo en futuras iniciativas de desarrollo.

rama principal

La main rama es una rama de larga duración que siempre representa el código que se está ejecutando en producción. El código se fusiona automáticamente en la main rama desde una rama de lanzamiento tras una implementación correcta desde el proceso de publicación. Para evitar la eliminación, habilita la protección de la rama en la main rama.

rama de corrección de errores

La bugfix rama es una rama a corto plazo que se utiliza para solucionar problemas en las ramas de lanzamiento que no se han lanzado al mercado de producción. Una bugfix rama solo debe usarse para promover correcciones en las release sucursales para los entornos de prueba, preparación o producción. Una bugfix sucursal siempre se ramifica a partir de una release sucursal.

Una vez que se haya probado la corrección del error, se puede ascender a la release rama mediante una solicitud de fusión. A continuación, puedes impulsar la release rama siguiendo el proceso de publicación estándar.

rama de hotfix

La hotfix sucursal es una rama a corto plazo que se utiliza para solucionar problemas en la producción. Solo se utilizará para promover soluciones que deben acelerarse para que lleguen al entorno de producción. Siempre se hotfix ramifica una sucursal desde. main

Una vez que se haya probado la revisión, puedes pasarla a producción mediante una solicitud de fusión en la release rama desde la que se creó. main Para realizar las pruebas, puedes impulsar la release rama siguiendo el proceso de publicación estándar.