Cómo enseñar Git desde cero: un recorrido visual para el aula

Una clase puede repetir add, commit y push y seguir sin saber dónde está su trabajo. Para enseñar Git desde cero, el primer objetivo es que el alumnado pueda predecir qué cambia después de cada operación. Los comandos vienen a poner nombre a esas decisiones.

Esta propuesta está dirigida a profesores de informática que introducen el control de versiones en FP, aunque también sirve para organizar un taller de iniciación. El recorrido utiliza un proyecto pequeño, preguntas de comprobación y dibujos que se pueden reproducir en una pizarra. Es una propuesta de secuenciación, no un programa oficial ni una experiencia de aula cuyos resultados se hayan medido.

¿Qué debe entender el alumnado antes de usar Git?

El punto de partida es distinguir un archivo, una carpeta y una versión de un trabajo. No hace falta empezar con una aplicación que compile: un documento con las normas de un proyecto permite hablar de cambios sin que un error de programación interrumpa la explicación.

Plantea una situación concreta: el grupo tiene tres archivos llamados normas-final, normas-final-2 y normas-definitivas. Dos personas han corregido versiones distintas. ¿Cuál conserva las dos correcciones? ¿Cómo se averigua quién cambió cada cosa?

A partir de ahí, introduce el repositorio Git como el lugar donde se organiza el historial del proyecto. Reserva GitHub para cuando aparezca la necesidad de compartirlo. Mezclar desde el principio instalación, cuentas, autenticación y control de versiones dificulta saber qué parte no se ha entendido.

Antes de la primera práctica con terminal, comprueba que cada alumno puede abrirla en una carpeta conocida y ejecutar git --version. La configuración inicial de Git puede prepararse como tarea previa. No debe consumir la sesión dedicada al modelo mental.

Un mapa visual para explicar dónde está cada cambio

Dibuja cuatro zonas y utiliza una tarjeta que represente una modificación de README.md. El dibujo describe un recorrido habitual hacia un remoto; las tres primeras zonas están en el ordenador del alumno.

Archivos que editas     Selección del próximo commit     Historial local
  README.md    --add-->       README.md        --commit-->     C1
                                                              |
                                                             push
                                                              v
                                                     Historial del remoto

La tarjeta representa contenido, no un archivo que desaparezca al moverse. git add prepara una versión del archivo y git commit registra lo preparado. Si el alumno vuelve a editar el archivo después de prepararlo, deberá prepararlo de nuevo si quiere incluir esa nueva edición. Documentación de Git sobre cambios y preparación.

Haz una pausa en cada flecha: «¿Qué hay ahora en el próximo commit?» y «¿Puede verlo ya otra persona en el remoto?». Para introducir push, explica que publica commits en el destino configurado y que el servidor puede rechazar la actualización. No es una operación que envíe cualquier archivo abierto en el editor. Referencia de git push.

La pregunta útil al terminar el dibujo es esta: «Has creado un commit sin hacer push. ¿Dónde está guardado?». Pide una respuesta y una señal que permita comprobarla, no solo el nombre de un comando.

¿En qué orden conviene enseñar Git?

Organiza el avance por decisiones que el alumno puede explicar. Esta secuencia permite detectar una laguna antes de que aparezcan ramas, permisos y conflictos al mismo tiempo.

Etapa	Decisión que se practica	Evidencia para avanzar
Estado del proyecto	Qué ha cambiado desde la última versión	Interpreta git status y localiza el archivo
Preparación	Qué cambio pertenece al próximo commit	Justifica lo que incluye y lo que deja fuera
Historial	Qué versión se ha guardado	Reconoce su commit y explica su propósito
Ramas	Dónde desarrollar una modificación separada	Distingue la rama actual de otra rama
Integración	Cómo reunir dos líneas de trabajo	Explica el resultado de un merge
Colaboración	Qué trabajo debe compartir o incorporar	Distingue su repositorio del remoto

No es necesario completar la tabla en una clase. El criterio de avance es la explicación del alumnado; el ritmo dependerá de su experiencia y del tiempo disponible.

Para introducir las ramas, dibuja un historial con un punto de partida común y dos continuaciones. Una rama es una referencia a un commit, no una carpeta independiente que el alumno deba duplicar. Después de integrar ambas líneas, compara el dibujo inicial con el historial que muestra Git. Pro Git: ramificar y fusionar.

Cómo preparar una primera sesión de práctica

Una sesión puede centrarse únicamente en seleccionar y guardar cambios. Como punto de partida, reserva unos 45–60 minutos, ajustables al grupo: introducción del problema, dibujo de las zonas, práctica breve y comprobación individual. Esta duración es una estimación de preparación, no una medida de eficacia.

Entrega dos archivos pequeños dentro de un repositorio preparado con un commit inicial. Pide que modifiquen ambos, pero que guarden solo uno en el siguiente commit. Antes de ejecutar nada, cada alumno escribe qué espera ver en el historial y qué cambio quedará pendiente.

Después, contrasta su predicción con el repositorio. Si alguien incluye ambos archivos, la revisión consiste en localizar cuándo se seleccionaron los cambios. Si alguien cree que ya están compartidos, vuelve a distinguir el historial local del remoto. La colección de ejercicios de Git para principiantes desarrolla este caso y añade ramas y colaboración.

En FP puede utilizarse como introducción, repaso antes de un proyecto en equipo o refuerzo individual. El encaje en un módulo concreto debe decidirlo el profesor según su programación; este recorrido no acredita por sí mismo resultados curriculares.

Cómo comprobar la comprensión sin premiar la copia

Pide que expliquen un caso ligeramente distinto del que acaban de ejecutar. Cambiar el nombre del archivo no basta: cambia la decisión, por ejemplo, prepara un archivo, edítalo otra vez y pregunta qué versión entraría en el commit.

Respuesta observada	Qué conviene revisar
«Guardar en el editor crea un commit»	Separar edición e historial
«Todo lo modificado entra en el commit»	Volver a la selección de cambios
«Una rama es una copia que hago a mano»	Dibujar referencias e historial común
«El compañero lo ve porque hice commit»	Distinguir repositorio local y remoto

Si el grupo utiliza IA, permite consultar una explicación después de formular la predicción. Pide que compruebe la respuesta contra el estado real del repositorio. El ejercicio sigue siendo decidir y verificar; pegar una secuencia que termina sin errores no demuestra que se haya entendido.

Antes de avanzar, comprueba que cada alumno puede describir el estado inicial, anticipar el resultado, inspeccionarlo y explicar una diferencia respecto a su predicción. Conserva una breve explicación individual junto al trabajo en parejas.

Para acompañar este recorrido con diagramas y simulaciones, AI Coding Patterns ofrece un curso de Git para alumnado de FP con seguimiento del aula. Revisa el contenido y el nivel antes de incorporarlo a tu grupo. La práctica visual debe conectarse también con el uso de Git en un repositorio real.

Preguntas Frecuentes

¿Cómo enseñar Git desde cero si el alumnado apenas programa?

Utiliza archivos de texto sencillos y cambios que se puedan reconocer a simple vista. Se puede trabajar el concepto de versión, selección e historial sin exigir que el alumno construya una aplicación.

¿Hace falta GitHub para enseñar Git desde cero?

No para las primeras prácticas locales. Puedes introducir un remoto cuando el grupo necesite compartir commits y ya distinga el trabajo editado del historial guardado. Git y GitHub cumplen funciones diferentes.

¿Es mejor empezar por terminal o por una interfaz gráfica?

Ambas permiten inspeccionar cambios y crear commits. Elige una interfaz que puedas explicar con claridad y pide al alumnado que identifique las mismas zonas en ella. Introducir dos interfaces a la vez añade una comparación que puede esperar.

¿Cuándo conviene introducir los conflictos de merge?

Cuando el grupo distinga las ramas y comprenda qué versiones se intentan reunir. Empieza con un conflicto pequeño y preparado, cuyo resultado correcto se pueda discutir, antes de usar un proyecto con muchas modificaciones.