Experimentos seguros: trabajo con ramas

1. ¿Qué son las ramas y para qué sirven?

El trabajo con branches en Git es uno de los aspectos clave del control de versiones, que permite llevar en paralelo varias líneas de desarrollo en un mismo repositorio. La ramificación hace de Git una herramienta potente para la colaboración, los experimentos y la gestión de distintas versiones del proyecto.

            gitGraph
            commit id: "Initial setup"
            commit id: "Add base features"
            branch feature/new-idea
            checkout feature/new-idea
            commit id: "Implement new logic"
            commit id: "Refactor the logic"
            checkout main
            commit id: "Urgent bugfix on main"
            merge feature/new-idea
            commit id: "Prepare for release"
        

Imagina que quieres rehacer algo de forma importante en tu proyecto o realizar un experimento arriesgado. ¿Qué harías sin Git? Probablemente copiarías todo el proyecto a una carpeta nueva y trabajarías allí. Si el resultado te gusta, lo moverías a la carpeta principal. Si no, simplemente borrarías la copia.

Las ramas en Git funcionan según el mismo principio, pero de forma mucho más elegante. Veámoslo con el ejemplo de escribir un libro:

1. Tienes un manuscrito terminado (esta es tu rama principal main).
2. Quieres escribir un final alternativo (creas una nueva rama, por ejemplo feature/new-idea).
3. Escribes el nuevo final sin tocar el texto principal del manuscrito (trabajas en la nueva rama).
4. Si el nuevo final resulta mejor, sustituyes el antiguo por este (haces una fusión de ramas — merge).
5. El borrador antiguo con el final innecesario puede eliminarse (eliminas la rama).

2. Creación de una nueva rama y trabajo en ella

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

En la barra superior de la IDE hay un widget que muestra el nombre de la rama actual (por defecto — main). Haz clic en él y elige + New Branch.

Paso 2. Nombre de la nueva rama.

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

Tras crear la rama, la IDE cambiará a ella automáticamente. Verás el nuevo nombre en ese mismo widget.

Paso 3. Realiza y confirma los cambios.

Ahora estás en tu «zona de pruebas». Vamos a añadir a nuestro archivo README.md una sección nueva con ejemplos de uso. Realiza los cambios y haz un commit, como aprendiste en la lección anterior.

3. Cambiar entre ramas

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

Paso 1. Vuelve a hacer clic en el widget con el nombre de la rama actual.

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

Paso 3. Comprueba el resultado.

En cuanto cambies, abre el archivo README.md. ¡Verás que la sección con ejemplos de uso no está! Se quedó en la otra rama. De este modo, puedes trabajar en nuevas funcionalidades sin tocar la versión estable en la rama main.

4. Fusión de ramas (Merge)

La orden merge toma todos los commits de la rama feature/add-examples (en este caso, el commit C3) y los combina con la rama actual main, creando un nuevo commit de fusión.

            gitGraph
            commit id: "C1"
            commit id: "C2"
            branch feature/add-examples
            checkout feature/add-examples
            commit id: "C3: Add new section"
            checkout main
            merge feature/add-examples
        

Así que has terminado tu tarea en la rama feature/add-usage-examples y quieres añadir estos cambios al proyecto principal.

Paso 1. Cambia a la rama de destino.

Asegúrate de que estás en la rama A DÓNDE quieres añadir los cambios. En nuestro caso, es main.

Paso 2. Ejecuta la fusión.

Vuelve a hacer clic en el widget de gestión de ramas. En la lista, elige la rama DE DÓNDE quieres tomar los cambios (feature/add-usage-examples), y en el submenú selecciona Merge feature/add-usage-examples en main.

Paso 3. Comprueba el resultado.

Ahora en el archivo README.md en la rama main ha aparecido tu nueva sección con ejemplos. ¡Has unido con éxito tu trabajo a la versión principal del proyecto!

5. Conflictos al fusionar: ¡no te preocupes, es normal!

En ocasiones, al fusionar ramas surgen conflictos. Esto ocurre cuando en ambas ramas se han modificado las mismas líneas en el mismo archivo. Git no puede decidir por sí mismo qué versión es la correcta y pide tu ayuda.

            gitGraph
            commit id: "C1: Base común"
            branch feature/new-title
            checkout main
            commit id: "C2: Cambio en main"
            checkout feature/new-title
            commit id: "C3: Cambio en feature"
        

Simulemos un conflicto:

1. Asegúrate de que estás en la rama main y de que no tienes cambios sin guardar.
2. Crea inmediatamente una nueva rama feature/new-title, pero no cambies a ella todavía. Asegúrate de que la casilla Checkout branch esté desmarcada.
3. Ahora, estando en la rama main, cambia la primera línea en README.md a "My Awesome Project" y haz un commit.
4. Cámbiate a la rama feature/new-title. Verás que la primera línea en README.md aquí sigue siendo la antigua: es el estado del archivo en el momento de crear la rama. Cambia esta misma línea a "My Super Project" y haz un commit.
5. Vuelve a la rama main y realiza la fusión con feature/new-title.

Ahora Git verá que ambas ramas tienen nuevas historias divergentes desde su ancestro común. En ambas historias se ha cambiado la misma línea, por lo que Git no podrá elegir qué versión es correcta y te mostrará una ventana para resolver el conflicto.

Merge Revision

Qué ves aquí:

• A la izquierda (Your changes): la versión del archivo de tu rama actual (main).
• A la derecha (Changes from branch...): la versión del archivo de la rama que estás fusionando.
• En el centro (Result): la versión final del archivo que debes construir.

Puedes pulsar en las flechas >> o << para aceptar por completo una u otra opción.

Cuando el resultado en el panel central te satisfaga, pulsa Apply. La IDE creará el commit de fusión automáticamente y el conflicto quedará resuelto.

¿Por qué no hubo conflicto?

Puede darse la situación de que hayas realizado todos los pasos y, aun así, no haya habido conflicto. Lo más habitual es que Git haya podido realizar un fast-forward merge, ya que la historia de una rama simplemente continuó la de la otra. Para garantizar el conflicto, las historias de las ramas deben divergir en direcciones distintas desde el ancestro común.

Ejemplo:

1. Tienes un commit en main (digamos, C1).
2. Haces un nuevo commit en main con el texto "My Awesome Project". La rama main ahora apunta al commit C2 (main -> C1 -> C2).
3. Creas la rama feature/new-title desde la posición actual de la rama main. Esto significa que la nueva rama también empieza en el commit C2.
4. Haces un commit en feature/new-title con el texto "My Super Project". Esta rama «avanza» y ahora apunta al commit C3 (feature/new-title -> C1 -> C2 -> C3).
5. Vuelves a main (que sigue en el commit C2) y das la orden de fusionar feature/new-title.

Git mira la situación y ve que la rama main es el antecesor directo de la rama feature/new-title. En la historia de main no hubo commits nuevos mientras trabajabas en la otra rama. Git piensa: «Ah, aquí solo hay que adelantar main hasta el commit C3. No hay contradicciones». Y simplemente mueve el puntero de main al commit C3.

            gitGraph
            commit id: "C1"
            commit id: "C2"
            branch feature/new-title
            checkout feature/new-title
            commit id: "C3"
            checkout main
            merge feature/new-title
        

6. Visualización del historial de cambios

Para entender mejor lo que ocurre en tu proyecto, es útil mirar su historia.

Abre la pestaña Git en la parte inferior de la IDE y elige Log. Verás una representación gráfica de todas tus ramas y commits. Esto te ayudará a seguir de forma visual qué rama se separó de cuál y dónde se fusionaron.

Allí puedes hacer clic en cualquier commit para ver qué cambios contiene, quién lo hizo y cuándo. ¡Es una auténtica máquina del tiempo para el código!