Experimentos seguros: trabajar con ramas

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

Trabajar con branches en Git — es uno de los aspectos clave del control de versiones que permite mantener varias líneas de desarrollo en paralelo dentro de un mismo repositorio. El branching hace de Git una herramienta potente para colaboración, experimentos y 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 importante en tu proyecto o hacer 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 pasarías a la carpeta principal. Si no — simplemente borrarías la copia.

Las ramas en Git funcionan con la misma idea, pero de forma mucho más elegante. Veámoslo con el ejemplo de escribir un libro:

1. Tienes un manuscrito listo (esa 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 (trabajas en la nueva rama).
4. Si el nuevo final resulta mejor, lo sustituyes por el antiguo (haces merge de las ramas — merge).
5. El viejo borrador con el final no deseado se puede borrar (eliminas la rama).

2. Crear una rama nueva y trabajar en ella

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

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

Paso 2. Nombre de la nueva rama.

Buena práctica: nombrar las ramas según la tarea que resuelves. Por ejemplo, feature/add-usage-examples.

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

Paso 3. Haz cambios y haz commit.

Ahora estás en tu "sandbox". Vamos a añadir al archivo README.md una nueva sección con ejemplos de uso. Haz los cambios y realiza el commit, como aprendiste en la clase anterior.

3. Cambiar entre ramas

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

Paso 1. Haz clic de nuevo en el widget con el nombre de la rama actual.

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

Paso 3. Comprueba el resultado.

En cuanto cambies de rama, abre el archivo README.md. Verás que la sección con los ejemplos de uso no está allí. ¡Quedó en la otra rama! Así puedes trabajar en nueva funcionalidad sin tocar la versión estable en main.

4. Fusionar ramas (Merge)

El comando merge toma todos los commits de la rama feature/add-examples (en este caso, el commit C3) y los une con la rama actual main, creando un nuevo commit de merge.

            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
        

Entonces, terminaste el trabajo en tu tarea en la rama feature/add-usage-examples y quieres añadir esos cambios al proyecto principal.

Paso 1. Cámbiate a la rama objetivo.

Asegúrate de estar en la rama a la QUE quieres añadir los cambios. En nuestro caso es main.

Paso 2. Ejecuta el merge.

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

Paso 3. Comprueba el resultado.

Ahora el archivo README.md en la rama main tiene tu nueva sección de ejemplos. ¡Has integrado con éxito tu trabajo con la versión principal del proyecto!

5. Conflictos al fusionar: no te asustes, es normal

A veces al fusionar ramas aparecen conflictos. Ocurre cuando en ambas ramas se han cambiado las mismas líneas en el mismo archivo. Git no puede decidir por sí mismo qué versión es la correcta y te pide ayuda.

            gitGraph
            commit id: "C1: Common base"
            branch feature/new-title
            checkout main
            commit id: "C2: Change in main"
            checkout feature/new-title
            commit id: "C3: Change in feature"
        

Vamos a simular un conflicto:

1. Asegúrate de estar en la rama main y de no tener cambios sin guardar.
2. Inmediatamente crea una nueva rama feature/new-title, pero no te cambies a ella todavía. Asegúrate de que la casilla Checkout branch esté desmarcada.
3. Ahora, estando en main, cambia la primera línea de README.md a "Mi Proyecto Asombroso" y haz commit.
4. Cámbiate a la rama feature/new-title. Verás que la primera línea en README.md sigue siendo la antigua: ese es el estado del archivo en el momento de crear la rama. Cambia esa misma línea a "Mi Super Proyecto" y haz commit.
5. Vuelve a la rama main y haz merge con feature/new-title.

Ahora Git verá que ambas ramas tienen historias divergentes desde su ancestro común. En ambas se cambió la misma línea, así que Git no podrá elegir cuál es la 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 desde tu rama actual (main).
• A la derecha (Changes from branch...): la versión del archivo desde la rama que estás fusionando.
• En el centro (Result): la versión final del archivo que debes armar.

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

Cuando el resultado en el panel central te convenza, haz clic en Apply. El IDE creará automáticamente el commit de merge y el conflicto quedará resuelto.

¿Por qué no apareció conflicto?

Puede ocurrir que sigas todos los pasos y no aparezca conflicto. Lo más habitual es que Git haya podido hacer un fast-forward merge, porque la historia de una rama simplemente continuó la de la otra. Para que haya conflicto garantizado, las historias de las ramas deben divergir en direcciones diferentes desde el ancestro común.

Ejemplo:

1. Tienes un commit en main (p. ej. 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 main. Eso 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. Regresas a main (que sigue en el commit C2) y pides hacer merge de feature/new-title.

Git mira la situación y ve que la rama main es antecesora directa de feature/new-title. En la historia de main no hubo commits nuevos mientras trabajabas en la otra rama. Git piensa: "Ah, solo hay que mover main hacia adelante hasta el commit C3. No hay conflictos". Y simplemente mueve el puntero 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. Ver el historial de cambios

Para entender mejor lo que pasa en tu proyecto, es útil mirar su historial.

Abre la pestaña Git en la parte inferior del IDE y selecciona Log. Verás una representación gráfica de todas tus ramas y commits. Esto ayuda a seguir visualmente de qué rama se separó otra y dónde se fusionaron.

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