Flujos de trabajo y estrategias de ramas en Git

Hasta ahora hemos visto cómo se puede utilizar Git para manejar el código fuente de un proyecto. Sin embargo todavía no hemos hablado de las estrategias que se pueden seguir a la hora de trabajar en equipo.

Todaslasestrategiassebasanesencialmenteenlaformaenlaquevasatratarde crear (o no) ramas y fusionarlas a la rama principal. Y no, no hay una estrategia perfecta. Cada equipo y proyecto es un mundo, y esas peculiaridades son las que pueden marcar la diferencia para elegir entre una estrategia u otra.

En este capítulo vamos a revisar las tres estrategias más famosas que se pueden seguir a la hora de trabajar en equipo: Git Flow,GitHub FlowyTrunk Based Development. También hablamos de otra estrategia, bastante más moderna, llamada Ship / Show / Ask. Al final del capítulo te compartiré mi opinión al respecto y a qué creo que deberías aspirar.

Usar una buena estrategia en un proyecto puede determinar la velocidad, o incluso el éxito, de los desarrollos del equipo

Git Flow

Una de las estrategias más famosas a la hora de trabajar en equipo es Git Flow. Fue ideada por el desarrolladorVincentDriessenen el año 2010 y presentada en el artículo “A successful Git branching model”²⁵.

En la imagen de Vincent Driessen se presentan todas las ramas necesarias para poder seguir la estrategia

Las ramas principales

EnGit Flowexisten dos ramas principales que deben ser creadas al iniciar el
repositorio:

^²⁵ https://nvie.com/posts/a-successful-git-branching-model/
main (o master ): Su propósito es contener el código que se encuentra en producción. - develop : Código de pre-producción con nuevas características que todavía tienen que ser probadas y validadas pero que serán lanzadas en el próximo pase a producción.

Una vez que la ramadevelopesté lista y estable, sus cambios serán incorporados a la ramamainpara crear una nueva versión de producción. Más adelante veremos cómo lo logramos.

Al final, en Git Flow tienes que entender que cada commit a la rama principal main se refiere a una versión de producción.

Al incorporar los cambios de la rama develop a main se genera un nuevo lanzamiento de versión a producción

Las ramas de apoyo

Además de las ramasmainydevelopexisten las ramas de apoyo. Hay tres tipos de ramas de apoyo y, a diferencia de las principales, son ramas temporales que serán eliminadas una vez que sean fusionadas. Cada rama tiene una misión en concreto:

Feature: Cuando trabajas en una nueva característica para el proyecto. - Release: Cuando preparas el lanzamiento de una nueva versión. - Hotfix: Para trabajar en cambios imprevistos como parches para arreglar un bug o un problema en producción.

Ramas Feature

Lo natural en cualquier proyecto es trabajar en nuevas características para iterarlo y hacerlo cada vez mejor y más completo. Estas nuevas funcionalidades, aunque no se sabe exactamente cuándo se lanzarán a producción, están planificadas y, normalmente, documentadas.

Para trabajar en este tipo de desarrollo en Git Flowexisten las ramasfeature. Estas ramas se crean a partir de la ramadevelopy, una vez finalizan, son fusionadas de nuevo endevelopy eliminadas.

Creamos ramas feature desde la rama develop y, más tarde, volverán a ser integradas en esta rama

Cómo crear y fusionar una rama feature

Como hemos dicho anteriormente, debemos crear la ramafeature a partir de develop. Para ello usamos el siguiente comando:

# creamos una rama llamada feature-new-search desde develop

$ git switch -c feature-new-search develop
Switched to a new branch "feature-new-search"

Aquí trabajaremos en la feature, añadiendo los commits que sean necesarios a la rama, hasta que estemos satisfechos con la nueva característica. Entonces será el momento de fusionar ese trabajo a la ramadeveloppara que esté disponible en el próximo lanzamiento.

# vamos a la rama develop

$ git switch develop
Switched to branch 'develop'

# fusionamos nuestra feature sin fast-forward
$ git merge --no-ff feature-new-search
Updating dc3a92a..12c6443
(Summary of changes)

# eliminamos la rama que ya no necesitamos
$ git branch -d feature-new-search
Deleted branch feature-new-search (was 12c6443).

# empujamos los cambios al repositorio remoto
$ git push origin develop

El parámetro—no-ffes opcional. Sirve para crear siempre un commit al fusionar la rama, incluso cuando se podría realizar unfast-forward. Esto se hace para dejar en el historial de commits un commit que contenga todos los cambios de la rama que se está fusionando. De otra forma sería imposible seguir el flujo de trabajo de la rama developa la hora de saber qué cambios se han añadido para una rama en concreto. Aunque el historial queda “más sucio”, la información es más importante que la limpieza.

Aquí puedes ver la diferencia entre ejecutar git merge con o sin el argumento –no-ff

Resumen de ramas feature:

Se crean desde:develop
Se fusionan endevelop
Convención de nombre:feature-*

Ramas Release

Las ramasreleasesirven para preparar un nuevo lanzamiento de nuestro código a producción. Para ello, una vez que la ramadevelopha sido validada y tiene los

cambios que queremos lanzar, creamos a partir de ella una ramarelease. Se fusionan de nuevo endevelop, mainy, después, eliminadas.

Aunque no es recomendable, en las ramasreleasese puede seguir trabajando para añadir algún pequeño cambio de última hora o algún parche a un error que haya sido detectado justo antes del lanzamiento. También se puede, y seguramente es mejor opción, usar unhotfixcomo veremos más adelante.

Lo que sí que vamos a evitar es trabajar en cualquier nueva característica que podría en su lugar ser creada en una ramafeature. La idea es que la ramareleaserefleja la versión final del código que va a llegar a producción y será la nueva ramamaindel proyecto.

Cómo crear y fusionar una rama release

Las ramasreleasese crean, como hemos comentado, a partir de la ramadevelop. Para ello usamos el siguiente comando:

# creamos la rama release con la versión 1.2.0 desde develop
$ git checkout -b release-1.2.0 develop
Switched to a new branch "release-1.2.0"

# esto debería actualizar los archivos necesarios

$ ./bump-version.sh 1 .2.0
Files modified successfully, version bumped to 1 .2.0.

# añadimos un commit con los cambios generados
$ git commit -am "Bumped version number to 1.2.0"
[release-1.2 74d9424] Bumped version number to 1 .2
1 files changed, 1 insertions(+), 1 deletions(-)

En este punto podemos realizar algunos cambios aunque es poco recomendable… Aunque la ramareleasepuede vivir durante un tiempo, lo mejor es que sea usada lo antes posible.

Para finalizar la rama dereleasetenemos que fusionarla condevelopymain. Para
ello hacemos:

# cambiamos a la rama main

$ git switch main
# fusionamos la rama release con la rama main
$ git merge --no-ff release-1.2.0
Merge made by recursive.
(Summary of changes)
# creamos un tag para etiquetar la nueva versión
$ git tag -a 1 .2.0

# ahora nos toca también hacer lo propio con develop
$ git switch develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2.0
Merge made by recursive.
(Summary of changes)

Es posible que encuentras algún conflicto al volver a la ramadevelop, ya que las personas del equipo han podido seguir trabajando sobre ella. No pasa nada, resuelve los conflictos y haz un commit a develop para solucionarlos.

Una vez hemos terminado con la rama derelease, procedemos a eliminarla.

$ git branch -d release-1.2.0
Deleted branch release-1.2.0 (was ff452fe).

Resumen de ramas release:

*Se crean desde:develop
*Se fusionan endevelopy master
Convención de nombre:release-

Ramas Hotfix

Las ramas de apoyohotfixson ramas temporales que se crean para trabajar en cambios imprevistos. Una vez que se hayan validado y aprobados, se incorporan a la ramamainpara crear una nueva versión de producción.

Puedes traducirhotfixcomoparche, paño calienteotirita. Soluciones temporales a problemas o cambios imprevistos. Por eso, al crear una rama hotfix se debe hacer desde la rama main ya que no se podría crear una solución desde la ramadevelopya que contiene cambios que pueden ser inestables todavía.

Lo que sí que tiene sentido es que, más adelante, fusionaremos el mismohotfixa developpara que el problema no vuelva a surgir y todo el equipo tenga solucionado el problema.

Cómo crear una rama hotfix

# Creamos una rama hotfix desde la rama principal main
$ git switch -c hotfix-2.5.1 main
Switched to a new branch "hotfix-2.5.1"

# Hacer bump de la versión es opcional y depende

$ ./bump-version.sh 2 .5.1
Files modified successfully, version bumped to 2 .5.1.

$ git commit -am "Bump version to 2.5.1"
[hotfix-2.5.1 32c1aff] Bump version to 2 .5.1
1 files changed, 1 insertions(+), 1 deletions(-)

# Hacemos el commit con el arreglo del problema
$ git commit -m "Fix bug causing app not working properly"
[hotfix-2.5.1 44c2aff] Fix bug causing app not working properly
3 files changed, 24 insertions(+), 16 deletions(-)

# Fusionamos la rama hotfix con la rama main
$ git switch main
Switched to a new branch "main"

$ git merge --no-ff hotfix-2.5.1
Merge made by recursive.

# También fusionamos el hotfix a la rama develop

$ git switch develop
Switched to branch 'develop'

$ git merge --no-ff hotfix-2.5.1
Merge made by recursive.

# Ya podemos eliminar la rama
$ git branch -d hotfix-2.5.1
Deleted branch hotfix-2.5.1(was 44c2aff).

¡Ojo! A veces es posible que ya tengas preparada una rama derelease. Si es el caso y la falta de parche endevelopno está bloqueando a ningún equipo, en lugar de fusionar el parche a la ramadeveloplo haremos directamente en la misma rama de releaseque haya creada, ya que esa misma rama será integrada endevelop.

Resumen de ramas hotfix:

*Se crean desde:main
*Se fusionan endevelop(orelease) y main
*Convención de nombre:hotfix-

Algunas notas sobre Git Flow

Git Flow es, y sigue siendo, una estrategia muy popular. No hay ninguna duda que hace 10 años aportaba orden y control a la hora de trabajar en equipo y, aún hoy, sigue contando con algunas ventajas importantes. Es especialmente interesante para productos fuertemente versionados o para equipos que necesitan una estrategia de trabajo muy estable y con reglas muy claras e identificadas.

Sin embargo, el propioVincent Driesen(el creador de Git Flow) añadió en 2020 una nota respecto a Git Flow: el desarrollo del software ha evolucionado y, seguramente, no siempre Git Flow es la mejor opción. Por ejemplo, en la creación de web apps, GitFlowañadecomplejidadinnecesariaya que no es necesario mantener múltiples versiones y normalmente no se hace un rollback a través de Git.

Al final hay que tener en cuenta que cada proyecto y cada equipo tiene su propia estrategia de trabajo y, por lo tanto,Git Flow no es una solución universal.

GitHub Flow

GitHubFlowes una estrategia creada por la propiaGitHuby pensada especialmente para equipos y proyectos que hacen despliegues de forma regular. Se basa en la creación dePull Requestsque serán discutidas para que se integren en la rama principal que siempre está actualizada con los cambios más recientes y preparada para ser desplegada.

GitHub Flow es una alternativa más simple de Git Flow. Tiene menos liturgias, es más fácil de entender y favorece los despliegues continuos de tu proyecto

Esta estrategia es muy utilizada especialmente en proyectos de código abierto ya que es una estrategia que elimina liturgias y simplifica la contribución de personas ajenas a la organización.

¿Qué es un Pull Request? Una Pull Request, o abreviadoPR, es una petición de cambios que se envía a través de una rama de GitHub. Lo que se pide es que los cambios que presenta la rama sean incorporados a otra rama (que normalmente es la rama principal pero no necesariamente tiene que ser siempre así).

GitHub Flow tiene dos tipos de ramas:

main (o master ): La rama principal que contiene los cambios que se despliegan regularmente. - Cualquier otra rama que quiere ser integrada en la rama principal.

Para trabajar de esta forma, primero creamos una rama desde la rama principal main:

# creamos una rama desde la rama principal main
$ git switch -c feature-new-cool-thing main

Luego añadimos todos los commits que consideremos importantes para la rama
feature-new-cool-thing:

# añadimos un par de commits a nuestra rama
$ git commit -am "Add new cool thing"
[feature-new-cool-thing fb8f8f9]Add new cool thing

1 file changed, 1 insertion(+), 1 deletion(-)

$ git commit -am "Add cool thing to the README"
[feature-new-cool-thing fb8f8f9]Add cool thing to the README

1 file changed, 1 insertion(+), 1 deletion(-)

# sincronizamos esta rama al repositorio remoto con alias origin
$ git push origin feature-new-cool-thing
Total 0 (delta 0 ), reused 0 (delta 0 ), pack-reused 0
remote:
remote: Create a pull request for 'feature-new-cool-thing 'on GitHub by
visiting:
remote: https://github.com/tu-usuario/your-repo/pull/new/feature-new-
cool-thing
remote:
To github.com:tu-usuario/your-repo.git
* [new branch] feature-new-cool-thing -> feature-new-cool-thing

Ahora podemos acceder a GitHub y crear una nueva petición de cambios para integrar la ramafeature-new-cool-thinga la rama principal:

Si entramos al repositorio, podemos ver que GitHub ahora muestra una notificación que nos invita a realizar una Pull Request de esta rama.

Si hacemos clic en el botón“Compare & pull request”nos abrirá la pantalla para crear una Pull Request, donde debemos seguir los pasos indicados.

El paso 1 es la rama de destino, en este caso la rama principal “master”. El paso 2 es la rama que queremos fusionar. La 3 y la 4 nos deja dar más contexto sobre los cambios que queremos añadir. Finalmente el botón creará la Pull Request

Si tienes acceso de colaboración al repositorio, podrás crear directamente una Pull Request como hemos visto. Si no, deberás crear un fork como hemos visto en capítulos anteriores, para poder realizar una Pull Request desde tu fork.

Después de todo estose iniciará una discusión por parte de la organización, las personas que colaboran en el proyecto y la comunidad respecto a los cambios que quieres incorporar. En ocasiones es posible que pidan (o exijan) que se añadan más cambios a la ramafeature-new-cool-thingantes de que se pueda integrar a la rama principal.

Revisa la sección deBuenas prácticaspara ver cómo puedes crear mejores PRs que sean más fáciles de ser aceptadas.

También es posible que exista algún proceso de revisión automatizada. A eso se le llama Continuous Integration (CI) y puede contener una serie de pruebas para verificar que el código funciona, es correcto y sigue los estándares de la organización. En ocasiones, incluso, se despliegan los cambios de la rama a una dirección para que todas las personas implicadas puedan ver los cambios funcionando.

En este repositorio, por ejemplo, se despliega automáticamente cada Pull Request con el servicio de Vercel y se ofrece en un comentario una dirección para visitar la web. ¡Muy útil!

Una vez la revisión haya sido un éxito y las comprobaciones han pasado, alguien con suficientes permisos podrá aceptar integrar los cambios en la rama principal. A veces incluso el botón de “Fusionar” se activa después de pasar algunas comprobaciones y puedes hacerlo tú mismo.

Una cosa más. Aunque hemos visto todos los pasos como si estuvieramos usando GitHub como servidor donde hospedar el repositorio remoto, esta estrategia es compatible con GitLab, Bitbucket y otras alternativas.

Trunk Based Development

ElTrunk Based Development²⁶es una estrategia que se basa en que el mayor tiempo de desarrollo se concentra en una sola rama llamada trunk(tronco) que normalmente corresponderá con main(o master). Esto quiere decir que se evita la creación de ramas auxiliares y, sólo en algunos casos que se requieran, se crean con un tiempo de vida muy limitado (máximo un par de días).

Por raro que parezca, esta estrategia es la más antigua de todas las que hemos visto. Considera que, antiguamente, los equipos de desarrollo no contaban con las posibilidades de controles de versiones modernos y distribuidos, que facilitaban la creación de ramas que se mantenían actualizadas y que se pudieran integrar en otras ramas.

Enestaestrategiasepriorizahacercommitsdirectamentealaramaprincipal. Enelcasodenecesitar ramas, sehacenPullRequestpequeñasyquedurenpocotiempoparaserintegradasloantesposible

^²⁶ https://trunkbaseddevelopment.com/

En el caso de los equipos pequeños, la idea es que los commits a la rama principal sean constantes gracias a programar en pares o en grupo

Así que esta estrategia la podríamos resumir en:haz commit a main y hazlo lo más frecuentemente posible con pequeños cambios. Y crea PRs pequeñas y rápidas sólo cuando sea necesario.

¿Qué puede salir mal? Pues menos de lo que esperas si cuentas con un buen sistema deIntegración y Despliegue Continuo(CI/CD). De hecho, aunque puedes pensar que esta estrategia sólo tendría sentido para un proyecto muy pequeño, en realidad suele ocurrir casi lo contrario. Grandes empresas, comoGoogleyFacebook, usan esta estrategia en un monorepositorio de miles de líneas de código.

Un monorepositorio no deja de ser un repositorio pero que contiene más de un proyecto o paquete publicable dentro. Tiene bastantes ventajas respecto a experiencia de desarrollo pero es un reto a la hora de crear una integración rápida.

¿Y cómo es posible que puedan hacerlo? Porquesatisfacen todas las consideraciones a tener en cuenta para poder usarTrunk Based Developmenten tu organizacióncon garantías:

Necesitas contar con un sistema deIntegración Continua (CI)que permita verificar que el código funciona (testsútiles y con buena cobertura), es correcto

y sigue los estándares de la organización (lint). De esta forma se automatiza gran parte del trabajo manual. 2. El equipo trabaja usando técnicas como la programación a pares (pair programming) o la programación en grupo (mob programming), quepermiten que los miembrosdeunequipotrabajenenconjuntocon otros miembros (del mismo u otro equipo) para resolver un problema.

Existe la falsa creencia que hacer Pair Programming hace que el equipo vaya más lento. Se ha demostrado que estas prácticas hace que la aplicación tenga menos errores, el conocimiento se comparta más fácilmente y tareas complicadas sean más factibles

Se deben hacer commits constantemente, para que los cambios sean más fáciles de integrar. Cambios pequeños y frecuentes. 4. Existen redes de seguridad automatizadas quedeshacenunpaseaproducción en el caso que algo haya salido mal. Por ejemplo, un sistema que analiza las métricas de conversiones de una tienda online que, si detecta que hay una desviación demasiado fuerte y negativa, devuelve la aplicación a una versión anterior (rollback automatizado). 5. Cada día es lo mismo para un desarrollador. O, dicho de otro modo, no hay “días de despliegue”o“días de no-despliegue”(como en el caso de los viernes). No haycode freezeque valga. No hay distracciones, la ramatrunksiempre está disponible y siempre se puede desplegar.

En definitiva, esta estrategia requiere que la organización sea responsable y madurapara evitar conflictos entre personas y errores en la aplicación.

“Las ramas crean distancia entre desarrolladores y nosotros no queremos
eso” (Frank Compagner de Guerrilla Games)

Beneficios de Trunk Based Development

Vamos a revisar algunos beneficios que trae seguir la estrategia deTrunk Based Developmenten tu organización o equipo:

Integración continua y menos fricción

La rama principal recibe constantemente un flujo de cambios pequeños. En lugar de estar trabajando en un pequeño silo durante largos períodos de tiempo y formarte una burbuja donde “todo funciona”, estohace que constantemente tu trabajo local esté sincronizado con el remotoy, además, tu trabajo estéconstantemente siendovalidadoporlostestsautomatizadosy cobertura de código de la integración continua.

En las estrategias que se basan en ramas, la fusión de las ramas que llevan mucho en el proyecto suele traer problemas ya que se han alejado demasiado tiempo de la principal.

Menos trabajo manual

En lugar de crear muchas ramas y con gran cantidad de código, que luego deben ser revisadas por otros colegas del equipo, la estrategia deTrunk Based Development confía en la automatización continua y en la colaboración entre el equipo de desarrollomientras se trabaja en esas nuevas características.

En el caso que una Pull Request sea necesaria, se debe hacer corta y concisa, de forma que revisarla de forma manual sea algo rápido y sencillo. Incluso útil para, simplemente, recibir feedback.

Despliegue a producción continuo

En lugar de tener días o momentos especiales para hacer despliegue a producción, la rama principal llega constantemente al usuario final siempre que el sistema de integración continua haya pasado todas sus revisiones correctamente.

La idea es mantener siempre la rama principalenverde. Esto quiere decir que la rama principal siempre tiene que tener todos los tests pasando, cumpliendo una cobertura de código y con todas las revisiones correctas.

La idea es hacer múltiples despliegues diarios a producción que incorporan cambios pequeños, incluso cambios que todavía no son visibles porque se encuentran detrás de unFeature Toggle. De esta forma, esas nuevas funcionalidades se pueden activar bajo demanda, para un pequeño grupo de usuarios, y desplegarlo al resto de usuarios de forma progresiva y controlada si no hay ningún problema.

Para realizarFeature TogglesyProgressive Delivery Experimentationtienes herramientas comoOptimizely,SplitoLaunch Darkly. También puedes hacerlo manualmente, aunque, dependiendo de lo que busques y las analíticas que quieras controlar, vas a tener que montar tu propia plataforma y esto puede ser costoso de crear y mantener. https://www.optimizely.com/

Ship / Show / Ask

Ship / Show / Askes una estrategia de ramas que combina la idea de crear Pull Request con la habilidad de seguir publicando cambios rápidamente. Fuepresentada por Rousan Wilsenach en el blog del mítico Martin Fowler²⁷.

Los cambios que creamos en el repositorio se categorizan en tres:

Ship: Se fusiona en la rama principal sin revisión - Show: Abre una petición de cambios para que sean revisados por CI pero se fusiona inmediatamente - Ask: Abre una PR para discutir los cambios antes de fusionarlos

Las tres posibles categorías que pueden tener tus cambios son los que dan nombre a la estrategia. ²⁷https://martinfowler.com/articles/ship-show-ask.html

Ship

Shipsignifica que vamos a hacer un cambiodirectamente a la rama principal. No esperamos revisiones de código, ni integración. Vamosdirectos a producción (aunque antes del despliegue sí se harán los tests o checks pertinentes para evitar errores)

El commit va directamente a producción, sin pasar por Pull Request

Pensado para:

He añadido una nueva funcionalidad con un patrón establecido.
He arreglado de forma sencilla un bug por un error.
Actualizaciones de documentación.
Mejora de código porfeedbackdel equipo o la comunidad.
Se añaden nuevostestspara evitar errores.

Show

En este caso sí usamosPull Requestpero no esperamos revisiones manuales del código. Es decir, esperamos que los tests automatizados, pruebas de cobertura y validación de código sean exitosospero no que otra persona revise el código.

En Show creamos Pull Request para validar que las pruebas automáticas pasan pero no esperamos opiniones de otras personas del equipo

Estonoquieredecirquenoocurranconversacionessobreelcódigo. La diferencia es que ocurrirán después de hacer la fusion de los cambios.

La idea es que el trabajo fluya hacia adelante, con el menor número de bloqueos, pero que sigan existiendo espacios dónde se pueda hablar y discutir sobre cómo mejorar las prácticas de desarrollo y el código que se crea.

El equipo es notificado que se creó una Pull Request, la revisan posteriormente y después se hacen las observaciones que sean necesarias. Lo interesante es que hace que esa PR queda fácilmente identificable y separada.

LasPull Requestmuchas veces se usan como una forma deforzar laconversación dentrodelequipoycompartirconocimiento. A veces, puede ser buena idea. Pero nunca deben ser una sustitucióna buenas dinámicas de trabajo en equipo y usar programación a pares o en grupo.

Pensado para:

Hacer arreglos necesarios para bugs y dejar constancia para que se aprenda.
Crear pequeñas mejoras de código orefactors.
Añadir nuevas funcionalidades siguiendo estructuras ya acordadas.
Funcionalidades con pruebas automáticas.

Ask

Esta categoría es similar aShowpero aquísí esperamos al feedback de nuestro equipoante de fusionar la rama. Lo hacemos porque existe algo de incertidumbre: bien porque la solución es complicada, no sabemos implementarla, existen dudas…

La idea es que la rama dure el mínimo tiempo posible para no bloquear el trabajo de otros miembros del equipo

Con Ask sí esperamos que el equipo revise la Pull Request. No esperamos aprobación, esperamos conversación para eliminar la incertidumbre.

Una cosa importante a destacar es que decidir usar la categoría deAskno quiere decir que esperemos la aprobación de nuestros colegas. Estamos abriendo una vía de conversación y debate antes de fusionar la rama ya que existe algún bloqueo o duda, pero es posible que no estemos buscando una revisión general de los cambios (si es así, deberíamos indicarlo).

Pensado para:

Cuando es un trabajo muy grande y se necesita ayuda.
Hay dudas sobre cómo hacerlo funcionar o la calidad del código.
Existe incertidumbre sobre lo que estamos haciendo.
Estamos esperando a que algo ocurra para poder fusionar la rama.

Las reglas de Ship / Show / Ask

Obviamente, poder llegar a seguir algunas de las categorías requiere algunas reglas.

Tenemos un buen sistema deCI/CD, fiable y rápido, que hace que la rama principal siempre sea desplegable y que evite que lleguen errores no deseados a producción. 2. Confiamos en el equipo y existen buenas prácticas de desarrollo. Pair programming, mob programming, seniority… y, sobretodo, existe responsabilidad. La persona se responsabiliza de decidir la categoría de su cambio. Un gran poder, poder hacermergede tus propias Pull Request, conlleva una gran responsabilidad (no romper producción). 3. Las revisiones de código no son requerimientos para que las PRs sean fusionadas. 4. Las ramas son lo más pequeñas posibles, tienen un tiempo de vida corto y siempre salen directamente desde la rama principal. 5. El equipo ha sabido lidiar con el ego individual, las personas confían en el resto del equipo y las pruebas automáticas pasan. El equipo entiende que la rama principal puede contener código sin terminar detrás deFeature Flagsu otros mecanismos similares.

Últimas palabras sobre _Ship / Show / Ask_

Creo que la idea detrás de esta estrategia, en realidad, es la deresponsabilizar a cada persona con su trabajo, empoderar al equipo, darle autonomía y tratar a la gente que lo integra por igual.

También está que el desarrollo seamás rápidoy la entrega sea más continua, pero para poder lograrlo se va a necesitar mucha confianza. Algo que, seguramente, no todos los equipos estén preparados de inicio.

En cualquier caso creo queShip / Show / Askpodría ser una mezcla de estrategias que ya hemos visto anteriormente… simplemente deja la puerta abierta a que cada persona decida por sí misma cuál es la mejor categoría para cada cambio y le pone nombre.

Conclusiones sobre las estrategias de flujos de trabajo en Git

En este capítulo hemos visto algunas de las estrategias más famosas para trabajar con ramas y en equipo con Git. Son opciones muy interesantes pero, por favor, no adoptes ninguna sin análisis previo y, sobretodo, ten en cuenta que las estrategias no son mantras inalterables.

La estrategia que sigamos tiene que responder a laentrega de valor continua, la experiencia de desarrolloy lacalidad del softwareque entregamos.

En mi empresa seguimos GitHub Flow. Nos ha ayudado a realizar despliegues a producción de una forma mucho más continua y ha simplificado tanto la estrategia que hay poco que explicar.

En nuestro caso tiene todo el sentido ya que trabajamos con aplicaciones web, que no requieren de un versionado estricto y, en caso de problema, retroceder a una versión anterior es muy fácil (cambiamos el contenedor de Docker por uno anterior y listo).

En el caso del desarrollo de otro tipo de software, como un videojuego, puede tener más sentido usar una estrategia de versionado más estricto comoGitFlow. No quiere decir que no funcione otra o que tu equipo deba seguir esa… de hecho, los creadores de Killzone y Horizon Zero Dawn usanTrunk Based Development²⁸.

Lo que quiero decirte con esto es queno hay una bala de plata. Cada equipo, cada desarrollo, cada proyecto… son circunstancias diferentes que, seguro, hay que lidiar de forma distinta.

¿A qué deberíamos aspirar?

Si me preguntas a qué deberíamos aspirar como profesionales que trabajan en un proyecto de software, en equipo y ejercen la ingeniería… Creo quela aspiración es hacer commits en la rama principal continuamente evitando la creación de ramas auxiliares.

Esto sería aproximarse al máximo lo que hacemos enTrunk Based Developmento lo que proponeShip/Show/Ask. Con las adaptaciones, según el equipo y el proyecto, que se requieran.

^²⁸ https://dzone.com/articles/presenting-trunk-based

Obviamente, este tipo de estrategia requiere una buena disciplina, seniority, responsabilidad individual y de equipo, un buen sistema deCI/CDtanto en fiabilidad como velocidad y, por supuesto, unbuen trabajo en equipo.

No es algo que se puede hacer de un día para otropero creo que se pueden ir adoptando pequeñas mejoras en el equipo para poder aspirar a ello.

Primero, limitar la vida de las ramas que se crean. Evitar ramas que duren más de dos o tres días.

Segundo, construirunmejorsistemadeCI/CD.¿Tienes tests automatizados? ¿Qué cobertura tienes? ¿No lo sabes? Empieza por ahí. Construye las bases de una mejor estrategia a través de sacar datos objetivos del punto en el que te encuentras. ¿Cuanto tiempo tardas en conseguir que un commit que se crea llegue a producción? Su viaje debe ser lo más corto posible. Descubre en qué puntos se bloquea. ¿Es por revisión manual? ¿Hay conflictos?

Tercero. Una vez tengas mejoras en integración continua, abre la puerta a hacer commits a la rama principal cuando trabajes en equipo. Empezad a hacer alguna pequeña tarea en grupos de tres o más personas o, como mínimo, a pares.

Y, así, pequeñas mejoras incrementalesen el equipo, en tu repositorio y, claro, la organización. Hasta llegar a una nueva estrategia más eficiente para tus desarrollos.

No intentes cambiar de estrategia de trabajo en equipo de golpe. Adopta el método kaizen. Esta filosofía japonesa defiende que cambiospequeños continuados dan mejores resultadosy tiene más probabilidades de éxito que un único cambio grande.