GIT-Flow ¡Adelante Megazord!

 

Trabajar en equipo siempre nos ha dado el poder que nos faltaba en solitario. Lo sabían los Power Rangers y ahora lo sabemos nosotros. Si los poderes individuales de cada uno era impresionantes, cuando invocaban al Megazord, el enemigo ya había perdido la batalla. Y los Power Rangers también tenían una metodología para ensamblar sus Zords, creando el Megazord, pues GIT-Flow nos va a dar esta rutina para funcionar, haciendo que nuestro proyecto se vaya creando ensamblando las distintas funcionalidades creadas por cada uno de los desarrolladores involucrados en él.

Lo importante en la creación de cualquier proyecto de GIT, es que el conjunto de desarrolladores tengan claras las reglas del juego, podemos decir que van a ser las reglas de nuestro GIT-Flow. Estas reglas van a definir cómo crear las ramas, cómo hacer los commits, las razones por las que vamos a crear una rama y en que lugar las debemos de colocar, para que el resto del equipo pueda entender nuestros movimientos con un simple vistazo al repositorio.

Cómo ya os hemos comentado en el anterior post, usamos SourceTree para el control de los repositorios. Así que vamos a explicar el funcionamiento de GIT-Flow usando SourceTree. Si sois unos desarrolladores curtidos en la consola, aquí os dejamos un par de herramientas que os ayudarán a realizar GIT-Flow desde vuestra consola de comandos:

Con estas bases claras, vamos a hablar ahora de las “reglas” que definen GIT-Flow:

  1. Ramas: el trabajo se va a organizar principalmente en dos branches
    • MASTER: en esta rama vamos a tener principalmente las subidas de nuestro proyecto a producción. Hablando para los mortales, en esta rama nada más debemos de tener el código que este funcionando al 100%, nada de errores. Esto quiere decir que cuando hacemos un commit en MASTER, tenemos una nueva RELEASE (una nueva versión) del proyecto.
    • DEVELOP: es la branch en la que se crean todas las funcionalidades que vamos a tener en el proyecto. Desde aquí iremos creando poco a poco el proyecto e integrando poco a poco el código de los distintos desarrolladores que contribuyen en el proyecto. El padre de esta rama es MASTER.
  2. Ramas auxiliares
    • FEATURE: esta rama se genera y se incorpora siempre a DEVELOP. Se crea este tipo de rama para cuando se va a desarrollar una nueva funcionalidad en el proyecto, cuando está terminada la funcionalidad, se hace merge con la rama DEVELOP. El nombre deseado para este tipo de rama sería feature-nombre_feature.
    • RELEASE: este tipo de rama se genera desde la rama DEVELOP. Cuando se cierra, se incorpora tanto a MASTER como a DEVELOP. Esta rama se usa para preparar las próximas salidas a producción del código, arreglando los últimos bugs y cerrando los últimos detalles para que el código quede preparado. La nomenclatura en esta rama es release-nombre_release.
    • HOTFIX: se crean desde la rama MASTER. Se incorporan tanto a la rama MASTER como a DEVELOP. Se utilizan para arreglar pequeños errores detectados en el código de una release. La única diferencia de estas ramas con las de RELEASE, es que estas no están planificadas.

Básicamente siguiendo estas pautas, podemos organizar nuestro equipo de trabajo en base a estas a normas y funcionar de una manera muy eficiente y efectiva. La idea es que todo el equipo de desarrollo funcione utilizando esta metodología, creando un espacio ordenado en el que todos saben que movimientos se han realizado en el repositorio y las razones de estos cambios.

A continuación….. ¡GIT-Flow desde SourceTree! ¡Tachán!

Una vez tenemos nuestro repositorio preparado con nuestro proyecto como os explicamos en el tutorial de SourceTree, simplemente tenemos que pulsar el botón de GIT-Flow en la esquina superior derecha, esto nos configurará nuestro proyecto para usar GIT-Flow, podéis dejar los nombres y valores por defecto o crear los vuestros propios.

GIT-Flow Button

Tras esto pulsando en ese mismo botón podremos crear features, hot-fixes o releases, así como cerrarlas. Recomendamos no borrar las ramas al cerrarlas porque nunca se sabe cuando querremos volver a ellas tras un desastre.

Pero…
No rules

Si piensas que este modelo de GIT-Flow no se adapta a ti. No hay problema. Puedes crearte tu propio modelo de GIT-Flow. No se le pueden poner diques al mar.

Nosotros por ejemplo habíamos utilizado anteriormente, nuestro propio modelo de GIT-Flow simplficado.

Creábamos como base nuestras ramas MASTER y DEVELOP y luego para funcionar en el día a día cada persona del equipo de trabajo creaba una rama personal, con su nombre, que salía de DEVELOP. Mientras desarrollábamos nuevas funcionalidades en nuestra rama personal, nuestros compañeros hacían lo mismo en las suyas. Más tarde uníamos los cambios en DEVELOP y probábamos que las funcionalidades se habían mezclado de manera correcta.

Nuestro modelo, es mucho más simple que el GIT-Flow explicado más arriba. Pero claro teníamos un equipo pequeño de personas y los proyectos no solían ser demasiado extensos, por lo que complicarnos más el GIT-Flow de nuestro repositorio habría sido una dificultad añadida. También teníamos que trabajar mucho más en los comentarios de los commits para que quedasen bien identificados los cambios que se habían implementado en este commit.

Con la experiencia hemos aprendido a que el orden de un repositorio es importante por eso recomendamos MUCHO el primer modelo. Evitad problemas ordenado bien vuestros repositorios. Hacednos casos. Que ya somos viejos pellejos.

Old man

 

Muchas gracias!

Saludos drunkcoderos!

Adelante GIT-FLOW!

  • Hola amigos,

    ¿Podríais detallar cómo se “incorporan” las ramas RELEASE y HOTFIX en MASTER y DEV? Con un ejemplo, porfi bebés.