Hace unos meses publiqué una de las entradas con más éxito de visitas. En ella hablaba acerca de distintas estrategias de branching, sin embargo hay aspectos de buenas prácticas DevOps de las que no hablé y creo necesario explicar. Ese es el motivo de esta entrada, profundizar en las opciones de merging.
Para ello, lo primero que voy a hacer es, desde un proyecto previo, crearé una nueva rama desde develop. Su nombre feature/123456-merge y en ella realizaré un par de modificaciones, con el propósito de realizar una Pull Request sobre develop, eligiendo la opción de merge (not fast forward), veamos.
En el momento de realizar la PR, vemos que, efectivamente existen dos nuevos commits y que la Branch sobre la que voy a realizar el merge es develop. Pulsamos sobre crear.
El propio Azure DevOps comprueba que no existen conflictos entre las ramas a mergear y desde la parte derecha, en el desplegable, seleccionamos el tipo de merge que vamos a realizar. En este primer ejemplo, será Merge (no fast forward). Justo debajo existe un conjunto de opciones que permiten:
- Pasar al completado el ítem del sprint backlog en caso de que le hubiéramos asociado alguno previamente. No es el caso, sin embargo es muy útil en un proyecto real, puesto que permite hacer un mejor seguimiento.
- Borrar la rama con la que vas a realizar el merge. También es útil puesto que permite limpiar el repositorio.
- El último set, permite customizar el mensaje que se envía tras el resultado de la Pull Request.
En nuestro ejemplo, tan sólo seleccionaremos la opción de borrado de la Branch de feature.
Una vez completada la Pull Request, podemos observar que nuestra rama de feature ya no está. Lógico, decidimos eliminarla al completarse la PR y cuando seleccionamos la rama develop (sobre la que hemos realizado la PR) y vamos a la sección de commits vemos lo siguiente.
Esta estrategia nos permite realizar un control exhaustivo de todos los commits realizados por los desarrolladores. Es decir, muestra una foto clara y nítida, llena de detalles.
Ahora vamos a ver el comportamiento del segundo tipo de merge, el Squash Commit. Para ello, volvemos a crear una rema feature desde nuestra develop, realizaremos dos cambios sobre los ficheros y acto seguido realizaremos una PR sobre develop, seleccionando ese tipo de merge. Veamos.
En este caso, vemos que aún habiendo realizado dos commits, tras el merge sólo aparece un único nodo. Esto se debe a que el squash commit no mantiene el detalle de cada commit, se limita a agrupar todos los cambios y dibujar un único nodo como continuación del proceso de desarrollo. Es útil en casos en los que se ha utilizado la rama para un «arreglo» como podría ser un Hotfix.
A continuación, replicaremos el mismo proceso y revisaremos la salida, en este caso usaremos el tipo de merge llamado Rebase.
Tras un par de problemillas pude completar la PR número 8 con dos commits utilizando el tipo de merge de Rebase que viene a ser similar a Squash, es decir usa un modo de nodos lineales, si bien, mantiene el detalle de los commits realizados.
Llegados hasta aquí, sólo nos quedaría el último tipo de merge, Semi Linear.
En este caso, se trata de una especie de combinación de rebase y merge, donde primero se ejecuta un rebase sobre los commits de la feature que se fusionan sobre la rama develop, siempre y cuando, el proceso de rebase haya sido completado con éxito. La ventaja es que se mantiene el detalle de cada commit, lo que permite su seguimiento y en caso de existir múltiples ramas de features, el resultado final es mucho más sencillo de seguir.
Personalmente, el tipo de merge que utilizo en casi todos los proyectos es el primero, Merge (no fast forward). Sin embargo, conocer el resultado visual del gráfico de nodos de los commits realizados en una rama, mediante cada uno de los tipos de merge, permite disponer de una mejor idea acerca los beneficios de uno u otro enfoque. Me ha parecido interesante el caso de Semi Linear, y me gustaría profundizar y ver cómo se comporta trabajando con múltiples ramas features que mergeen sobre develop. Seguro que en unos días monto un caso detallado de él.
Alb3rto Alonso 
3 comentarios sobre “Azure DevOps y sus tipos de merge”