# Git Flow - Raloy Lubricantes. ###### tags: `Documentation`,`Git` [TOC] ## Panorama general El modelo de flujos en Git está inspirado en el trabajo de [**[Vincent Driessen](https://nvie.com/posts/a-successful-git-branching-model/)**] ![](https://i.imgur.com/9nOSnpx.png) ## Metodologia El repositorio central tiene dos ramas principales con una vida infinita: - `master` - `develop` Consideramos ==origin/master== que es la rama principal donde el código fuente siempre refleja un estado listo para producción .Al fusionar de deberá ocupar --no-ff que garantizará no perder la existencia historica de la rama. Consideramos ==origin/develop== (Rama de integración )la rama principal donde el código fuente siempre refleja un estado con los últimos cambios de desarrollo entregados para la próxima versión.Al fusionar de deberá ocupar --no-ff que garantizará no perder la existencia historica de la rama. Consideramos ==origin/release== la rama con la cual fusionamos todos los cambios validados de la rama develop a la rama master. Y de generar nuevas especificaciones antes de su fusión con la master, está se fusionará con el develop. Al fusionar de deberá ocupar --no-ff que garantizará no perder la existencia historica de la rama. Utilizamos el flujo propuesto por nuestro controlador de versiones [BitBucket](http://git.consorcionova.com:7990/) ### Merge `--no-ff` ![](https://i.imgur.com/5g9bSbY.png) ### Ramas Los diferentes tipos de ramas que podemos usar son: - `feature` - `hotfix` - `bugfix` - `custom`(De aquí se desprende el `develop`) - `master` ### Feature Puede ramificarse de **develop**, debe *fusionarse* nuevamente en **develop**, no se deben llamar como *master, develop, release-*, o hotfix-* y su nomenclatura se especificará como `release-*` Las ramas feature se utilizán para generar una nueva caracteristica o definición. No se borrará nungun feature y la fusionar de deberá ocupar `--no-ff` que garantizará no perder la existencia historica de la rama. ### Realease Puede ramificarse de **develop**. Su nomenclatura se especifica por release-*. Sirven para la preparación de una nueva versión de producción. Permiten pequeñas correcciones de errores y preparan metadatos para un lanzamiento. No se eliminan versiones. Una vez determinado que la versión esta lista para lanzar a productivo de fusiona con `master` y `develop`. Se ocupará el GitTag `git tag -a {VERSION}` que nos indicará el cambio realizado. ### Hotfix Debe ramificarse de `master`. Su nomenclatura se especifica por `hotfix-*`.Al igual que las **release** también estan destinadas a prepararse para un nuevo lanzamiento de producción, aunque no planificado. Surgen de la necesidad de actuar inmediatamente sobre un estado no deseado de una versión de producción en vivo. Una vez solucionado el conflicto fusionar con `master` y `develop`. ### bugfix Debe ramificarse de `develop`. Su nomenclatura se especifica por `bugfix-*`. Surgen de la necesidad de actuar sobre un estado no deseado de una versión de un `feature`. Una vez solucionado el conflicto fusionar con `feature`.