Git switch vs checkout: en qué se diferencian

Durante mucho tiempo, git checkout servía para casi todo: moverte por el repositorio, cambiar de rama, restaurar archivos e inspeccionar commits antiguos. Esa flexibilidad generaba ambigüedad: la misma sintaxis podía significar cosas distintas según el contexto.

Un simple error tipográfico podía cambiarte de rama cuando en realidad querías restaurar un archivo. Y un vistazo rápido al historial con git checkout <commit-hash> podía dejarte en un estado HEAD desasociado sin darte cuenta. El comando funcionaba, pero exigía estar siempre atento a sus múltiples comportamientos.

Por eso, con Git 2.23 llegó git switch, un comando más especializado para gestionar operaciones con ramas.

En esta guía, te muestro cómo git switch se diferencia de git checkout. También veremos dónde encaja cada comando en los flujos de trabajo actuales y cuál es su alcance.

Si aún estás empezando con Git, te recomiendo aprender los fundamentos en nuestro curso Introduction to Git.

¿Qué es git switch?

git switch es un comando dedicado, introducido en Git 2.23, para navegar entre ramas y crearlas. Hace que moverte entre ramas sea más claro, seguro y con menos margen de error.

Antes, los desarrolladores usaban git checkout para cambiar de rama. El problema era que git checkout se ocupaba de varias tareas no relacionadas: 

• Cambiar de rama
• Restaurar archivos
• Inspeccionar commits

Esto sobrecargaba el comando y lo hacía más fácil de usar mal.

Git solucionó esto separando responsabilidades. git switch ahora se encarga de cambiar y crear ramas, y git restore de restaurar archivos. Esta separación reduce la ambigüedad y disminuye el riesgo de cambios accidentales en archivos.

En la práctica, git switch branch-name mueve el puntero HEAD actual a la rama indicada. También puedes usar git switch -c new-branch para crear y cambiarte a una rama nueva.

Mecánicas básicas: git switch vs checkout

Ahora que sabes por qué se introdujo git switch, veamos en qué se diferencia realmente de git checkout por dentro.

Gestión de ramas con propósito

Antes de Git 2.23, git checkout gestionaba tanto la navegación entre ramas como la restauración de archivos. Funcionaba, sí, pero mezclaba dos conceptos distintos. Mueve HEAD, restaura archivos y hace checkout de commits. Según cómo lo uses, manipula el puntero HEAD, el índice y el árbol de trabajo.

git switch se centra exclusivamente en mover el puntero HEAD entre ramas. Cuando ejecutas git switch branch-name, Git actualiza HEAD para que apunte a esa rama y ajusta el directorio de trabajo para que coincida. Este comando existe específicamente para navegar entre ramas y crearlas. Con git switch y git restore, las responsabilidades quedan claramente separadas:

• git switch mueve HEAD entre ramas.

• git restore modifica archivos en el árbol de trabajo o en el índice.

Por ejemplo, antes restaurar un archivo requería: git checkout HEAD -- file.txt. Hoy, el enfoque recomendado es: git restore file.txt.

Aquí estás restaurando un archivo, no navegando entre ramas. En scripts y documentación de equipo, esta distinción mejora la legibilidad y reduce errores.

Evolución de los comandos de Git

Git 2.23 separa responsabilidades introduciendo git switch para operaciones con ramas y git restore para restauración de archivos.

Antes de esa versión, git checkout funcionaba como una navaja suiza: podía cambiar de rama, restaurar archivos o moverse a commits arbitrarios. Pero esto generaba confusión, especialmente para quienes empezaban. Al dividir el comando, Git redujo la ambigüedad y clarificó los flujos de trabajo comunes.

Comportamiento con HEAD desasociado

En Git, HEAD normalmente apunta a una rama. Esa rama, a su vez, apunta al último commit. Cuando creas un nuevo commit, Git avanza la rama. Este es el flujo estándar.

Un HEAD desasociado ocurre cuando HEAD apunta directamente a un commit en lugar de a una rama. En ese estado, ya no estás en una rama. Si haces un nuevo commit, Git lo crea, pero ninguna rama lo referencia. A menos que crees una rama explícitamente, esos commits quedan sin referencia y luego pueden resultar difíciles de localizar.

Cuando ejecutas git checkout <commit-hash>, Git entra automáticamente en modo HEAD desasociado. Cambia a ese commit y desasocia HEAD sin pedir confirmación adicional. Este comportamiento es válido, pero facilita entrar sin querer en modo desasociado.

En cambio, git switch exige que lo indiques explícitamente. Para desasociar HEAD, debes usar git switch --detach <commit-hash>. Sin la opción --detach, git switch solo opera con ramas. Este diseño reduce estados desasociados accidentales y hace que los flujos con ramas sean más seguros y previsibles.

Diferencias funcionales clave entre git switch y checkout

Vistos los matices de alto nivel, pasemos a la sintaxis, el alcance y las consideraciones de seguridad.

Sintaxis y creación de ramas

Para crear y cambiarte a una rama nueva con git switch, ejecuta git switch -c <branch-name>. Con git checkout, el equivalente es git checkout -b <branch-name>.

Ambos crean una rama nueva y te cambian a ella, pero se diferencian en lo claro que expresan su intención. En git switch, la opción -c indica directamente que estás creando una rama; en git checkout, -b significa históricamente "branch", pero transmite menos claramente la intención.

git switch también incorpora la opción -C: git switch -C <branch-name>. Su efecto es más contundente que -c: crea la rama a la fuerza o la reinicia si ya existe. Este comportamiento es explícito y centrado en ramas. En git checkout existe un comportamiento forzado similar, pero su semántica está menos separada porque el comando sirve para varios propósitos.

Alcance de las operaciones

git switch solo trabaja con ramas. No puede restaurar archivos, deshace staging ni hace checkout de rutas específicas de commits anteriores. Básicamente, no admite operaciones a nivel de archivo.

En cambio, git checkout sí puede operar a nivel de archivo. Por ejemplo, git checkout <commit> -- <file> restaura un archivo concreto desde un commit pasado. 

Sin embargo, la documentación moderna de Git sugiere usar git restore para este fin. La clave es que git switch excluye deliberadamente la manipulación de archivos para mantener un alcance estrecho y predecible.

Seguridad y desambiguación

Un problema habitual de git checkout es la ambigüedad. Si un nombre de rama y un nombre de archivo son idénticos, según el contexto puede cambiar de rama o restaurar un archivo. git switch evita por completo esta ambigüedad: solo opera con ramas. Si no indicas una rama válida, Git falla claramente en lugar de adivinar. 

git switch también ofrece un manejo de errores más claro cuando los cambios locales entran en conflicto con la rama de destino. Si cambiar de rama sobrescribiría trabajo no confirmado, Git detiene la operación y muestra un mensaje directo, como estos: 

• Si la rama no existe: fatal: invalid reference: feature/login

• Si los cambios locales se sobrescribirían: error: Your local changes to the following files would be overwritten by checkout

• Si la rama ya existe al usar -c: fatal: a branch named 'feature/login' already exists

Mensajes así de claros reducen cambios de estado accidentales.

Ejemplos prácticos de git switch

Entender git switch es mucho más fácil al verlo en flujos reales. Estos ejemplos muestran cómo se comporta en la gestión diaria de ramas y por qué resulta más seguro y predecible que git checkout.

Operaciones estándar con ramas

En el día a día, básicamente te mueves entre ramas o creas otras nuevas.

• Para cambiar a una rama local existente, usa: git switch <branch_name>. Git mueve HEAD a esa rama y actualiza tu directorio de trabajo para que coincida.

• Para crear una rama para una nueva funcionalidad llamada «new_ui» y cambiarte a ella en un paso, usa git switch -c feature/new-ui. Crea la rama desde tu commit actual y mueve HEAD inmediatamente.

• Si necesitas reiniciar o sobrescribir una rama existente, usa: git switch -C feature/new-ui. La -C mayúscula fuerza la creación o reinicia el puntero de la rama. Deja claro que es una acción destructiva.

• También puedes alternar rápidamente entre tus dos últimas ramas con git switch -. Es muy útil para revisar código en una rama y volver a tu rama de feature repetidamente.

Trabajo con ramas remotas

A menudo, una rama existe en el remoto pero no en local. Por ejemplo, alguien sube origin/bugfix, pero tú aún no la has creado.

• Si ejecutas: git switch bugfix, Git creará una rama local bugfix y la configurará para hacer seguimiento de origin/bugfix, siempre que haya una coincidencia clara en origin. Esto simplifica la colaboración porque no necesitas configurar el upstream manualmente.

• Si quieres evitar que Git adivine, usa: git switch --no-guess bugfix. Ahora Git fallará si la rama no existe en local. Útil en flujos más estrictos donde el seguimiento automático puede generar confusión.

• Si prefieres ser explícito al crear una rama de seguimiento, usa git switch -c bugfix --track origin/bugfix. Así la relación de seguimiento queda clara en el propio comando.

Inspección experimental de commits

A veces solo quieres mirar un commit antiguo: probar una versión previa o verificar cuándo se introdujo un bug. En ese caso, quieres moverte temporalmente a ese punto del tiempo.

Con git switch, debes indicarlo explícitamente: git switch --detach <commit-hash>.

La opción --detach le dice a Git: mueve HEAD directamente a este commit, no a una rama. Ahora puedes explorar el código, ejecutar tests o compilar el proyecto. Si haces commits en este estado, no quedarán ligados a ninguna rama salvo que crees una.

Con git checkout <commit-hash>, ocurre lo mismo automáticamente sin una opción adicional. Eso facilita entrar sin querer en modo desasociado, mientras que exigir --detach en git switch evita estados HEAD desasociados por accidente. 

Integración de git switch en el flujo de trabajo

Veamos ahora cómo integrar git switch en los flujos de trabajo típicos de Git.

Elección según el escenario

En los flujos modernos, git switch debería gestionar todo lo relacionado con ramas, incluyendo 

• Desarrollo de funcionalidades rutinarias
• Revisión de pull requests
• Rebases locales
• Scripts de CI/CD que hacen checkout de ramas durante las builds

Como git switch se centra solo en la gestión de ramas, comunica la intención con claridad.

git checkout sigue teniendo su lugar, aunque más acotado. Muchas automatizaciones heredadas anteriores a Git 2.23 dependen de él. Ciertas tareas de reversión a nivel de archivo también pueden usarlo, aunque git restore es el reemplazo preferido a futuro.

Resolución de errores comunes

Hay dos escenarios típicos que pueden darte problemas con git switch.

“Your local changes would be overwritten”

Un error habitual al intentar cambiar de rama con cambios locales presentes es “error: Your local changes would be overwritten”. Git bloquea la operación porque el cambio sobrescribiría trabajo no confirmado. Tienes dos opciones seguras:

1. Si quieres conservar los cambios para más tarde, ejecuta git stash antes de cambiarte a la rama destino. Después, podrás recuperarlos con git stash pop.

2. Si quieres descartar intencionadamente los cambios locales, usa: git switch --discard-changes target-branch. Esta opción indica a Git que tire los cambios locales y restablezca el índice y el árbol de trabajo para que coincidan con la rama de destino (no elimina archivos no rastreados).

Entrar accidentalmente en estado HEAD desasociado

Otro caso es entrar sin querer en un estado HEAD desasociado. Si te das cuenta de que no estás en una rama pero quieres conservar tu trabajo, crea una rama nueva de inmediato: git switch -c recovery-branch. Así asocias tu historial actual a una rama con nombre y preservas los cambios.

Buenas prácticas para adoptar git switch

Adoptar git switch no es solo cuestión de preferencia. Es una pequeña mejora estructural en cómo los equipos piensan sus flujos de trabajo con Git. Los beneficios se multiplican cuando la adopción es consistente en documentación, onboarding y automatización.

Estrategias de migración en equipo

Empieza por tu documentación interna. Si tus guías de “Primeros pasos” aún enseñan git checkout para cambiar de rama, actualízalas a git switch. Deja checkout solo donde sea realmente necesario.

La formación también cuenta. Los comandos modernos de Git ofrecen mensajes de error más claros, sobre todo cuando los cambios locales entran en conflicto al cambiar de rama. Anima a las personas desarrolladoras a leer y entender estos mensajes en lugar de tratarlos como fallos genéricos. El conjunto nuevo de comandos es más explícito y, al reconocerlo, se gana confianza y se reducen errores.

Consistencia en la automatización

En scripts de shell, pipelines de CI y alias de Git, prioriza git switch para la navegación entre ramas porque comunica la intención al instante. Un script que usa git switch main se interpreta mejor que otro que usa git checkout, que puede significar varias cosas. 

Si defines alias de Git, actualízalos para reflejar el uso moderno. Por ejemplo, un alias para crear ramas de features debería envolver git switch -c, no git checkout -b.

Por último, verifica las versiones de Git en todos los entornos. git switch requiere Git 2.23 o posterior. Asegúrate de que los equipos locales, los runners de CI y los servidores de build cumplen este requisito antes de estandarizar el comando. Una simple comprobación de versión evita problemas sutiles de compatibilidad.

Conclusión

Si tomas perspectiva, la gran ventaja de git switch es sencilla: hace que la gestión de ramas sea más clara, segura e intencional. Cuando ejecutas el comando, no hay ambigüedad: estás cambiando de rama. Punto. Y ese pequeño grado de claridad elimina más fricción de la que parece en el desarrollo del día a día.

Ahora bien, git checkout no está en desuso; puedes seguir usándolo para restaurar archivos, moverte entre ramas o abordar escenarios más complejos. Pero para la navegación diaria entre ramas, Git recomienda usar git switch.

Como siguiente paso, te recomiendo nuestro curso Intermediate Git, centrado en la colaboración con Git.