Es muy probable que utilices Git en tu día a día, en el trabajo o en proyectos que hagas en tu tiempo libre, solo o en equipo. Pero, ¿Te has planteado alguna vez la metodología que más se adapta a tus necesidades y a las de tu equipo?
Si no lo has hecho te recomiendo que leas esta pequeña guía de Atlassian, de esta guía voy a darte más información sobre como trabajar con Gitflow, un método que me gusta bastante y con el que trabajo siempre que puedo.
El esquema del workflow
Para explicar gitflow he hecho mi propio esquema, totalmente basado en el que habrás podido ver en el artículo de Atlassian, pero con el que quiero ampliar y detallar la forma de trabajar que me gusta seguir con este workflow.
Abrimos Sourcetree y empezamos con una rama master, es posible que ya tengas commits viejos en esa rama, no hay problema.
Vamos a configurar Gitflow en este repositorio, hacemos clic en el botón de Gitflow y configuramos los nombres de las ramas, en mi caso dejo los nombres por defecto.
Ahora vamos a tener dos ramas en el mismo punto, master y dev, para la primera vamos a configurar que se haga una build y una publicación a nuestro servidor de producción en cada commit, y en la segunda una build y una publicación a nuestro servidor de desarrollo (Por supuesto esto no lo vamos a configurar en sourcetree, depende de un tercero por ejemplo TFS de Microsoft).
Perfecto, en este punto repasamos nuestra iteración o nuestro sprint y vemos que tenemos una serie de historias (stories en inglés) que tenemos que abordar. Vamos a hacer una rama por cada historia que se va a llamar feature/nombre_historia, con el programa con el que estamos trabajando es tan fácil como hacer clic en el botón de Gitflow y añadir una nueva feature.
Ponemos el nombre de la feature, especificamos que parta del último commit que hay en dev y veremos que se crea una nueva rama (una rama temporal) y podemos observar que en Sourcetree aparece dentro de la carpeta feature es solo una manera de agrupar todas las ramas que empiezan por feature/ realmente no hay ninguna carpeta, esto lo puedes observar fácilmente si vas a la consola y escribes ‘ git branch’.
Vamos implementando nuestra historia, hacemos commits y llega un punto en la que la hemos terminado, ahora queremos finalizar la feature, seleccionamos que haga un rebase a dev (suele haber un poco de debate sobre si hacer rebase o merge en estas ocasiones, como podrás ver en el esquema final siempre hago rebase de las feautres a dev y merge en el resto de casos, esta decisión es por lo que he leído y observado con el tiempo, por las configuraciones que ofrece Sourcetree y por opinión personal)
Este es el esquema que nos quedaría si fueramos creando features y finalizandolas con este método.
En algún punto es necesario hacer una nueva release y la queremos hacer sin afectar y sin que nos afecte al flujo de trabajo, así que volvemos a nuestro botón de Gitflow y asignamos un nombre a nuestra release, por ejemplo el nombre de versión a la que corresponde.
Es probable que probando la release en nuestro entorno de PRE encontremos algún error, así que lo corregimos generando algunos commits y finalizamos la release, al hacerlo podemos añadir un tag de la versión que quedará marcado en master.
Esto nos va a generar un merge a master y otro merge a dev (no queremos perder lo que acabamos de tocar en la rama release) obteniendo el siguiente esquema.
Puedes observar la diferencia entre hacer un rebase y un merge en el esquema anterior, la puedes encontrar aquí.
¡Ojo! el típico error crítico que aparece en producción, para eso están los hotfix, desde Sourcetree, vamos al botón de Gitflow y creamos un nuevo hotfix, haremos los cambios necesarios y lo finalizaremos.
Es el momento de ver el aspecto que tiene el esquema final de nuestro flow.
Y el bonus track es esta imagen donde he añadido los momentos en los que ocurren acciones como un despliege automatizado, una validación de una historia, etc.
La diferencia entre release, hotfix y feature, es que a veces la gente no borra las ramas de features, pero yo sí. Por eso solo he marcado Hotfix/ y Release/ como temporales y Feature/ no porque esta última es ‘opcionalmente’ temporal.
Espero que con este artículo hayas podido ampliar un poco más tu información para trabajar con el workflow Gitflow en git, si quieres más información puedes consultar este post de Vincent Driessen con mucha información más teórica sobre este workflow.
Si quieres, puedes leer este artículo en inglés, publicado en Medium.
Don’t lose your flow with Sourcetree and Gitflow
¿Necesitas este esquema por fases en una presentación? Gitflow Workflow