Branch en Git

Hemos dicho anteriormente que Git compara los archivos presentes en la working copy con respecto al commit de la que se extrajeron para comprender en qué estado se encuentran. Sin embargo, con mayor frecuencia oiremos (y comenzaremos a decir también) que cualquier cambio en la working copy es con respecto al branch en el que estoy trabajando.

Tratemos de aclarar esto:

Sabemos que un commit es para Git un snapshot de los contenidos del repository en un momento dado. Sabemos que cada commit tiene una referencia al commit que lo precedió. De esta forma, la secuencia de commits conectados entre sí nos permite conocer y reconstruir toda la historia del proyecto.

Supongamos que hemos realizado un proyecto hasta el lanzamiento de su versión 1.0. Estamos listos para trabajar en nuevas funciones fantásticas en vista de la versión 2.0 en unos meses, pero, mientras tanto, es posible que tengamos que hacer algunos lanzamientos de "arreglos" de la versión 1 (1.1, 1.2, ...). Cómo Git puede hacernos la vida más fácil.

Fig - Commit en el branch main hasta la versión 1.0

Cuando creamos un repository con git init en nuestro proyecto, Git también ha creado un branch de default (cuyo nombre suele ser main o master).

A medida que hemos guardado los diversos snapshot, nos ha parecido que hemos "agregado" nuevas confirmaciones a este branch, como si el branch main estuviera formado por la secuencia de commits.

En realidad, un branch en Git es un puntero a un commit específico, un puntero con un superpoder: cuando se realiza un nuevo commit, el puntero se mueve desde el commit anterior al último.

En nuestro ejemplo, podríamos crear un nuevo branch que apunte al commit con la que marcamos la versión 1.0 (ten en cuenta que varios branch pueden apuntar a la misma commit) para versiones de mantenimiento 1.x

Fig - Nuevo branch apunta al mismo commit

Dado que cada branch apunta a un commit (este commit se indica como “tip” o “head” del propio branch) y, dado que Git conoce el commit y el branch del que se extrajo el contenido actual del working copy, cuándo que se agrega un commit, este se convierte en el nuevo "head" del branch.

En la práctica, en nuestro proyecto de ejemplo, podríamos tener dos commit "secundarios" del mismo commit que marca la versión 1.0, cada uno en sus respectivos branchs, creando dos historias separadas.
 

Fig - Dos branch, dos history

Lo importante, por tanto, es tener siempre clara la distinción entre lo que hacemos en la práctica con Git ("extraer un branch en la working copy" o "ver el historial de un branch" o "ver los cambios del último commit" ) y lo que Git hace internamente ("extraer en la working copy el commit (snapshot) que es el HEAD de un branch" o "comenzar desde HEAD de un branch y reconstruir todos los commits principales" o "mostrar la diferencia entre el último commit (snapshot) y su principal (snapshot)").

Es importante tener en cuenta que Git no prescribe cómo usar los branch, por lo que depende de los equipos elegir si aprovechar los branch para sus propias necesidades y cómo hacerlo. Con el tiempo se han ido impulsando y definiendo algunas "estrategias de branch" más habituales, basadas en el uso de branch y en la posibilidad que ofrece Git de "mover" commits de un branch a otro.

Fig - Feature branch