🇬🇧 English version
🇫🇷 Version française
¿Tienes un nuevo empleo o en tu trabajo actual están planeando implementar Git-Flow y no sabes de qué se trata?
Has venido al lugar indicado. En este post te lo explico, pero si ya lo conoces un poco y solo quieres indicaciones sobre su uso, salta al tutorial.
🧐 Contexto
En pocas palabras, Git es un sistema de gestión de versiones, es una herramienta indispensable para controlar el ciclo de vida del desarrollo de una aplicación.
Hasta aquí todo bien, pero los problemas empiezan a aparecer cuando se trabaja en equipo: tú y tu equipo podrían decidir de simplemente trabajar en la rama principal del proyecto y crear algunas ramas secundarias en ocasiones especiales, pero ¿qué pasa cuando hay mucho trabajo o varias personas deben trabajar en la misma función al mismo tiempo?
📓 Git-Flow
Al trabajar en equipo, es necesario definir convenciones o buenas practicas para que todos sepan como trabajar juntos. Git-Flow es uno de muchos de los llamados flujos de trabajo, bastante popular por su practicidad y aprendizaje relativamente rápido, es una manera de organizar las ramas del repositorio del proyecto.
Probablemente ya has visto esta imagen o una parecida al buscar el término Git-Flow en Internet:
Git-Flow en una imagen
Parece y es complicado a primera vista, pero al conocer las diferentes ramas utilizadas y el por qué de su existencia veras que su funcionamiento es bastante lógico.
🌳 Ramas
Como ya vimos en la imagen, Git-Flow utiliza varias ramas para organizar el desarrollo:
- master
- develop
- feature
- release
- hotfix
🌴 master y develop
Si ya has utilizado Git antes, estarás familiarizado con la rama master
. En este nuevo contexto, esta rama es "intocable", nadie del equipo debe hacer ningún cambio directamente en ella, ni crear nuevas ramas a partir de ella, con una excepción que veremos más adelante.
Al crear un nuevo proyecto, o al momento de comenzar a utilizar Git-Flow, la rama develop
debe ser creada a partir de master
, y al igual que master
, sera una rama de "larga duración de vida", es decir, nunca sera borrada y vivirá paralelamente a master
.
Como su nombre lo indica, la rama develop
sirve como base para desarrollar todas las nuevas funciones y correcciones del proyecto, por eso es considerada como la rama principal.
Una vez que todas las nuevas funciones del proyecto han sido completadas y develop
es estable, debemos hacer un merge
de develop en master
.
La rama master
debe reflejar siempre un estado 'en producción', por eso es importante que no realicemos cambios directamente en ella, ya que cada vez que hay un nuevo commit
, deberíamos hacer un tag
para definir la nueva versión y publicarla.
💯 feature
Las ramas feature
son aquellas que dedicamos completamente al desarrollo de cada una de las nuevas funciones que agregaremos al proyecto en la versión siguiente. Siempre parten de develop
y debemos hacer el merge
de regreso a develop
.
Si seguimos las buenas practicas de Git-Flow, al crear una nueva rama feature
, siempre debemos agregar el prefijo feature/
, de esta manera podemos mantener una buena organización y al ver las ramas activas podremos identificar rápidamente el trabajo en curso.
Al mismo tiempo, es importante nombrar las ramas feature
de una forma descriptiva que permita identificar la finalidad de la rama:
❌ feature/new-method
✔️ feature/add-support-for-json-parsing
Lo importante de las ramas feature es que vivan solamente durante el desarrollo y que desaparezcan una vez que hayamos realizado el merge
en develop
o que sean descartadas si la función ya no es necesaria.
NOTA: el prefijo feature/*
es la practica por defecto, pero si tu o tu equipo lo estiman necesario, pueden adaptar el prefijo a cualquier otra cosa, por ejemplo funcionalidad/...
⭐ release
La rama release
sirve para reagrupar las funcionalidades y correcciones efectuadas para poder preparar el lanzamiento de la versión en desarrollo. Esta rama parte de develop
y el merge
se hace tanto en develop
como en master
.
El momento perfecto para crear las ramas release
es cuando la rama develop
se asemeja lo mas posible a lo que queremos tener en producción, es una manera para poder hacer las correcciones de ultimo minuto que pudimos haber olvidado, o para realizar cambios del proyecto que no necesariamente necesitan toda una rama para ser realizados, por ejemplo para aumentar el numero de versión.
Siguiendo las practicas de Git-Flow, las ramas release
también tienen un prefijo, release/*
o release-*
, normalmente seguido del numero o nombre de la versión que representan, por ejemplo: release/1.2.0
o release/5.0
o release/1.0.0-rc.1+build.123
.
La ventaja de tener una rama release es que el trabajo puede continuar en develop
y otras nuevas ramas feature
, ya que el trabajo planeado ya se encuentra en la release y no va a tener cambios importantes.
🛠️ hotfix
Las ramas hotfix
parten de master
y debemos realizar el merge
de vuelta en master
y develop
. Son utilizadas para realizar correcciones rápidas al proyecto, para poder publicar una nueva version lo antes posible.
NOTA: Si creamos una rama hotfix
pero ya existe una rama release
, en lugar de hacer el merge
en develop
, debemos hacer el merge
en master
y release
.
⚔️ hotfix vs bugfix
En algunos proyectos podemos ver que ademas de las ramas hotfix
, a veces tenemos algunas con el prefijo bugfix
. La diferencia entre estos dos tipos de ramas es que las bugfix
se comportan como las feature
y las hotfix
se comportan como las release
.
Visto de otra manera, podemos utilizar las bugfix
para realizar correcciones de bugs no muy importantes que pueden esperar al lanzamiento de la versión en desarrollo, mientras que las hotfix
no pueden esperar y deben ser publicadas en cuanto el desarrollo haya sido aprobado.
✔️ bugfix/fix-some-thingy-that-almost-nobody-uses-and-its-not-really-important
✔️ hotfix/fix-clic-on-top-right-corner-of-login-button-sets-the-users-computer-on-fire
✏️ Tutorial
Para este tutorial y con el fin de simplificarlo al maximo, utilizaré el plugin para consola de Git-Flow de Peter van der Does, pero aquí te dejo los comandos clásicos Git equivalentes a los comandos de Git-Flow.
-
Habilitar Git-Flow en el proyecto
# Inicia Git en el proyecto, crea la rama develop y # configura los prefijos de las otras ramas. # Finalmente, cambia a la rama develop git flow init
-
Comenzar a trabajar en una nueva funcionalidad
# Crear una nueva rama feature/* y cambiarse a ella git flow feature start <feature-name>
Podemos ver como la consola nos dice las acciones efectuadas y que podemos comenzar a trabajar en la nueva rama. -
Terminar una funcionalidad
# El nombre de la feature es opcional, no es necesario si # ya nos encontramos en la rama. # Cambia a develop, hace un merge de la feature hacia develop # Y elimina la rama feature git flow feature finish <feature-name>
NOTA: Todas estas acciones son realizadas en tu repositorio local, nada en el distante, a menos que realices un
push
. Recuerda hacerlo al terminar tus features, para actualizardevelop
. -
Preparar la nueva versión
# Crea una nueva rama release/* desde develop y cambia a ella. git flow release start <version-name>
NOTA: Justo después de actualizar el numero de versión de tu proyecto es un buen momento para publicar la rama release en
origin
. -
Terminar la versión
# Cambia a la rama master # Hace un merge de la release # Crea el tag de la versión utilizando el nombre de la rama # Cambia a la rama develop # Hace un merge de la release # Elimina la rama release git flow release finish # No olvides enviar los últimos cambios a `origin` utilizando los comandos clásicos de Git git push origin master git push origin develop git push --tags git push origin :release/1.2.0 (si la release estaba en el repo distante)
-
Crear un hotfix
# Puede ser creada a partir de un commit específico o simplemente del ultimo existente. # Crea una rama hotfix y cambia a ella git flow hotfix start <hotfix-name> [<commit>]
-
Finalizar un hotfix
# Ocurre lo mismo que en una release # No olvides especificar el argumento -T o --tagname # para crear un tag correctamente si el nombre de tu # rama hotfix no es un numero de versión. git flow hotfix finish [<-T version-name>]
Siguientes pasos
En un siguiente articulo, hablaremos de otras estrategias, pero si por el momento quieres aprender mas sobre Git-Flow, aquí te dejo algunas fuentes que utilicé para este articulo.
A successul Git branching model: El articulo original del creador de Git-Flow
Git-Flow cheat sheet: Un vistazo rápido sobre los comandos de Git-Flow
GitFlow considered harmful: Una alternativa mas simple a Git-Flow y una probada de lo que vamos a ver en el próximo articulo.
Top comments (0)