Las ramas son baratas, y esa es su virtud. También es su problema: cuando crear una cuesta cero, se crean muchas, y al cabo de unos meses el repositorio de Ana tiene ramas de funcionalidades ya integradas, ramas de experimentos que nadie recuerda, ramas con nombres como prueba o arreglo2 y alguna que lleva seis semanas sin un solo commit.

Un repositorio con cuarenta ramas de las que solo tres están vivas no es un problema técnico —Git aguanta miles sin despeinarse—, pero sí un problema humano: nadie sabe cuál es cuál, nadie se atreve a borrar nada por miedo a perder trabajo y el autocompletado deja de ser útil.

Esta lección es la caja de herramientas para mantener eso bajo control: listar ramas con la información que necesitas, saber cuáles se pueden borrar sin perder nada, renombrar, borrar con seguridad y ponerles nombres que digan algo. Es la lección menos espectacular del módulo y probablemente la que más veces vas a aplicar.

1. Listar ramas: git branch y sus variantes
2. --merged y --no-merged: qué se puede borrar sin perder nada
3. Listados a medida con --sort y --format
4. Renombrar ramas con -m
5. Borrar ramas: -d frente a -D
6. Cuando el borrado seguro falla
7. Convenciones de nombres
8. Qué nombres admite Git: git check-ref-format
9. Higiene: detectar ramas obsoletas
10. Cierre del módulo

El comando base ya lo conoces:

Diez ramas. El asterisco marca la actual. Ordenadas alfabéticamente, sin más información. Es un punto de partida pobre: no sabes cuáles están integradas, ni cuáles llevan meses paradas.

Ya se puede empezar a razonar. Fíjate en prueba: apunta a 8b6d3c2, un commit antiquísimo del principio del proyecto. Es una rama muerta que se creó y nunca se usó.

Hay una variante doble:

Añade, entre corchetes, la rama de seguimiento de cada una: con qué rama del repositorio remoto está emparejada y cuántos commits lleva por delante o por detrás. Como en este módulo todo ocurre en un único repositorio local, no hay nada que mostrar todavía; -vv cobrará todo su sentido en el módulo 4, cuando el trabajo empiece a viajar entre máquinas.

--contains es especialmente útil para responder a "¿en qué ramas está este arreglo?":

El arreglo del mensaje de lista vacía está en su rama original y en main. En ninguna otra.

Estas dos opciones son el corazón de la higiene de ramas.

El significado exacto, y conviene ser preciso porque genera confusión: --merged lista las ramas cuya punta es alcanzable desde la rama actual. Dicho de otro modo: todos sus commits están ya en el historial de main.

Traducido a la práctica: estas ramas se pueden borrar sin perder ni un solo commit.

Dos casos merecen comentario:

• prueba aparece aquí porque su punta es 8b6d3c2, un commit del principio del proyecto que obviamente está en main. No aportaba nada, y por eso consta como fusionada.
• experimento/almacenamiento-indexeddb también aparece, aunque su código nunca llegó al proyecto: la cerramos en la lección 03-04 con git merge -s ours, que crea el commit de fusión sin traer el contenido. Ese era precisamente el objetivo de aquella estrategia: que la rama dejara de figurar como pendiente.

Y ahora la otra cara:

Estas ramas tienen commits que main no tiene. Borrarlas dejaría esos commits sin ninguna referencia que los alcance. Por qué está cada una:

• documentacion/actualizar-notas: resolvimos su conflicto modify/delete a favor del borrado del fichero, así que su commit nunca llegó a main. Correcto que aparezca aquí.
• funcionalidad/exportar-csv: la integramos con squash. Su contenido está en main, pero sus seis commits originales no. Git dice la verdad: desde el punto de vista del grafo, no está fusionada.

Ese último caso es la trampa más habitual: una rama integrada con squash siempre aparece en --no-merged. Si tu equipo usa squash sistemáticamente, --merged deja de ser un criterio fiable para borrar y hay que llevar la cuenta de otra forma.

Por defecto, las dos opciones comparan contra HEAD. Se puede indicar otra referencia:

Es la forma correcta de usarlas en scripts, porque no depende de dónde estés situado.

Este es el idiom que verás en todas partes y que conviene entender pieza a pieza:

• git branch --merged main: las candidatas.
• grep -v '^\*': quita la línea de la rama actual (la del asterisco).
• grep -v ' main$': quita main de la lista, no vaya a ser que intente borrarse a sí misma.
• xargs -r git branch -d: borra cada una con el borrado seguro (-r evita ejecutar nada si la lista viene vacía).

Antes de ejecutarlo, revisa siempre la lista quitando el último tramo:

Un consejo importante: usa -d y nunca -D en un comando automático como este. -d se niega si algo no cuadra; -D borra sin preguntar.

El orden alfabético no es el más útil. Lo que casi siempre quieres saber es qué ramas están vivas, y eso es una cuestión de fechas.

El guion delante de committerdate significa orden descendente: lo más reciente arriba. Las de abajo son las candidatas a desaparecer.

Campos de ordenación habituales:

Y con --format se construye un listado a medida, usando los mismos marcadores de git for-each-ref:

Esta sí es una vista útil. De un vistazo se ve qué está vivo, quién lo lleva y qué es lo último que se hizo.

Los marcadores más prácticos:

Como es imposible recordar esa línea, se guarda como alias:

Los alias tienen su propia lección en el módulo 6; este es un buen candidato para tu colección.

Bruno abrió hace unos días una rama llamada arreglo2 y ahora nadie sabe qué contiene. Tras mirarla, Ana le pone un nombre que diga algo:

Si quieres renombrar la rama en la que estás, basta con un argumento:

Hay una variante mayúscula, -M, que fuerza el renombrado aunque ya exista una rama con el nombre de destino, sobrescribiéndola. La misma advertencia de siempre: -M puede dejar commits huérfanos sin avisar. Usa -m salvo que sepas exactamente lo que haces.

Nada sorprendente, a estas alturas del módulo:

Renombrar una rama es renombrar el fichero de 41 bytes y, si era la rama actual, actualizar .git/HEAD para que apunte al nombre nuevo. Los commits no se tocan: son inmutables y ni se enteran.

Por eso renombrar es una operación totalmente segura en local. Cuando la rama ya se ha compartido con el equipo la cosa cambia, porque los demás siguen viendo el nombre antiguo; eso pertenece al módulo 4.

El seguro, sobre una rama ya integrada:

Fíjate en que Git te da el hash de donde estaba. No es cortesía: es el dato con el que puedes recrear la rama si te has equivocado (git branch <nombre> 9d1e4b7). Cópialo si tienes la más mínima duda.

Se pueden borrar varias de golpe:

El fichero de 41 bytes. Nada más.

Los commits siguen íntegros en .git/objects/. Lo único que ha desaparecido es el nombre que apuntaba a ellos. Si esos commits siguen siendo alcanzables desde main (que es el caso cuando la rama estaba fusionada), no cambia absolutamente nada en el repositorio.

Este es el motivo por el que borrar una rama fusionada es una operación trivial y sin riesgo, y por el que no hay que tenerle ningún respeto.

No puedes borrar la rama en la que estás:

Y, desde Git 2.5, tampoco puedes borrar una rama que esté activa en otra copia de trabajo (git worktree, lección 06-06). En los dos casos la solución es la misma: git switch a otra rama y repetir.

Qué significa exactamente ese mensaje: la punta de esa rama no es alcanzable desde la rama actual (ni desde su rama de seguimiento, si la tuviera). Es decir, hay commits en ella que no están en ningún otro sitio del grafo.

Y qué NO significa: no significa que el trabajo se haya perdido, ni que el contenido no esté en main. Recuerda el caso del squash: el contenido de funcionalidad/exportacion-csv está íntegro en main en el commit 3b9e7d1, pero sus seis commits originales no. Git razona sobre el grafo, no sobre el contenido.

Antes de forzar, comprueba. Este es el reflejo que hay que adquirir:

Sin diferencias: el contenido es idéntico. Se integró con squash y no se pierde nada. Ahora sí, con conocimiento de causa:

Un borrado con -D no es el fin del mundo, y conviene saberlo para no vivir con miedo. Los commits siguen en la base de datos de objetos, y Git mantiene un registro llamado reflog con todos los movimientos de referencias. Mientras el hash sea recuperable —de ahí que git branch -D lo imprima al borrar— basta con recrear la rama:

Los commits sin ninguna referencia acaban siendo eliminados por el recolector de basura (git gc), pero no de inmediato: el plazo por defecto es de 30 días para objetos inalcanzables y 90 días para las entradas del reflog. Hay margen de sobra.

Todo el procedimiento de rescate —encontrar el hash con git reflog y git fsck --lost-found cuando ya no lo tienes apuntado— se ve en la lección 09-04. Aquí quédate con la idea tranquilizadora: -D casi nunca es irreversible.

Git no impone ninguna estructura en los nombres de rama más allá de unos pocos caracteres prohibidos. Lo que hacen los equipos es adoptar prefijos con barra que agrupan las ramas por propósito, exactamente como hemos venido haciendo en el módulo.

Muchos equipos añaden el identificador de la tarea del gestor de incidencias, que permite ir de la rama a la especificación y viceversa:

Y algunos incluyen el nombre de quien la lleva, útil en equipos grandes:

No es solo estética. La barra permite filtrar:

Y hace que el autocompletado sea utilizable: escribes git switch fun<TAB> y la shell te ofrece solo ese grupo.

También conviene saber por qué la barra tiene un límite: como los nombres se convierten en rutas dentro de .git/refs/heads/, no puede existir a la vez una rama llamada funcionalidad y otra llamada funcionalidad/orden. La primera sería un fichero y la segunda necesitaría que funcionalidad fuese un directorio. Git lo rechaza:

Es un error críptico con una explicación muy simple, y ahora ya la conoces.

• Minúsculas y guiones: funcionalidad/exportar-csv, no Funcionalidad/ExportarCSV. Evita sorpresas entre sistemas de ficheros sensibles y no sensibles a mayúsculas (recuerda que Ana está en Ubuntu, Bruno en macOS y Carla en Windows).
• Sin tildes ni ñ. correccion/, no corrección/. Git los admite, pero acaban en URL, en nombres de fichero y en salidas de herramientas de terceros donde dan problemas.
• Descriptivo pero corto: correccion/foco-tras-anadir, no correccion/arreglar-el-problema-del-foco-que-reporto-el-cliente-el-martes.
• Nada de prueba, temporal, nueva, arreglo2. Dentro de dos semanas no sabrás qué eran, y por eso nadie se atreverá a borrarlas.

Existen metodologías completas que definen qué ramas hay, cómo se llaman, de dónde salen y dónde se integran. Las más conocidas:

• Git Flow: ramas develop, release/*, hotfix/* y feature/* sobre una main que solo contiene versiones publicadas.
• GitHub Flow: una sola rama de larga duración (main) y ramas de trabajo de vida corta que se integran mediante propuestas de cambio.
• Trunk Based Development: todo el mundo integra en el tronco a diario, con ramas de horas y no de días.

Cada una tiene sus supuestos sobre el tamaño del equipo, la frecuencia de publicación y el nivel de automatización. Las estudiaremos en el módulo 7, donde ya tendremos los remotos y las propuestas de cambio para entenderlas de verdad. Por ahora, lo importante: la convención concreta importa menos que el hecho de que todo el equipo siga la misma.

Las reglas están definidas formalmente y se pueden comprobar:

Si el nombre es válido, lo imprime y devuelve 0. Si no:

Las reglas principales, con la razón de cada una:

Un detalle curioso y coherente con todo lo que has aprendido: la mayoría de estas reglas existen porque el nombre de la rama es a la vez una ruta de fichero y una expresión que Git tiene que poder analizar. Prohibir ^ no es capricho: si existiera una rama llamada mi^rama, git log mi^rama sería ambiguo.

Comprobación en un script:

Este tipo de validación es exactamente lo que se automatiza con un hook para impedir que entren nombres que no siguen la convención del equipo. Los hooks son el tema de la lección 06-01.

Reunamos todo en una rutina de mantenimiento. Basta con hacerla una vez al mes.

Paso 1: ver el panorama ordenado por antigüedad.

Sin el guion, el orden es ascendente: lo más viejo arriba, que es lo que quieres cuando buscas candidatos a borrar.

Paso 2: separar las integradas de las que no lo están.

Paso 3: revisar una por una las que no están fusionadas. Para cada una:

Con esos tres datos, la decisión es fácil: si el contenido ya está en main, -D sin miedo; si tiene trabajo real y reciente, se deja; si tiene trabajo real pero de hace meses, se habla con quien la abrió antes de tocar nada.

Paso 4: borrar las integradas.

La mejor gestión de ramas es no necesitarla: si las ramas viven dos o tres días y se borran al integrarlas, el repositorio nunca acumula basura. La limpieza mensual es un parche para un problema que se evita trabajando con ramas cortas.

Es la misma conclusión a la que llegamos con los conflictos en la lección anterior, y no es casualidad: la vida corta de las ramas resuelve a la vez la divergencia, los conflictos y el desorden. Es la idea que sostiene el desarrollo basado en tronco y buena parte del módulo 7.

Recapitulemos lo que hemos construido en estas seis lecciones.

Empezamos con una promesa del módulo 2 —"una rama es un fichero con un hash dentro"— y la cumplimos hasta el byte: 41, exactamente. Vimos que HEAD es otro fichero que apunta a una rama, no a un commit, y que esa indirección es lo que permite que confirmar mueva el puntero correcto. Entendimos por qué las ramas de Git son gratis frente a las de Subversion, y qué significa que dos ramas diverjan desde un ancestro común.

Después las creamos y nos movimos entre ellas con git branch, git switch y git switch -c, entendimos por qué Git separó checkout en dos comandos, qué pasa con los cambios sin confirmar al cambiar de rama y qué es el HEAD desacoplado.

Las volvimos a juntar con git merge, distinguiendo el fast-forward —un puntero que avanza— de la fusión a tres bandas que crea un commit con dos padres, y aprendimos a forzar o prohibir cada comportamiento con --no-ff y --ff-only. Estudiamos las estrategias (ort, resolve, octopus, ours, subtree), las opciones -X, la diferencia crítica entre -s ours y -X ours, y el squash merge.

Resolvimos un conflicto de verdad: los marcadores, el estilo zdiff3 que muestra el ancestro, las tres etapas del índice, git add como forma de decir "resuelto" y git merge --abort como tecla de escape.

Y hemos terminado poniendo orden: listar, filtrar, renombrar, borrar con criterio y nombrar bien.

Y sin embargo, todo lo que hemos hecho en este módulo ha ocurrido dentro de un único portátil. Todas las ramas viven en el .git/ de Ana. Cuando decíamos "Bruno abrió una rama", en realidad estábamos razonando como si su trabajo ya estuviera allí.

En el mundo real no lo está. Ana trabaja en Ubuntu, Bruno en macOS, y sus repositorios son dos bases de datos de objetos completamente independientes que no se conocen entre sí. Los commits de Bruno están en su MacBook y los de Ana en su Ubuntu, y ningún git merge del mundo puede fusionar algo que no está en tu propio .git/objects/.

Faltan las respuestas a preguntas muy concretas:

• ¿Cómo llegan los objetos de un repositorio a otro?
• ¿Dónde vive la copia "oficial" del proyecto?
• ¿Qué es exactamente ese origin/main que apareció fugazmente en la lección 02-06, y por qué lleva una barra en el nombre?
• ¿Cómo se autentica Bruno para poder enviar su trabajo?
• ¿Qué pasa si dos personas envían cambios sobre la misma rama a la vez?
• Y sobre todo: Carla todavía no se ha incorporado. Está esperando en su Windows 11 a que le digan de dónde descargar el proyecto.

En el módulo 4: Trabajando con Repositorios Remotos cerramos ese círculo. Veremos qué es un remoto y por qué no es más que un nombre corto para una URL, cómo se registra con git remote add, cómo funciona la autenticación con SSH y con tokens, la diferencia crucial entre git fetch y git pull, cómo enviar el trabajo con git push, y qué son las ramas de seguimiento que hacen que git status te diga "tu rama está 3 commits por delante de origin/main".

Y la buena noticia es que todo lo que has aprendido en este módulo sigue siendo cierto sin ningún cambio. Fusionar el trabajo de otra persona es exactamente el mismo git merge que has usado aquí. Los conflictos se resuelven igual. Las estrategias son las mismas. Lo único que se añade es el transporte: cómo consiguen los objetos viajar de un .git/ a otro. Una vez han llegado, todo funciona como ya sabes.

Error 1: interpretar --no-merged como "aquí hay trabajo perdido". Solo significa que la punta de esa rama no es alcanzable desde donde estás. Una rama integrada con squash siempre aparecerá ahí aunque su contenido esté íntegro en main. Comprueba con git diff main..<rama> antes de sacar conclusiones.

Error 2: usar -D por costumbre porque -d "da la lata". Esa lata es la red de seguridad. Cada vez que -d falla, te está diciendo algo que merece treinta segundos de comprobación. Reserva -D para después de haber mirado.

Error 3: no anotar el hash que imprime el borrado. Deleted branch X (was 9d1e4b7) es tu billete de vuelta. Si te das cuenta al minuto siguiente de que te has equivocado, git branch X 9d1e4b7 lo arregla. Sin el hash, hay que ir al reflog.

Error 4: crear una rama con el nombre de un directorio de ramas existente. Si tienes funcionalidad/orden-alfabetico, no puedes crear funcionalidad. El error que da Git es críptico, pero la causa es que los nombres son rutas de fichero.

Error 5: acumular ramas "por si acaso". El coste no es el espacio (son 41 bytes) sino la confusión: nadie sabe cuáles están vivas, el autocompletado se vuelve inútil y las listas dejan de leerse. Si la rama está fusionada, bórrala; los commits no se van a ninguna parte.

Consejo 1: guarda el listado bonito como alias. git ramas con fecha relativa, autor y último mensaje es la vista que de verdad usarás. La línea completa está en el apartado 3.

Consejo 2: haz la limpieza mensual, y hazla en dos pasos. Primero listar, revisar con los ojos, y después borrar. Nunca en un solo comando encadenado sin mirar.

Consejo 3: nombra las ramas pensando en quien las vea dentro de un mes. Incluye el prefijo de tipo y, si el equipo usa un gestor de incidencias, su identificador. Es la diferencia entre una lista de ramas que se entiende y una que da miedo tocar.

Consejo 4: borra la rama en cuanto la integres. Convertirlo en el último paso del ritual de fusión —fusionar, comprobar, borrar— hace que la limpieza mensual no llegue nunca a ser necesaria.

En un repositorio con varias ramas (créalas si hace falta), responde con comandos:

1. ¿Qué ramas se pueden borrar ahora mismo sin perder ningún commit?
2. ¿Qué ramas tienen trabajo sin integrar y cuántos commits son en cada caso?
3. ¿Cuál es la rama que lleva más tiempo sin actividad?
4. ¿En qué ramas está presente un commit concreto?

Reproduce la situación que confunde a --merged: integra una rama con --squash y demuestra con comandos que:

1. Su contenido está en main.
2. Git la considera no fusionada.
3. -d se niega a borrarla y -D no.
4. Después de borrarla con -D, se puede recrear exactamente donde estaba.

Escribe un pequeño script que reciba un nombre de rama y decida si es válido según Git y según una convención de equipo que exija uno de estos prefijos: funcionalidad/, correccion/, hotfix/ o documentacion/. Pruébalo con al menos cuatro nombres, válidos e inválidos.

Solución 1:

Su punta es alcanzable desde main: borrarlas no deja ningún commit sin referencia.

git rev-list --count main..<rama> cuenta los commits del rango, con la misma semántica que aprendiste en la lección 02-06.

Solución 2:

Cero diferencias: los ficheros son idénticos.

Tres commits que main no tiene, aunque su efecto sí esté ahí, condensado en un único commit distinto.

Idéntica a como estaba. Los commits nunca se fueron: solo se borró el nombre que los señalaba.

Solución 3:

Pruebas:

Fíjate en el cuarto caso: el espacio hace que lo rechace ya git check-ref-format, sin que lleguemos a la comprobación de mayúsculas. Y el quinto lo rechaza por el .., que Git reserva para los rangos de commits.

Este script es exactamente lo que se convierte en un hook pre-commit o pre-push para que la convención se aplique sola, sin depender de la disciplina de cada persona. Lo veremos en la lección 06-01.

Con esta lección cerramos el módulo 3. Lo aprendido aquí:

• git branch -v muestra la punta y el último mensaje de cada rama; -vv añadirá la información de seguimiento cuando tengamos remotos (módulo 4).
• --merged y --no-merged responden a la pregunta clave del mantenimiento: qué ramas se pueden borrar sin perder ningún commit. Ojo con las integradas mediante squash, que siempre aparecen como no fusionadas aunque su contenido esté en main.
• --sort=-committerdate con --format convierte un listado alfabético inútil en una vista real de qué está vivo, quién lo lleva y desde cuándo. Guárdalo como alias.
• git branch -m renombra: es renombrar el fichero de 41 bytes y, si era la rama actual, actualizar HEAD. Totalmente seguro en local.
• -d frente a -D: el primero comprueba que no se pierde nada y se niega si no es así; el segundo fuerza. Cuando -d falla, significa que la punta no es alcanzable desde donde estás, no necesariamente que el trabajo se pierda. Comprueba con git log main..<rama> y git diff main <rama> antes de forzar. -D es recuperable durante semanas gracias al reflog (módulo 9).
• Borrar una rama borra 41 bytes. Los commits siguen intactos en la base de datos de objetos.
• Las convenciones de nombres (funcionalidad/, correccion/, hotfix/…) agrupan, permiten filtrar y hacen útil el autocompletado. Las reglas formales de Git se comprueban con git check-ref-format --branch.
• La higiene es una rutina de cuatro pasos: listar por antigüedad, separar fusionadas de no fusionadas, revisar las segundas y borrar las primeras. Y la mejor higiene es tener ramas de vida corta que no lleguen a acumularse.

Ya dominas las ramas: qué son, cómo crearlas, cómo fusionarlas, cómo resolver los choques y cómo mantener el repositorio ordenado. Pero todo ello dentro de un único .git/.

En el módulo 4: Trabajando con Repositorios Remotos el proyecto sale por fin del portátil de Ana. Veremos qué es un remoto, cómo se registra, cómo se autentica el acceso, la diferencia entre git fetch y git pull, cómo enviar el trabajo con git push y qué son las ramas de seguimiento. Y Carla se incorporará por fin al equipo desde su Windows 11, clonando el proyecto tal como hizo Bruno en la lección 02-02, pero esta vez con un repositorio que ya tiene historia, ramas y una forma de trabajar.