Esta vez hablaremos de conceptos relacionados con una parte fundamental en el uso de Git y demás sistemas de versionamiento distribuidos o centralizados: ¡las ramas!
En el capítulo anterior se hizo énfasis en el concepto de repositorio remoto, repositorio local y la relación entre ambos (pull/push).
Para empezar a definir el término, se debe tener claro que en Git o casi todo es representado como punteros. Sí, así es, los viejos y conocidos punteros.
Una rama entonces es un puntero que hace referencia a un “snapshot” del repositorio (commit).
Este es un ejemplo breve de un repositorio con sólo este historial de commits (los grises) con un puntero (el amarillo) a uno de ellos:
El puntero es llamado máster (rama creada por defecto en los repositorios de GIT) y está apuntando al commit a98s2s, con lo que podemos concluir que la rama máster está representada por un puntero.
Para crear una rama se ejecuta el siguiente comando:
Si en este punto del historial de commits se creara una nueva rama, se vería de la siguiente forma, en donde la nueva rama (puntero) creada con el nombre Develop está apuntando al mismo commit que la rama Máster:
Hay que mencionar un tipo de puntero especial llamado HEAD, el cual le indica a GIT en qué rama estamos “parados” actualmente.
Posterior a la creación de la rama, el repositorio se ve así:
Con el comando git branch Develop le estamos pidiendo a GIT que cree una rama con nombre Develop, a partir de la rama actual (sí, como deben haber imaginado, el puntero HEAD debió estar apuntando a la rama Máster antes de la creación de la rama Develop).
Para que GIT se “pare” en la rama que se acabó de crear (es decir, que el puntero HEAD apunte a la rama), se debe ejecutar el siguiente comando:
Cuando el puntero HEAD está apuntando a una rama (o en otras palabras, cuando estemos “parados” en esta rama), los commits que se realicen actualizarán tanto el puntero de la rama actual (en este caso la Develop) como el puntero HEAD. ¡GIT es bastante listo!
Luego de haber realizado cambios en nuestro working copy, de adicionarlos al staging area y hacer un commit, el repositorio debe verse así:
Uno de los aspectos más importantes del uso de ramas en GIT es la posibilidad de hacer merge entre ellas. Para hacer un merge entre dos ramas, se debe ejecutar el siguiente comando:
Vamos a hacer merge desde la rama Develop a la rama Máster. Para esto, se ejecuta el siguiente comando:
Cuando se hace Merge entre dos ramas, se pueden presentar dos casos:
Cuando la rama origen (la rama sobre la que estamos “parados”) tiene un camino lineal hasta la rama destino, es decir, la rama Máster no tiene un historial de commits propios después de haber creado la rama destino, GIT ejecuta el merge como fast forward:
Cuando la rama origen diverge de la rama destino, es decir, en Máster se han agregado más commits después de haber creado la rama Develop, al intentar hacer un merge, GIT se ve obligado a usar el algoritmo de three way merge para crear un commit adicional que una el historial de la rama origen, el historial de la rama destino y el commit ancestro de ambas.
Luego de realizar el merge, el historial debe verse así:
En la siguiente imagen se pueden ver los commits (en color rojo) que componen el siguiente commit three way merge (en color verde):
Hasta aquí el episodio actual en el que se han visto conceptos relacionados con las ramas en GIT y algo de Merge entre ellas.
Lee el especial completo: