Una Branch (rama) es un mecanismo que permite tener vías de desarrollo independientes dentro del mismo proyecto.
Uno de los requisitos fundamentales en cualquier proyecto es la capacidad de trabajar en diferentes tareas de forma paralela. Por ejemplo, añadir una nueva funcionalidad, arreglar un error, probar una idea.
Necesitamos un mecanismo para aislar estos cambios, sin interferir con el código principal. En Git, esta herramienta son las Ramas.
En esta entrada analizaremos cómo Git gestiona estas bifurcaciones por debajo. Entenderemos qué son, y cómo funcionan internamente.
Entendiendo el Commit
Para entender cómo funcionan las ramas, recordemos que un commit es una instantánea inmutable de tu proyecto en un determinado momento.
Pero además, guarda el identificador de su padre, lo que permite “formar una cadeneta” (técnicamente, formar un grafo).
¿Qué es una rama?
Técnicamente, una rama en Git es un archivo de texto diminuto (40 bytes) que contiene el Hash de un commit. Nada más.
Piensa en una rama como un Post-it con un nombre, que pegas encima de un commit específico.
Cuando decimos que “estamos en la rama main”, lo único que significa es que hay un puntero llamado main apuntando al último commit que hemos hecho.
Si creamos una rama nueva llamada testing, lo único que hace Git es crear una nueva etiqueta y pegarla en el mismo commit donde estás ahora. No copia archivos.
No duplica código. Solo crea un puntero. Por eso es una operación inmediata.
En otros sitemas de versiones antiguos, crear una rama implicaba hacer una copia física de todos los archivos del proyecto en otra carpeta. Era lento y pesado.
Git gestiona las ramas de forma diferente. Aquí crear una rama es instantáneo. Tarda lo mismo si tu proyecto tiene 3 archivos o si tiene 300.000.
Por este motivo, no le tengáis miedo o pereza a crear Ramas. En Git las ramas se usan para todo.
El puntero HEAD: “¿Dónde estoy?”
El HEAD es un puntero especial y muy importante que indica a Git tu ubicación actual. Es el “Usted está aquí” del grafo de Git 📌.
Imagina que tienes dos ramas (main y testing) ¿Cómo sabe Git en cuál de las dos estás trabajando tú? ¿Cómo sabe que si haces un commit nuevo, debe avanzar una rama y no la otra?
Para eso existe un puntero HEAD. Normalmente, el HEAD no apunta a un commit directamente, si no que apunta a una Rama.
Esto le dice a Git: “El usuario está trabajando actualmente sobre la rama Main, que a su vez apunta al commit C”.
El movimiento de los punteros
Lo genial de este sistema es lo sencillo y eficiente que es. La gracia ocurre con el movimiento de los punteros, cuando hacemos un nuevo commit.
Imagina que estamos en main (HEAD apunta a main). Hacemos cambios, git add y finalmente git commit.
Git crea el nuevo commit D. Su padre será C.
Como HEAD apuntaba a main, Git sabe “estás en main”. Asi que tiene que mover la etiqueta main para al nuevo commit D.
HEAD sigue apuntando a main, así que no hay que hacer ningun cambio en HEAD (sigue a main).
Es decir, la rama main ha “avanzando” automáticamente. Las ramas en Git avanzan hacia adelante con los commit.
Tú no “metes código en la rama”, tú creas commits y la rama (la etiqueta) se mueve para seguirte.
Toma aire, y no te agobies si alguna parte de ha parecido dificil. Explicar las bases de las ramas no es algo que se entienda a la primera.
Sigue viendo los siguientes artículos, y cuando tengas dudas vuelve a este para repasar la teoría. Poco a poco lo acabarás viendo sencillo.
