Ramificación y fusión básicas de Git/Sourcetree

Alerta de pregunta de novato!!! Estoy empezando a usar Git, y particularmente Sourcetree, que parece una buena aplicación para visualizarlo. En mi primera prueba funcionó bastante bien, ramificándose y fusionándose (vea el diagrama superior). Sé que esta estructura significa que estoy usando la rama maestra y de desarrollo al revés, pero está bien porque al menos funcionó.

Sin embargo, en mi segundo intento, no pude visualizar ninguna rama, a pesar de que se estaba trabajando en ambas, parece que aparecen en una sola rama (con una nota ‘7 adelante’), y cuando intento fusionar nada parece suceder. Esperemos que la segunda captura de pantalla sea suficiente para que alguien me diga qué está pasando aquí. Si no, intentaré dar más información.

Solo estoy jugando en este momento, así que sigo familiarizándome con el flujo de trabajo adecuado, solo tratando de que las acciones básicas de bifurcación y fusión se lleven a cabo de manera consistente a través de Sourcetree. Cualquier ayuda será apreciada.

En la segunda foto hay ramas. En el local tienes 2 sucursales, Maestro & desarrollar. Sin embargo, ambas ramas descansan en el mismo compromiso. Si desea ‘ver sucursales’ como en la primera imagen, puede hacer una confirmación en desarrollar, sin embargo, el gráfico seguirá pareciendo lineal. Usted será capaz de unir desarrollar dentro Maestro en ese momento si quieres.

Si desea ver el gráfico divergir, intente poner un compromiso en Maestro también. Entonces comenzarás a ver algo más como la primera imagen.

Para tener una idea de cómo funciona git con un programa de visualización como este, le sugiero que realice acciones como las que sugerí anteriormente y observe el gráfico en cada paso intermedio.

Están pasando algunas cosas aquí. En primer lugar, es útil comprender que las ramas en Git son en realidad solo “etiquetas” que se adhieren a una confirmación en particular, y que se moverán automáticamente cuando confirme la rama; Git creará la nueva confirmación, con un nuevo hash de confirmación, y actualizará la rama/etiqueta para apuntar a la nueva confirmación. (Entonces, podría preguntarse, ¿en qué se diferencia esto de las etiquetas? Una etiqueta está pegada a la misma confirmación y no recibirá actualizaciones cuando llame a git commit).

Cuando creas una nueva rama, todo lo que sucede es que Git crea una nueva etiqueta que apunta a la misma confirmación en la que estabas. Solo cuando crea una nueva confirmación mientras esta nueva rama está desprotegida, verá que la nueva rama diverge de la otra rama.

La verdadera confusión comienza cuando comienzas a fusionar ramas nuevamente, y esto se debe en gran parte a una cosa extraña que Git llama “fusión de avance rápido”, lo cual hace por defecto. Tomemos su segundo ejemplo e imaginemos que su maestro y desarrollo están donde originalmente estaban origin/master y origin/develop:

Cuando le pide a Git que fusione una rama con otra, Git irá y descubrirá qué debe hacer para obtener la diferencia entre esas ramas en la rama de destino. Supongamos que desea fusionar los cambios que realizó para desarrollar en maestro, por lo que le dice a git:

$ git checkout master
$ git merge develop

Git mirará las ramas y verá que el desarrollo está justo por delante del maestro por unas pocas confirmaciones, pero no hay nada más complicado que eso. Por lo tanto, hará una fusión de “avance rápido”, simplemente tomando la etiqueta maestra y pegándola al compromiso donde apunta el desarrollo. Misión cumplida, cambios que antes solo estaban en desarrollo ahora también están en master.

Si cada rama tiene compromisos adicionales, como en su primer ejemplo justo antes de fusionar el maestro en el desarrollo, “algo más complicado” es pasando Hiciste una confirmación en master, luego hiciste un desarrollo de git checkout, hiciste una confirmación allí y después le pidió a Git que volviera a fusionar el maestro en el desarrollo. Git ahora ya no puede “hacer trampa” simplemente moviendo las etiquetas de rama. Tendrá que descubrir cómo unificar los cambios de las dos ramas en un solo estado de los archivos bajo su control (supongamos, por ahora, que siempre puede hacer eso, lo cual no está tan lejos de la verdad; su bastante bueno en eso. Si no puede, tiene un conflicto de fusión, que en realidad no es tan malo como parece).

El nuevo contenido, después de la fusión, no será ni el último estado de la primera rama, ni será el estado de la segunda rama. Por lo tanto, debe representarse con un nuevo compromiso, que es lo que ve en la parte superior de su primer ejemplo; Git creó lo que llama una “confirmación de fusión” para representar el nuevo estado con los cambios de cada rama fusionados en un solo estado.

Por último, puede obligar a Git a crear siempre una confirmación de fusión, aunque técnicamente no es estrictamente necesario. En la línea de comando, puede hacer esto con la bandera –no-ff, para no avanzar rápidamente. Los clientes gráficos tendrán una casilla de verificación que logrará lo mismo (en SourceTree, actualmente está etiquetada como “Crear una confirmación incluso si la combinación se resuelve mediante avance rápido”). Muchos (incluyéndome a mí) en realidad recomiendan simplemente fusionarse con –no-ff, porque de esa manera el acto de fusionarse siempre se registra en el historial, independientemente de tecnicismos como si sería técnicamente posible simplemente mover los punteros de rama.

Acabo de encontrarme con este mismo problema y descubrí que hay una configuración en SourceTree para “No avanzar rápidamente al fusionar, siempre crear confirmación”. Asegúrese de que esté marcado y verá la estructura de la rama a partir de ellos.

Esta configuración se encuentra en la pestaña Git en preferencias.

Puede evitar que las ramas desaparezcan en el Árbol de origen de forma permanente habilitando “No avance rápido al fusionar, siempre cree una confirmación” en Opciones de herramientas.

Si desea decidir para cada operación de fusión, hay una opción “Cree una nueva confirmación incluso si es posible el avance rápido” en el cuadro de diálogo Fusionar.

También sugiero consultar la respuesta de Eelke Blok para los detalles técnicos.