Esto es git [episodio 1]: conceptos básicos [parte 4]

29 de septiembre de 2016
2 min. de lectura

Continuamos con el desarrollo de la serie “Esto es Git” para entregarles esta vez 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). 

Ramas

Para empezar a definir el término, se debe tener claro que en GIT todo (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. 

Crear una rama 

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).

“Pararse” en una rama 

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:

Luego de ejecutar el comando anterior, el repositorio se verá así: 

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í: 


Merge 

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: 

Fast forward merge 

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: 

 Three way merge 

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.

Te puede interesar

Otros artículos de Desarrollo de software

Suscríbete