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.
![\[Las ramas y los entornos de una estrategia de ramificación de Gitflow.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-branching-strategy.png)
## rama de característica
`Feature`las 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:
+ Incorpórese a la `sandbox` rama
+ Crea una solicitud de fusión en la `develop` sucursal
| | |
| --- |--- |
| Convención de nomenclatura: | `feature/__` |
| Ejemplo de convención de nomenclatura: | `feature/123456_MS_Implement_Feature_A` |
## 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 CI/CD canalizaciones. La `sandbox` rama se utiliza principalmente para los siguientes fines:
+ Realice una implementación completa en el entorno sandbox mediante las CI/CD canalizaciones en lugar de una implementación manual.
+ Desarrolle y pruebe una canalización antes de enviar solicitudes de fusión para realizar pruebas completas en un entorno inferior, como el de desarrollo o las pruebas.
`Sandbox`las sucursales son de naturaleza temporal y no están destinadas a ser duraderas. Deben borrarse una vez finalizadas las pruebas específicas.
| | |
| --- |--- |
| Convención de nomenclatura: | `sandbox/__` |
| Ejemplo de convención de nomenclatura: | `sandbox/123456_MS_Test_Pipeline_Deploy` |
## 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.
| | |
| --- |--- |
| Convención de nomenclatura: | `develop` |
## 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. `Release`las 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. `Release`las 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.
| | |
| --- |--- |
| Convención de nomenclatura: | `release/v{major}.{minor}` |
| Ejemplo de convención de nomenclatura: | `release/v1.0` |
## 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.
| | |
| --- |--- |
| Convención de nomenclatura: | `main` |
## 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.
| | |
| --- |--- |
| Convención de nomenclatura: | `bugfix/__` |
| Ejemplo de convención de nomenclatura: | `bugfix/123456_MS_Fix_Problem_A` |
## 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.
| | |
| --- |--- |
| Convención de nomenclatura: | `hotfix/__` |
| Ejemplo de convención de nomenclatura: | `hotfix/123456_MS_Fix_Problem_A` |