Cómo aprender Git: plan de estudio, simuladores, documentación y práctica

Git se aprende con las manos, no leyendo. Para trabajar con soltura en equipo basta con dominar unos veinte comandos y entender tres ideas: un commit es una instantánea del proyecto, una rama es un puntero a un commit y un repositorio remoto no es más que otra copia del historial. Aquí tienes un plan para aprender Git por etapas, con ejercicios, recursos gratuitos y criterios para saber que has superado cada etapa.

El plan está pensado para un principiante que ya sabe usar el terminal, al menos a nivel de cd y ls. Si no es tu caso, dedica una tarde a lo básico de la línea de comandos: sin ella, aprender Git cuesta bastante más.

Por qué conviene aprender Git de forma sistemática

Mucha gente pasa años con cinco comandos copiados de unas instrucciones ajenas y entra en pánico ante el primer conflicto o un «detached HEAD». El motivo casi siempre es el mismo: no hay un modelo mental; no se entiende qué cambia exactamente un comando en el historial y en los archivos.

Aprender Git de forma sistemática compensa enseguida. Dejas de temer los experimentos porque sabes cómo volver atrás, resuelves conflictos con calma y mantienes un historial ordenado que ven los revisores y los empleadores. Git se evalúa en entrevistas de casi cualquier profesión IT, del frontend al DevOps y el análisis de datos.

Etapa 1. Fundamentos: repositorio, índice, commit

El objetivo de la primera etapa es entender el ciclo básico y las tres áreas de Git: el directorio de trabajo, el índice y el repositorio. Lleva de 2 a 4 días a razón de una hora diaria.

• Instalación y configuración inicial: git config --global user.name, user.email, la rama por defecto main.
• Crear un repositorio: git init.
• El ciclo git status → git add → git commit; añadir de forma selectiva con git add -p.
• Ver el historial: git log --oneline, git diff, git diff --staged, git show.
• El archivo .gitignore: lo que no debe entrar en el repositorio.

Ejercicio. Crea un repositorio para tus notas o un pequeño script. Haz entre 15 y 20 commits, cada uno con un cambio lógico y un mensaje claro. Después de cada comando ejecuta git status y explícate qué ha cambiado.

Etapa superada si puedes decir sin ayuda en qué se diferencia la salida de git diff de la de git diff --staged y hacer commit solo de una parte de los archivos modificados.

Etapa 2. Ramas y fusiones

Las ramas son el corazón de Git y la principal fuente de miedo de los principiantes. Aquí lo importante no es memorizar comandos, sino aprender a imaginar el grafo de commits. Dedica a esta etapa alrededor de una semana.

• Crear y cambiar de rama: git branch, git switch, git switch -c.
• Qué es HEAD y el estado detached HEAD.
• Fusión: git merge, fast-forward y commit de merge, la opción --no-ff.
• Conflictos: los marcadores <<<<<<< y >>>>>>>, git merge --abort.
• Visualización: git log --oneline --graph --all.

Ejercicio. Crea dos ramas a partir de main y modifica en cada una la misma línea del mismo archivo. Fusiónalas una tras otra, provoca el conflicto y resuélvelo. Repite hasta que el proceso te resulte aburrido.

En esta etapa lo que más ayuda es un simulador interactivo de Git (lo vemos más abajo). Muestra el grafo tras cada comando y construye la intuición muy rápido.

Etapa 3. Repositorios remotos y trabajo en equipo

El objetivo es aprender a trabajar con el servidor como se hace en los equipos. Necesitarás una cuenta en GitHub, GitLab u otro hosting de Git. Plazo: alrededor de una semana.

• Conectar y clonar: git remote add, git clone, acceso con clave SSH.
• Sincronización: git push, git push -u, git fetch, git pull y la diferencia entre ellos.
• Ramas de seguimiento remoto como origin/main.
• Forks, ramas de feature y pull requests con revisión de código.
• Procesos de equipo: GitHub Flow, Git Flow, trunk-based development.

Ejercicio. Trabaja con un mismo repositorio desde dos «ordenadores»: clónalo en dos carpetas distintas. Haz commits en una, súbelos y tráelos en la otra. Provoca una situación en la que el push sea rechazado porque el servidor ha avanzado y averigua por qué.

git clone git@github.com:you/sandbox.git copy-a
git clone git@github.com:you/sandbox.git copy-b
cd copy-a && echo "desde A" >> notes.txt && git commit -am "Cambio desde A" && git push
cd ../copy-b && echo "desde B" >> notes.txt && git commit -am "Cambio desde B"
git push          # rejected: el servidor ha avanzado
git pull          # traemos el cambio de A y resolvemos el conflicto en notes.txt
git push

Este breve escenario reproduce la situación más frecuente en un equipo. Analiza la salida de cada comando: por qué se rechazó el push, qué apareció en origin/main tras el fetch, de dónde salió el commit de merge. Luego repite lo mismo con git pull --rebase y compara los grafos con git log --oneline --graph --all.

Mejor aún: busca un compañero y haced juntos un pequeño proyecto mediante pull requests. Así vivirás de verdad las revisiones, los conflictos y los acuerdos sobre ramas.

Etapa 4. Deshacer errores

Esta etapa convierte Git de fuente de ansiedad en red de seguridad. De 3 a 5 días.

• git restore y git restore --staged: deshacer en archivos y en el índice.
• git commit --amend: corregir el último commit.
• git reset en los modos --soft, --mixed, --hard.
• git revert: deshacer de forma segura un commit publicado.
• git reflog: recuperar commits «perdidos».

Ejercicio. Haz varios commits, ejecuta git reset --hard HEAD~3 y recupéralos con el reflog. Deshaz un commit en una rama «compartida» con revert y mira cómo queda en el historial.

Etapa 5. Herramientas avanzadas

Se aprenden a medida que hacen falta, pero conviene saber de antemano que existen.

Simuladores de Git: dónde practicar

Lo bueno de un simulador es que ofrece un entorno seguro y muestra el resultado al momento. Algunas opciones gratuitas:

• Learn Git Branching (learngitbranching.js.org): el mejor simulador de ramas. Niveles con retos, grafo de commits animado e interfaz en español. Cubre commit, branch, merge, rebase, cherry-pick, rebase interactivo y trabajo con remotos.
• Oh My Git!: un juego gratuito y de código abierto en el que los comandos de Git son cartas y por debajo funciona un Git real.
• Tu propio repositorio de pruebas: el simulador más infravalorado. Crea una carpeta git-sandbox y rompe en ella todo lo que quieras: no hay nada que perder.

Los simuladores desarrollan muy bien la comprensión del grafo, pero no sustituyen a un proyecto real: no tienen archivos de verdad, editor, conflictos en el código ni IDE. Úsalos como complemento.

Documentación de Git y libros

La documentación oficial de Git está en git-scm.com. Allí también está disponible gratis el libro Pro Git de Scott Chacon y Ben Straub, con traducción al español. Es el mejor manual de Git: los tres primeros capítulos (fundamentos, ramificaciones) son imprescindibles, y el capítulo «Los entresijos internos de Git», para quien quiera entender el modelo de datos a fondo.

La ayuda integrada siempre está a mano: git help <comando> abre el manual completo y git <comando> -h, una lista breve de opciones. La documentación de Git es seca pero precisa; acostúmbrate a consultarla a ella y no la primera respuesta del buscador.

git help rebase        # manual completo
git switch -h          # ayuda breve sobre las opciones
git help -g            # lista de guías conceptuales (gitworkflows, gittutorial…)

También son útiles las guías gittutorial y giteveryday: vienen con la instalación estándar de Git y se abren con git help.

Por tu cuenta o con un curso

Aprender Git por tu cuenta es perfectamente posible: un libro, un simulador y un repositorio de pruebas te dan todo lo necesario. La dificultad está en otra parte: sin estructura es fácil quedarse atascado en la teoría o, al contrario, acumular comandos sin entenderlos, y sin feedback nadie te dirá que llevas el historial de forma descuidada.

Un curso de Git es útil si quieres recorrer el camino rápido y en orden: del primer commit a un pull request en un repositorio real, con ejercicios en cada paso. Al elegir un curso, no te fijes en la duración, sino en la proporción de práctica: si hay ejercicios con conflictos, deshacer errores, trabajo en equipo y un proyecto final.

Cuánto tiempo se tarda en aprender Git

Las cifras son orientativas: lo que decide es la regularidad. Una hora cada día rinde más que maratones de fin de semana una vez al mes.

Errores habituales al aprender Git

• Aprender solo con una interfaz gráfica. Los clientes gráficos son cómodos, pero esconden el modelo. Primero entiende la línea de comandos y luego elige la herramienta que prefieras.
• Memorizar opciones. Hay que recordar las ideas; las opciones siempre están en -h.
• Tener miedo a romper cosas. Hasta que no hayas hecho un reset --hard y te hayas recuperado, no sabrás que Git te protege.
• Saltarse los repositorios remotos. Git en local sin push, pull ni pull requests es la mitad de la habilidad.
• Commits «fix» y «update». El hábito de escribir mensajes con sentido es más fácil de adquirir desde el principio.

Proyecto final para afianzar lo aprendido

La mejor prueba es simular un desarrollo en equipo. Crea un repositorio, protege la rama main contra pushes directos e invita a un compañero o trabaja con dos cuentas. Cada tarea, una rama de feature y un pull request con revisión; provoca al menos un conflicto, deshaz al menos una vez un commit fallido con revert y marca una release con una etiqueta.

Tras un proyecto así, Git deja de ser un conjunto de conjuros. Ves el grafo, entiendes las consecuencias de los comandos y estás preparado para las preguntas de las entrevistas.

Conclusión

Aprender Git de forma eficaz sigue un orden: el ciclo básico, las ramas, el trabajo con el servidor, deshacer errores y después las herramientas avanzadas. El simulador te ayuda a ver el grafo, Pro Git y la documentación oficial te dan profundidad, y tu propio repositorio de pruebas y un proyecto en equipo convierten el conocimiento en habilidad. Justo así, de git init a un pull request en el proyecto final, está construido el curso de Git de Skillaria.