Ramas + equipo = desastre… si no nos ponemos de acuerdo con el equipo en una forma de trabajar. Gitflow (puedes ver una chuleta aquí de lo que es) para mí ha resultado en la forma más sencilla de seguir unas normas y no equivocarnos.
A todos nos ha pasado que cuando empezamos a trabajar con Git, resulta muy sencillo ¿verdad?
- inicializo repositorio (o lo clono)
- hago cambios
- añado y hago commit
- subo cambios al repositorio
Pero cuando empezamos a trabajar con ramas se empieza a complicar un poquito… hay toda una ciencia detrás de cómo gestionar las ramas. Pero a nivel individual aún es «sencillo».
¿Qué es Gitflow?
Es un conjunto de extensiones de git (comandos de consola que usan Git y alias de Git) que nos permiten automatizar y simplificar procesos.
Nos da cierta capa de abstracción de las «tripas» de Git, ya que lo usamos como un lenguaje de «alto nivel».
Es decir, en 1 comando de Gitflow englobamos 5 comandos de Git. Esto normalmente da lugar a error ya que 5 comandos se prestan más a producir un olvido en alguno que solo 1 comando.
NOTA: la herramienta Gitflow usa el flujo de trabajo Git Flow
Herramienta de automatización VS el flujo de trabajo
Hemos de distinguir los diferentes «gitflows» que puedan existir (que los hay muchísimos) con el Gitflow al que nos referimos que es una herramienta de Git que por debajo utiliza un flujo de trabajo (un «gitflow») determinado.
El lío viene cuando la herramienta de este post se llama Gitflow y el flujo de trabajo también se llama git flow…
Pero podríamos tener otras herramientas de automatización para Git que utilizaran otros flujos de trabajo.
¿Qué otros flujos de trabajo existen en Git?
- Git Flow (la que utiliza la herramienta de este post)
- GitHub Flow: el que usan los de GitHub
- GitLab Flow: el que usan los de GitLab
- Release Flow: lo usan en Microsoft
- Trunk-Based development
- Master-only Flow
- … etc
Cuando tu equipo es consistente, con experiencia y aplica buenas prácticas, quizás lo más adecuado sea usar Master-only flow 😉
Detractores de Gitflow
Es verdad, que manualmente Git Flow (el flujo de trabajo) añade una carga de tareas impresionante y una cantidad de ramas excesiva… y muchas veces es innecesario.
La mayor pega de esta forma de trabajar, es que manualmente se nos va a olvidar algún paso entre tantas ramas.
Pero para esto entra la herramienta de automatización que veíamos en la chuleta aquí: hace todos los pasos por tí y te «obliga» a seguir el camino indicado por el flujo de trabajo Git flow.
Es entonces cuando se convierte en un fuerte aliado que nos facilita la vida
Ventajas de usarlo
Lo más difícil de Git Flow (el flujo de trabajo) es acordarse de todos los pasos a seguir… lo que hace que aparezcan inconsistencias (ramas muertas, ramas no mergeadas correctamete, ramas mergeadas y no borradas, etc,).
Ejemplo de realizar una nueva feature usando la herramienta Gitflow (sin comandos, hablamos de los pasos):
- Crear feature (nos crea rama desde la rama develop con prefijo «feature/»)
- Modifcaciones de código
- Commits y opcionalmente subir rama
- Finalizar feature
Ejemplo sin la herramienta Gitflow:
- Crear feature y acordarse de nombrarla adecuadamente
- Modifcaciones de código
- Commits y opcionalmente subir rama
- Mergear feature en develop y acordarse de: borrar feature local, borrar feature remota
Esos dos detalle «tonto» que hay que acordarse, llevan a inconsistencias, pero la herramienta lo hace automáticamente por nosotros.
Y cuando queremos sacar una reslease (código a master para llevarlo a producción) es aún más tedioso… mergear develop con master, poner tags, etc, etc. Si ya queremos usar la rama release para staging o y hacer correcciones de última hora, se siguen sumando los pasos y las ramas.
Todo esto lo gestionamos con comandos intuitivos del tipo:
- git flow feature start mifeature / git flow feature finish mifeature
- git flow release start /git flow release finish
Simple e intuitivo, si nos gusta el flujo de trabajo Git Flow claro 🙂