Git · 04

Ramas: trabajar en paralelo sin romper nada

Una rama te deja probar una idea o desarrollar una función nueva aparte de la versión principal. Cuando está lista, la unís; si no sirvió, la borrás. Es la forma normal de trabajar con Git, aunque estés solo.

Términos de esta página

Las bases (commit, HEAD) están en Conceptos.

Rama (branch)
Un marcador con nombre que apunta a un commit y avanza solo cuando hacés commits nuevos estando en ella.
main
La rama principal por convención: la versión “buena” del proyecto.
Rama de función
Una rama corta para una sola tarea (feature branch), por ejemplo agrega-login. Se une a main y se borra.
Merge
Unir los commits de una rama dentro de otra.
Fast-forward
Un merge en el que la rama destino solo “avanza” hasta la otra, porque no tenía commits propios. No crea commit nuevo.
Commit de merge
Un commit especial con dos padres que se crea cuando las dos ramas avanzaron por separado.
Conflicto
Cuando las dos ramas cambiaron las mismas líneas de un archivo y Git no puede decidir solo cuál dejar. Te pide que elijas vos.
Rebase
Mover tus commits para que queden encima de otra rama, como si hubieras empezado desde ahí. Deja un historial en línea recta.
switch / checkout
Cambiar de rama. git switch es el comando moderno; git checkout es el viejo y hace muchas cosas más (por eso confunde).
1

Qué es una rama

Una rama no es una copia de los archivos: es solo un nombre que apunta a un commit. Por eso crearla es instantáneo. Cuando cambiás de rama, Git reemplaza los archivos de tu carpeta por los de esa rama. Cuando volvés, vuelven los otros.

En el dibujo, main siguió con el commit C mientras en nueva-ruta se hicieron D y E. Las dos líneas comparten A y B, y cada una tiene lo suyo. HEAD marca en cuál estás (acá, en nueva-ruta).

A B C D E main nueva-ruta HEAD el tiempo avanza hacia la derecha →
2

Crear, cambiar y borrar ramas

Crear y cambiar

git switch -c nueva-ruta
Crea la rama nueva-ruta a partir del commit actual y se cambia a ella (-c = create). Es lo que vas a usar casi siempre.
git switch main
Cambia a una rama que ya existe. Los archivos de la carpeta pasan a ser los de esa rama.
git switch -
Vuelve a la rama en la que estabas antes del último cambio, como el botón “atrás” del navegador. Repetirlo te lleva de nuevo a la otra: sirve para ir y venir entre dos ramas.
i

En tutoriales viejos vas a ver git checkout -b nueva-ruta y git checkout main: hacen lo mismo.

Ver, renombrar y borrar

git branch
Lista las ramas que tenés en tu PC; la actual está marcada con *. Con -v muestra además el último commit de cada una.
git branch -a
Incluye las ramas del remoto que Git conoce desde el último fetch; aparecen como remotes/origin/nombre. Para trabajar en una de ellas, git switch nombre crea la rama local conectada.
git branch -m nombre-nuevo
Cambia el nombre de la rama en la que estás (-m = move). Si ya la habías subido, en GitHub sigue con el nombre viejo: subí la nueva con git push -u origin nombre-nuevo y borrá la vieja allá.
git branch -d nueva-ruta
Borra una rama que ya se unió. Si tiene commits sin unir, Git se niega para protegerte; -D la borra igual (se pierden esos commits).
git push origin --delete nueva-ruta
Borra la rama en GitHub (en el remoto origin). git branch -d solo borra la copia de tu PC; para quitarla de los dos lados, hacen falta los dos comandos.
!

Cambios sin commitear al cambiar de rama: si tus cambios no chocan con la otra rama, viajan con vos. Si chocan, Git no te deja cambiar (“Your local changes would be overwritten”). Commiteá primero o guardalos con git stash.

3

Unir ramas (merge)

Para traer el trabajo de nueva-ruta a main: te parás en la rama que recibe los cambios y le decís qué rama unir.

git switch main
git pull
git merge nueva-ruta
1) Ir a la rama destino. 2) Traer lo último del remoto. 3) Unir nueva-ruta dentro de main.
git push
git branch -d nueva-ruta
git push sube a GitHub el main con la rama ya unida. Después, git branch -d borra la rama local: sus commits ya forman parte de main, así que no se pierde nada.

Qué podés ver al hacer merge

  • “Fast-forward”: main no tenía commits nuevos; solo avanzó. Listo.
  • Se abre el editor con “Merge branch 'nueva-ruta'”: las dos ramas avanzaron y Git crea un commit de merge. Guardá y cerrá el editor para aceptar el mensaje.
  • “CONFLICT”: las dos ramas cambiaron las mismas líneas. Seguí la sección siguiente.
Fast-forward main no tenía commits nuevos: solo avanza A B D E main (antes) main (después) Merge con commit las dos ramas avanzaron: se crea M con dos padres A B C D E M main
4

Resolver un conflicto, paso a paso

No es un error grave: Git solo necesita que decidas qué versión queda.

1. Qué ves

Auto-merging app.js
CONFLICT (content): Merge conflict in app.js
Automatic merge failed; fix conflicts and then commit the result.

Git unió todo lo que pudo y dejó marcadas, dentro del archivo, las partes en conflicto:

<<<<<<< HEAD
const PORT = 3000;
=======
const PORT = process.env.PORT ?? 8080;
>>>>>>> nueva-ruta
  • Entre <<<<<<< HEAD y =======: lo que tenía tu rama actual (main).
  • Entre ======= y >>>>>>> nueva-ruta: lo que traía la otra rama.

2. Cómo resolverlo

  1. Corré git status: los archivos en conflicto aparecen como both modified.
  2. Abrí cada archivo y dejá el código como tiene que quedar: una de las dos versiones, las dos o una mezcla. Borrá las tres líneas de marcas (<<<, ===, >>>).
  3. En VS Code aparecen botones arriba del conflicto: Accept Current (lo tuyo), Accept Incoming (lo de la otra rama), Accept Both (ambos).
  4. Marcá cada archivo como resuelto: git add app.js.
  5. Terminá el merge: git commit (Git propone el mensaje; guardá y cerrá el editor).
git merge --abort
¿Te arrepentiste? Cancela el merge y deja todo como estaba antes de empezar.
✓

Para tener menos conflictos: ramas cortas, git pull seguido y commits chicos.

5

Rebase: la alternativa al merge

rebase toma los commits de tu rama y los “vuelve a aplicar” encima del último commit de otra. El resultado es el mismo código, pero el historial queda en línea recta, sin commits de merge. Los commits movidos son commits nuevos (cambia su hash): D y E pasan a ser D′ y E′.

Antes A B C D E main mi-rama rebase main Después A B C D′ E′ main mi-rama 
git switch mi-rama
git rebase main
Pone tus commits de mi-rama encima de lo último de main. Si hay conflictos, se resuelven como en un merge, pero se continúa con git rebase --continue (o se cancela con git rebase --abort).
git pull --rebase
Trae lo del remoto y pone tus commits locales encima, en vez de crear un commit de merge.

La regla de oro

✕

No hagas rebase de commits que ya subiste a una rama que usan otras personas. Como el rebase crea commits nuevos, los demás tendrían un historial distinto al tuyo y se arma un lío.

Si tenés dudas, usá merge: siempre es seguro. El rebase es una preferencia de prolijidad, no una obligación.

6

Un flujo de trabajo con ramas

El que usan la mayoría de los equipos (y que conviene usar solo también).

  1. Partí de main actualizado: git switch main y git pull.
  2. Creá una rama por tarea: git switch -c agrega-health.
  3. Trabajá y commiteá en esa rama todas las veces que quieras.
  4. Subila: git push -u origin agrega-health (la primera vez con -u).
  5. En GitHub, abrí un Pull Request de agrega-health hacia main para revisar los cambios (ver GitHub y remotos).
  6. Cuando está aprobado, se hace el merge en GitHub (botón Merge pull request).
  7. En tu PC: git switch main, git pull y git branch -d agrega-health.
i

Con este flujo, main siempre tiene código que funciona, y si algo sale mal en una rama no afecta a nadie más. Además, si conectaste el repo a Netlify, cada merge a main publica el sitio solo.

No encontré resultados.