[SOLUCIONADO] Qué método elegir para fusionar 2 ramas ("merge").

[Negora]

Hola:

Estoy empezando a usar GIT y he visto que hay mucho debate sobre dos métodos distintos para fusionar ramas, los cuales dan lugar a dos flujos de trabajo bien distintos.

El primero de ellos consiste en hacer un "rebase" de la rama a fusionar contra la rama de destino, y luego hacer un "merge" de tipo "fast forward" (visto en guías como las de Atlassian). Da lugar a un flujo más lineal.

El segundo de ellos consiste en hacer un "merge" evitando que sea de tipo "fast forward", con la opción "--no-ff". Da lugar a un flujo de ramas.

Tras leer las ventajas e inconvenientes de cada uno en infinidad de artículos, sigo sin decidirme por un método u otro por defecto. A priori el segundo me gusta más porque mantiene el contexto de las ramas y de cuándo se produjeron las fusiones. Me parece bueno disponer de esa información pero tengo mis dudas de que ésta luego sea útil en la práctica. ¿Qué método usáis vosotros?

Gracias.

[pateketrueke]

Pues yo pienso que es una decisión bastante objetiva.

¿Quieres conservar el historial o no?

Que tan útil es para uno u otro es relativo.

Si te es útil conservar dicho historial ahí tienes.

Así de simple.

[Negora]

Hola Pateketrueke:

Antes de nada, gracias por responder. Mi problema radica en que estoy empezando a usar GIT. Por si fuera poco, además es la primera vez que me estoy usando un sistema de control de versiones. Por eso no sé qué flujo puede ser más útil en un futuro, ya que no he llegado a esa etapa todavía.

Desde un punto de vista informativo, mantener las ramas me parece interesante. Sin embargo, ¿Tiene alguna utilidad práctica más allá de saber qué se fusionó con qué y cuándo? Todavía no he tenido que ir atrás en el historial para buscar cuándo se introdujo un "bug" (no sé usar "bisect" o "blame" todavía). ¿Ayuda en algo tener las ramas o el proceso de búsqueda sería idéntico en un flujo lineal?

Un saludo.

[Negora]

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.

[pateketrueke]

Yo igual prefiero usar rebase siempre que trabajo sólo.

En repositorios compartidos procuro hacer merge como siempre, pues así me evito posibles conflictos que puedan derivar de ir haciendo rebase.

Lo que mencionas de "flujo de trabajo lineal" funcionaría bien incluso usando merge, en teoría, por cada N commits es posible compactarlos en uno sólo facilitando su uso para rebase o merge, etc.

Te digo que hoy en día tampoco sé usar bisect, pero siempre me es útil tener todo el historial, cada pequeño cambio es útil.

[Negora]

Espero poder volver a este hilo dentro de unos meses y decirte que fue un acierto escoger este camino, je je je.

Que conste que me sigue gustando eso de tener "commits" que representen las fusiones que he hecho entre ramas. Pero si uso correctamente las etiquetas, creo que puedo suplir esa carencia con marcadores que dejen testimonio de cuándo se hizo una fusión.