Aprender Git “de verdad” no va de memorizar comandos, sino de entender el grafo: ramas, commits, punteros y cómo se mueven HEAD, branch y tag con cada operación. Learn Git Branching (LGB) convierte ese grafo en un juego visual interactivo que permite ensayar —sin miedo— los movimientos que luego romperían un repo real. Para equipos de SRE/DevOps y desarrollo, es una herramienta útil para onboarding, formación continua y simulacros de incidencias de control de versiones.
Qué es (y qué no es) Learn Git Branching
- Qué es: un simulador de repositorio con árbol de commits animado. Cada comando que se escribe muta el grafo en tiempo real; los 34 niveles guían por 8 comandos base y sus variantes (branching, merging, rebase, reset, cherry-pick, etc.).
- Qué no es: no sustituye a
gitni pretende cubrir todos los casos bordes (submódulos, LFS, hooks). Es un entrenador para fijar el modelo mental de Git y ganar velocidad y seguridad.
Acceso directo en español:
- Web: https://learngitbranching.js.org/?locale=es_ES
- Demo: https://pcottle.github.io/learnGitBranching/?locale=es_ES&demo
- Sin diálogo inicial: …&NODEMO
Por qué sirve a administradores y programadores
- Modela el grafo, no la consola. En producción, el problema no es teclear
git, sino entender consecuencias: ¿qué cambiagit reset --hardfrente agit revert? ¿qué hacerebasecon commits compartidos? LGB lo muestra en vivo. - Acelera onboarding. Nuevas incorporaciones se ponen al día en 1–2 sesiones con ejercicios autocontenidos.
- Seguridad operativa. Permite ensayar “cirugías”: reescritura de historia, rescates con
reflog, limpieza previa a release, sin riesgo para el monorrepo. - Estandariza flujos. Visualiza GitFlow, Trunk-Based o ramas de release/hotfix para alinear prácticas entre dev, QA y ops.
Plan de adopción (90 minutos, equipo mixto)
Bloque 1 (20’): fundamentos
commit,branch,checkout,merge(niveles intro).- Visualizar fast-forward vs merge commit.
- Regla de oro: no reescribir historia compartida.
Bloque 2 (35’): operaciones de “peligro controlado”
rebase(linealizar historia local antes de push).reset(--soft,--mixed,--hard): cuándo usar cada uno.reflogpara rescates (LGB no es un bash real, pero el concepto se explica y se practica la mímica conreset/cherry-pick).
Bloque 3 (25’): flujos y políticas
- Feature branches + PRs vs Trunk-based.
- Estrategias de release (tags, ramas de soporte,
cherry-pickde hotfix). - Convenciones de naming y protección de ramas en el forge (GitHub/GitLab).
Tarea (10’): desafío de “git golf” (resolver un nivel con mínimos comandos), rotando drivers para pensamiento colectivo.
Modo sandbox: taller de “cirugía de historia”
En LGB, ejecute levels para ver retos; o entre a sandbox y practique:
# Crear ramas y divergir historia
git checkout -b feature/login
git commit
git commit
git checkout main
git commit
# Intento 1: merge explícito con commit de merge
git merge feature/login
# Deshacer y probar rebase (lineal)
undo
git checkout feature/login
git rebase main
git checkout main
git merge feature/login # ahora FF
Lenguaje del código: PHP (php)Puntos clave que el equipo debe verbalizar mientras mira el grafo:
- Fast-forward vs merge commit: cuándo conservar una línea recta (historia limpia) y cuándo un nodo de fusión (valor documental).
rebasereescribe SHA (seguridad: solo local o ramas no compartidas).resetmueve solo punteros; los blobs pueden sobrevivir hasta GC (por esoreflogrescata).cherry-pickcrea nuevos commits (nuevos SHA); úselo con cuidado en hotfix multi-rama.
Políticas recomendadas por contexto
Monorrepo con cientos de devs (Trunk-based + feature flags)
- Regla: branches cortas, PRs pequeños, merge squash a
main. - Antes de push:
git pull --rebaseogit fetch && git rebase origin/main. - Ramas protegidas:
main,release/*con checks obligatorios. - Hotfix: rama
hotfix/x.y.z,cherry-pickamainyreleaseactivos, tag final.
Producto con versiones LTS (GitFlow adaptado)
developpara integración,release/*congelan features.- Rebajar deuda con
rebaseen features antes de fusionar. - Evitar merges cruzados entre
releaseydevelopsin plan; preferircherry-pickcontrolado.
Cómo usarlo offline (aula interna o brown bag)
Docker (estable, sin Internet):
docker run -p 8080:80 ghcr.io/pcottle/learngitbranching:main
# Abrir http://localhost:8080
Lenguaje del código: PHP (php)Build local (para personalizar):
git clone https://github.com/pcottle/learnGitBranching
cd learnGitBranching
yarn install
yarn gulp build
open ./index.html
Lenguaje del código: PHP (php)Consejos de aula:
- Proyectar la pantalla y entregar fichas de comandos.
- Usar el Level Builder para crear ejercicios con convenciones de la empresa (nombres de ramas, hooks imaginarios).
- Medir “git golf” por parejas para incentivar precisión.
Errores habituales y cómo explicarlos con LGB
rebasesobre rama compartida.- Riesgo: force push pisa trabajo ajeno.
- Enseñar: rebase solo local; en remoto,
mergeorevert.
- Confundir
reset --hardconrevert.reset --hardmueve punteros y tira cambios locales.revertañade un commit inverso (seguro en ramas públicas).
- Detached HEAD “mágico”.
- En LGB se ve
HEADapuntando a un commit, no a una rama. - solución:
git switch -c fix/foopara no perder el trabajo.
- En LGB se ve
cherry-picken cascada sin control.- Duplicación de commits y conflictos repetidos.
- Política: etiquetas en PRs y backport automatizado donde sea posible.
Mini-catálogo de ejercicios (lista de verificación)
- FF vs Merge commit: reproducir ambos y justificar cuándo usar cada uno.
- Rebase interactivo (simulado): reordenar y squash de commits antes de fusionar feature.
- Rescate de commits “perdidos”: simular una pérdida con
resety recuperar con movimientos del puntero (explicarreflog). - Branch hygiene: borrar ramas fusionadas con seguridad; etiquetar releases.
- Hotfix simultáneo: aplicar
cherry-pickarelease/2.4ymain, evitar divergencias.
Buenas prácticas que trasladar al forge
- Protección de ramas (
main,release/*): status checks, revisiones y veto a--force. - Convenciones de commit (Conventional Commits) para auto-changelog y semantic release.
- Plantillas de PR con checklist de tests, impacto y rollback plan.
- Acciones CI que rechacen merge si la rama no es FF respecto a
main(o auto-rebase). - Política de tags:
vX.Y.Zfirmados (GPG) y artifacts reproducibles.
Métricas útiles para tu CTO/Head of Eng
- Lead time de feature branch (apertura → merge).
- Tasa de PRs revertidos y conflictos por sprint.
- Edad media de ramas (alerta > 14 días).
- Ratio squash/merge según repositorio (consistencia de historia).
- Tiempo de recuperación ante “accidente” simulado (mediante LGB + runbook).
Conclusión
Para perfiles técnicos, entender el grafo de Git es la diferencia entre “tirar de costumbre” y operar con precisión cuando hay presión. Learn Git Branching ofrece un entorno seguro donde visualizar cada decisión y automatizar el buen juicio: cuándo rebase, cuándo merge, cuándo revert y cómo deshacer sin pánico. Integre LGB en sus rutinas de onboarding, game days de control de versiones y formación continua: el coste es mínimo; la reducción de incidentes, medible.
Preguntas frecuentes
¿Sirve para equipos avanzados o solo para juniors?
Para ambos. Juniors fijan el modelo mental; seniors ensayan cirugías de historia y acuerdan políticas visualmente. Útil en monorrepos con múltiples owners.
¿Puedo crear niveles con nuestros flujos reales?
Sí. Use Level Builder para generar un JSON del nivel y compártalo por URL o gist. Es ideal para institucionalizar el flujo de releases y backports.
¿Cómo lo meto en una sesión interna sin Internet?
Con Docker (ghcr.io/pcottle/learngitbranching:main) o build local (yarn gulp build) y servir index.html en la red interna.
¿Rebase o merge para integrar feature?
Regla práctica: rebase local para limpiar historia antes del PR; merge (con o sin squash) en ramas compartidas. Nunca rebase ramas públicas activas.
