Ramas y fusión en Git

Las ramas permiten llevar varias líneas de trabajo en paralelo dentro de un mismo proyecto sin que se estorben entre sí. En este artículo verá qué son las ramas y para qué sirven, y aprenderá a crearlas, a cambiar de una a otra, a fusionar cambios y a resolver con calma los conflictos de fusión con las herramientas del IDE. Es justo la base que necesita para entender qué hace Claude Code cuando trabaja con su repositorio en una rama aparte.

Los ejemplos y las capturas de la interfaz corresponden a los IDE de JetBrains; los nombres y la ubicación de las acciones pueden variar en su versión. Para los ejercicios, use un repositorio de práctica aparte. En un proyecto de trabajo, siga sus reglas de ramas, commits y envío de cambios.

Qué son las ramas y para qué sirven

Una rama da nombre a una línea de commits independiente. Crear una rama no copia la carpeta del proyecto ni guarda los archivos sin commit. En una carpeta de trabajo normal, al cambiar de rama Git modifica los archivos según la rama elegida; los cambios sin terminar pueden acompañarle a la otra rama o impedir que cambie de rama.

De la rama principal main sale una nueva rama feature/new-idea para una línea de desarrollo aparte. Cuando se termina el trabajo, se fusiona de vuelta en main.

Imagine que quiere rehacer a fondo algo de su proyecto o hacer un experimento arriesgado. ¿Qué haría sin Git? Lo más probable es que copiara todo el proyecto a una carpeta nueva y trabajara allí. Si el resultado le gustara, lo pasaría a la carpeta principal. Si no, simplemente borraría la copia.

La analogía de la copia ayuda a entender que hay variantes de trabajo separadas, pero técnicamente una rama es un puntero a un commit. Veámoslo con el ejemplo de un libro:

1. tiene un manuscrito terminado (es su rama principal main);
2. quiere escribir un final alternativo (crea una rama nueva, por ejemplo feature/new-idea);
3. escribe el nuevo final sin tocar el texto principal del manuscrito (trabaja en la rama nueva);
4. si el nuevo final resulta mejor, sustituye con él el anterior (fusiona las ramas con merge);
5. el borrador viejo con el final que ya no sirve se puede eliminar (elimina la rama).

Crear una rama nueva y trabajar en ella

Paso 1. Abra el menú de gestión de ramas.

En la barra de herramientas principal, junto al nombre del proyecto, hay un widget que muestra el nombre de la rama actual (por defecto, main). Haga clic en él y elija + New Branch.

Paso 2. Nombre de la rama nueva.

Una buena práctica es nombrar las ramas según la tarea que está resolviendo. Por ejemplo, feature/add-usage-examples.

Si al crearla está marcado Checkout branch, el IDE cambiará a la rama nueva. Compruebe su nombre en el widget antes de editar archivos.

Paso 3. Haga los cambios y el commit.

Añada a README.md una sección con ejemplos de uso. Revise los cambios y haga el commit como de costumbre: en el historial de la rama nueva aparecerá una instantánea guardada.

Cambiar entre ramas

Sus cambios con los ejemplos de uso ya están guardados a salvo en la rama feature/add-usage-examples. Volvamos a la rama principal main y veamos qué hay allí.

Paso 1. Vuelva a hacer clic en el widget con el nombre de la rama actual, en la esquina superior izquierda.

Paso 2. En la lista Local o Recent, elija la rama main y, en el submenú que aparece, pulse Checkout.

Paso 3. Compruebe el resultado.

En cuanto haya cambiado de rama, abra el archivo README.md. Verá que la sección con ejemplos de uso no está: se quedó en la otra rama. Así puede trabajar en una funcionalidad nueva sin tocar la versión estable de la rama main.

Fusionar ramas

merge combina el historial de la rama elegida con el de la actual. Si main no ha avanzado desde que se creó la rama, es posible un fast-forward: main se moverá a C3 sin un commit nuevo. Si las líneas se han separado, la fusión normal crea un commit con dos padres.

En el caso lineal que se muestra, main puede moverse a C3. La rama feature/add-usage-examples por ahora también apunta a C3; no hace falta eliminar su nombre para fusionar.

Bien, ha terminado su tarea en la rama feature/add-usage-examples y quiere llevar esos cambios al proyecto principal.

Paso 1. Cambie a la rama de destino.

Asegúrese de estar en la rama A LA QUE quiere añadir los cambios. En nuestro caso es main.

Paso 2. Haga la fusión.

Vuelva a hacer clic en el widget de gestión de ramas. En la lista, elija la rama DE LA QUE quiere tomar los cambios (feature/add-usage-examples) y, en el submenú, elija Merge 'feature/add-usage-examples' into 'main'.

Paso 3. Compruebe el resultado.

Ahora el archivo README.md de la rama main tiene su nueva sección con ejemplos. Ha combinado con éxito su trabajo con la versión principal del proyecto.

Conflictos al fusionar

Un conflicto significa que Git no ha podido combinar los cambios automáticamente. El caso más habitual son cambios distintos en las mismas líneas; también ocurre cuando un archivo se elimina en una rama y se modifica en otra. La solución se elige según lo que deba quedar en el resultado.

Y aquí es donde se nota todo el potencial de las herramientas integradas de su IDE (CLion o IntelliJ IDEA). Resolver conflictos en la terminal no es precisamente un placer, pero la herramienta integrada de fusión a tres bandas (3-way merge) convierte esta tarea en un proceso visual y sencillo.

Las dos ramas han recibido commits a partir del ancestro común C1. Que el historial se separe no garantiza por sí solo un conflicto: este aparece cuando Git no puede combinar los cambios automáticamente. En el ejercicio de abajo, dos textos distintos sustituyen una misma línea original.

Provoquemos un conflicto:

1. asegúrese de estar en la rama main y de no tener cambios sin commit ni archivos nuevos en la ventana Commit;
2. cree una rama nueva feature/new-title, pero no cambie a ella todavía. Compruebe que la casilla Checkout branch está desmarcada;
3. ahora, estando en la rama main, cambie la primera línea de README.md por "My Awesome Project" y haga un commit;
4. cambie a la rama feature/new-title. Verá que aquí la primera línea de README.md sigue siendo la antigua: es el estado del archivo en el momento de crear la rama. Cambie esa misma línea por "My Super Project" y haga un commit;
5. vuelva a la rama main y fusione en ella feature/new-title.

Ahora Git verá que los dos historiales han cambiado el mismo sitio. Le mostrará una ventana para resolver el conflicto (Merge Conflicts).

Pulse el botón Merge para abrir la herramienta de resolución de conflictos. Esto es lo que verá:

• a la izquierda (Your changes), la versión del archivo de su rama actual (en la que fusiona, main);
• a la derecha (Changes from branch), la versión del archivo de la rama que está fusionando;
• en el centro (Result), la versión final del archivo, que usted debe montar a mano.

Puede pulsar las flechas >> o << (o las cruces para descartar) para aceptar entera una u otra variante. También puede escribir directamente el texto correcto en el panel central.

Revise el resultado en el panel central y pulse Apply o el botón de finalización correspondiente. Después mire el estado de Git: si la fusión todavía no está registrada, haga el commit desde el IDE. Resolver las líneas en conflicto y terminar el merge son pasos distintos. Compruebe cómo se comporta el código resultante.

Por qué a veces no hay conflicto

Si en el ejercicio no aparece el conflicto, compruebe desde qué commit se creó la segunda rama y si de verdad los dos lados sustituyeron la misma línea de forma distinta. Git sabe combinar automáticamente cambios compatibles incluso en ramas que se han separado. Otra opción es un historial lineal, en el que puede darse un fast-forward:

Ejemplo:

1. tiene un commit cualquiera en main (digamos, C1);
2. hace un commit nuevo en la rama main con el texto "My Awesome Project". La rama main ahora apunta al commit C2;
3. crea la rama feature/new-title desde la posición actual de main: la rama nueva también empieza en el commit C2;
4. hace un commit en feature/new-title con el texto "My Super Project". Esta rama avanza y apunta al commit C3;
5. vuelve a main (que sigue en el commit C2) y fusiona feature/new-title.

Git ve que la rama main es un ancestro directo de la rama feature/new-title: en el historial de main no hubo commits nuevos mientras usted trabajaba en la otra rama. Por eso simplemente adelanta el puntero de main hasta el commit C3, sin conflictos.

El historial de main continúa con el de feature/new-title sin separarse, así que Git simplemente adelanta main, y no hay conflicto.

Ver el historial de cambios

Para entender mejor lo que pasa en su proyecto, conviene mirar su historial.

Abra la ventana de herramientas Git (suele ser un icono en la barra lateral izquierda o en la parte inferior de la ventana del IDE) y elija la pestaña Log o Show Git Log en la barra de herramientas de Git. Verá una representación gráfica de todas sus ramas y commits. Así se ve claramente qué rama salió de cuál y dónde se fusionaron.

Aquí puede hacer clic en cualquier commit para ver qué cambios incluye, quién lo hizo y cuándo. Es una auténtica máquina del tiempo para su código.

Cómo funciona esto junto con Claude Code

Ahora que entiende las ramas, le resultará más fácil leer lo que hace Claude Code cuando trabaja con su repositorio. Esto es lo que hace por usted con esta tecnología y en qué conviene fijarse:

• crea una rama aparte si así lo prevén la tarea y las reglas del proyecto;
• propone un commit en los puntos clave: usted lee el diff y decide si lo acepta o lo corrige;
• ayuda a encontrar el commit guardado que necesita y a elegir cómo volver a él, teniendo en cuenta los cambios sin commit;
• ante un conflicto de fusión puede pedirle ayuda, y se resuelve con la misma herramienta del IDE;
• sabe preparar y comentar un pull request (PR, una propuesta para integrar una rama en la principal, por ejemplo a través de GitHub CLI).

Artículo anterior: El trabajo diario con Git · Artículo siguiente: Pull request, de la creación a la fusión