---
# System prepended metadata

title: Git Flow - Raloy Lubricantes.
tags: [Documentation, Git]

---

# 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`.

