|
| 1 | +## Introducción |
| 2 | + |
| 3 | +En este tutorial vamos a explicar cómo trabajar con ramas en Git de una forma muy sencilla, gracias a la herramienta [Git-Flow](https://github.com/nvie/gitflow) de Vincent Driessen. |
| 4 | + |
| 5 | + |
| 6 | + |
| 7 | +<br /> |
| 8 | + |
| 9 | + |
| 10 | + |
| 11 | +## ¿Qué es Git-Flow? |
| 12 | + |
| 13 | +Git-Flow es una herramienta diseñada para el control de versiones en Git que define un modelo de ramificación robusto para gestionar proyectos de desarrollo de software. |
| 14 | + |
| 15 | + |
| 16 | + |
| 17 | +El modelo de GitFlow cuenta con dos ramas principales, **master** y **develop**, y varias de soporte para estas que podrán ser ramas de **feature**, **release** y **hotfix**. |
| 18 | + |
| 19 | +- La rama **master** es la que contiene la última versión de nuestro proyecto y usaremos para desplegar en producción. |
| 20 | +- La rama **develop** es la que contiene el último estado del desarrollo del mismo, es decir, hasta el último commit que hayamos hecho. |
| 21 | +- Las ramas de **feature** se usarán para desarrollar nuevas funcionalidades, se crearán a partir de la rama develop y al terminar se fusiona con develop. |
| 22 | +- Las ramas **release** se usarán para lanzar una nueva versión de nuestro proyecto y se fusionaran tanto con master como con develop. |
| 23 | +- Las ramas **hotfix** se usarán para cambios rápidos sobre la rama master y se fusionan con master y develop. |
| 24 | + |
| 25 | + |
| 26 | + |
| 27 | +<br /> |
| 28 | + |
| 29 | + |
| 30 | + |
| 31 | +## Instalar GitFlow |
| 32 | + |
| 33 | +Para instalarlo sobre nuestro PC en Linux basta con lanzar la siguiente instrucción sobre la terminal: |
| 34 | + |
| 35 | +```sh |
| 36 | +migueabellan@Ubuntu:~ $ sudo apt install git-flow |
| 37 | +``` |
| 38 | + |
| 39 | +Una vez instalado y desde el directorio raiz de nuestro proyecto, tenemos que inicializarlo de forma similar a como hacemos con Git. Esto nos hará una serie de preguntas sobre como queremos nombrar a las diferentes ramas, el prefijo de nuestras versiones, etc. |
| 40 | + |
| 41 | +```sh |
| 42 | +migueabellan@Ubuntu:~ $ git flow init |
| 43 | +``` |
| 44 | + |
| 45 | +Tras la inicialización observaremos que nos encontramos sobre la rama develop de nuestro repositorio. Algo similar a lo siguiente: |
| 46 | + |
| 47 | +```sh |
| 48 | +migueabellan@Ubuntu:~/miproyecto (develop) $ | |
| 49 | +``` |
| 50 | + |
| 51 | +## Ramas Features |
| 52 | + |
| 53 | +Para empezar a desarrollar una nueva funcionalidad tenemos que crearla mediante el comando `git flow feature start [nombre]`, por ejemplo: |
| 54 | + |
| 55 | +```sh |
| 56 | +migueabellan@Ubuntu:~ $ git flow feature start nueva_feature |
| 57 | +``` |
| 58 | + |
| 59 | +Observaremos que de forma automática se ha creado la rama `nueva_feature` y estamos trabajando sobre dicha rama: |
| 60 | + |
| 61 | +```sh |
| 62 | +migueabellan@Ubuntu:~/miproyecto (develop/nueva_feature) $ | |
| 63 | +``` |
| 64 | + |
| 65 | +Una vez consideres que has terminado la funcionalidad y tras comitear los cambios, se finaliza la rama fusionando de forma automática todos los cambios sobre la rama develop. Utilizaremos el siguiente comando: |
| 66 | + |
| 67 | +```sh |
| 68 | +migueabellan@Ubuntu:~ $ git flow feature finish nueva_feature |
| 69 | +``` |
| 70 | + |
| 71 | +## Ramas Releases |
| 72 | + |
| 73 | +Después de haber desarrollado unas cuantas features y haberlas commiteado, queremos liberar una nueva versión de nuestro proyecto y para ello utilizaremos la rama releases de forma similar a la anterior. Es decir, creamos la rama utilizando el comando `git flow release start [nombre_version]` y una vez finalizado los cambios cerramos la rama mediante el comando `git flow release finish [nombre_version]`. |
| 74 | + |
| 75 | +```sh |
| 76 | +migueabellan@Ubuntu:~ $ git flow release start version_1 |
| 77 | +... |
| 78 | +... |
| 79 | +migueabellan@Ubuntu:~ $ git flow release finish version_1 |
| 80 | +``` |
| 81 | + |
| 82 | +Podemos observar que en este momento se han fusionado correctamente las ramas develop y master. |
| 83 | + |
| 84 | +## Ramas Hotfix |
| 85 | + |
| 86 | +Como podemos imaginar, puede que se de el caso de querer modificar un línea o bug de nuestro código sobre la rama master sin necesidad de lanzar una nueva release. Es en este caso cuando utilizamos las ramas hotfix de forma similar a las anteriores: |
| 87 | + |
| 88 | +```sh |
| 89 | +migueabellan@Ubuntu:~ $ git flow hotfix start bug_1 |
| 90 | +... |
| 91 | +... |
| 92 | +migueabellan@Ubuntu:~ $ git flow hotfix finish bug_1 |
| 93 | +``` |
| 94 | + |
| 95 | +Una vez solucionado el bug y cerrada la rama de hotfix, observaremos que los cambios se han fusionado sobre las ramas master y develop para que podamos seguir trabajando con normalidad. |
| 96 | + |
| 97 | + |
| 98 | +<br /> |
| 99 | + |
| 100 | +## Conclusiones |
| 101 | + |
| 102 | +Como veis GitFlow automatiza la forma de trabajar con git, aplicando un flujo de trabajo adaptándose perfectamente a la mayoría de los proyectos de desarrollo de software. |
0 commit comments