Cada vez que releo el artículo
"Git team workflows: merge or rebase?", me dan ganas de olvidarme de hacer "merge" de tipo "non fast forward" y tirar por el camino de "rebase". Especialmente ahora que he leído uno de los artículos ahí mencionados, llamado
"A Rebase Workflow for Git".
Ahora mismo estoy trabajando exclusivamente yo, en un único repositorio local. Y supongo que por eso se me hace fácil, cómodo y hasta bonito usar "merge" de tipo "non fast forward". Porque se ven los "commit" en los que distintas ramas confluyen. Pero estaba pensando que si algún día tuviese que volcar el trabajo en un repositorio remoto en el que trabaja más gente y tuviera que hacer "pull" y "push" constantemente, el grafo del historial se volvería una auténtica locura.
Por otro lado, usar "rebase" permite solucionar los posibles conflictos en tu propia rama privada. Si metes la pata en la resolución de ese conflicto, sabes que te cargas sólo esa rama, sin alterar la rama de destino, que seguramente sea pública (siempre y cuando no hayas fusionado todavía, claro). No es un asunto menor, la verdad.
Por último, he estado pensando en qué información aportan los mensajes de los "commit" generados por "merge" de tipo "non fast forward" y me doy cuenta de que, aparte del típico mensaje redundante "Merges the branch A into B.", poco más aportan. Si necesitase añadir alguna referencia externa, como puede ser la versión de lanzamiento que se crea tras fusionar una rama de desarrollo con una de producción, pienso que bastaría con usar el comando "git tag" y escribir algo como "version-1.0". Supongo que para eso fue creado precisamente.
Así que creo que voy a probar a hacer eso, a usar un flujo de trabajo lineal. A ver qué tal me va. Espero no arrepentirme :) .
PD: Por cierto, que las fusiones que llamo "non fast forward" casi siempre son del tipo "3-way merge". Lo comento por si alguien quiere buscar más información al respecto (a mí me vino bien usar Wikipedia para eso). Me hubiese gustado usar términos en español para hacer mis mensajes más legibles. Pero creo que hubiese causado más confusión al que está acostumbrado a la terminología de los programas de control de revisiones.