Introducción

En Git, un branch es solo una referencia móvil a un commit. Crear un branch es crear un archivo de 41 bytes. Comparado con sistemas centralizados donde los branches son copias completas de directorio, el modelo de Git hace el branching lo suficientemente barato para usarlo casualmente.

Qué es realmente un branch

cat .git/refs/heads/main
# a1b2c3d4e5f6...
git rev-parse main

Ese hash es la punta del branch. El "branch" en sí es la cadena de commits alcanzables desde la punta vía punteros padre.

Creando branches

git branch feature/login           # crear, no cambiar
git switch -c feature/login        # crear y cambiar
git switch -c hotfix v1.2.3        # desde un tag
git branch fixup HEAD~3            # desde una ref relativa

Moviendo la punta

Cada commit en el branch actual avanza su punta en uno. Los comandos que mueven puntas incluyen commit, merge, rebase, reset y cherry-pick.

git commit -m "Work"           # main avanza
git reset --hard HEAD~2        # main retrocede; los commits se vuelven inalcanzables

Branches y alcanzabilidad

Un commit está "vivo" mientras alguna ref llegue a él. Elimina cada branch y tag que apunte a un commit y se vuelve colgante; el recolector de basura de Git eventualmente lo elimina.

git fsck --unreachable
git gc

Rastreando upstream

Un branch local puede vincularse a un branch de seguimiento remoto:

git branch --set-upstream-to=origin/main main
git branch -u origin/main
git status            # muestra ahead/behind basado en el vínculo

Mantenimiento de branches

git branch --merged main           # branches completamente mergeados
git branch --no-merged main        # branches con trabajo no mergeado
git branch -d feature/old          # eliminar mergeado
git branch -D feature/discarded    # forzar eliminación

Comparando branches

git log main..feature/login --oneline
git diff main...feature/login
git range-diff main..@{u} main..HEAD

range-diff es excelente para comparar dos versiones de un branch rebaseado.

Políticas de branch en hosts

La mayoría de las plataformas de hosting te permiten proteger branches por patrón de nombre: requerir pull requests, commits firmados, CI verde o reviewers específicos antes de aceptar un push. El lado de Git de esto se implementa vía hooks pre-receive; el lado de la plataforma es configuración. Desde tu clon local, la protección de branch es invisible hasta que tu push es rechazado, momento en el cual el servidor explica por qué. Para inspeccionar la protección desde la línea de comandos, usa la CLI del host (gh, glab) o su API.

gh api repos/owner/repo/branches/main/protection

Errores comunes

Imaginar los branches como contenedores de commits. No lo son; los commits existen independientemente y muchos branches pueden alcanzar el mismo commit. Eliminar un branch "feature" y asumir que los commits se han ido; se han ido solo después de que se vuelven inalcanzables y el reflog expira (90 días por defecto). Usar nombres de branch de una palabra que colisionan con nombres de archivo; los separadores -- evitan la ambigüedad. Finalmente, trabajar directamente en main en un repo compartido; siempre crea un branch para trabajo no trivial, incluso si planeas hacer fast-forward después.