Ejercicios de Git para principiantes: commits, ramas y equipo

Un ejercicio de Git sirve para algo más que terminar una lista de comandos. Debe dejar una evidencia: qué cambio se ha guardado, en qué rama y por qué el resultado coincide con lo que se buscaba. Estos ejercicios de Git para principiantes trabajan esas decisiones con archivos pequeños y resultados que puedes comprobar.

La propuesta sirve para práctica individual o para un aula de FP. Los tres primeros ejercicios utilizan el mismo repositorio y se realizan en orden. El cuarto añade colaboración y necesita una preparación distinta. Los tiempos son orientativos y no incluyen instalar Git ni resolver problemas de acceso.

Preparación: un repositorio pequeño y conocido

Necesitas Git 2.28 o posterior, una terminal y un editor de texto. Comprueba la versión con git --version. En Windows puedes usar Git Bash; en macOS y Linux, la terminal habitual. Ejecuta los ejemplos en una carpeta nueva de prácticas, fuera de cualquier proyecto existente.

mkdir practica-git-aula
cd practica-git-aula
git init -b main
git config user.name "Estudiante Git"
git config user.email "estudiante@example.com"

Los dos últimos comandos configuran la identidad solo en este repositorio de prácticas. Usa esa identidad ficticia para los ejercicios locales; si después vas a publicar el historial, revisa la identidad que quieres asociar a tus commits antes de crearlos.

Con el editor, crea README.md con una línea: Proyecto de práctica. Crea también normas.txt con una línea: Entrega: lunes. Guarda ambos archivos y ejecuta:

git add README.md normas.txt
git commit -m "Crea la base de la práctica"
git status

El resultado esperado es un primer commit y un directorio de trabajo limpio. Si Git solicita la identidad, revisa los comandos de configuración; si dice que no estás en un repositorio, comprueba la carpeta de la terminal. A partir de aquí no hay que repetir la preparación.

Ejercicio 1: guardar un cambio y dejar otro pendiente

Objetivo: decidir qué entra en un commit. Reserva unos 10–15 minutos. Añade Objetivo: practicar Git al final de README.md y cambia lunes por martes en normas.txt. Guarda los dos archivos.

El encargo es guardar únicamente la ampliación de README. Antes de ejecutar comandos, escribe qué debería mostrar Git después del commit. Después realiza la selección y compruébala. Si se abre un visor de texto, pulsa q para salir:

git status --short
git diff
git add README.md
git diff --staged
git commit -m "Explica el objetivo de la práctica"
git show --stat --oneline HEAD
git status --short

Resultado esperado: el último commit afecta solo a README.md. El cambio de normas.txt sigue pendiente en el directorio de trabajo. git diff --staged permite inspeccionar la selección antes de guardarla; el commit registra ese contenido preparado. Documentación de Git.

Pregunta de comprobación: si cierras el editor ahora, ¿el cambio de normas.txt pertenece ya a algún commit? Debe seguir guardado en el archivo, pero todavía no forma parte del historial. Es una distinción que puedes explicar sin memorizar la salida exacta de la terminal.

Para terminar y continuar con el ejercicio 2, guarda también ese segundo cambio:

git add normas.txt
git commit -m "Cambia la entrega al martes"
git status --short

La última orden no debería mostrar cambios pendientes. No uses git add . para resolver el ejercicio: preparar archivos por nombre hace visible la decisión que estamos practicando.

Ejercicio 2: desarrollar una mejora en otra rama

Objetivo: separar una modificación e integrarla después. Reserva unos 10–15 minutos. Desde el repositorio limpio del ejercicio anterior, crea una rama:

git switch -c mejora-readme

Añade al final de README.md la línea Revisión: por parejas, guarda y ejecuta:

git add README.md
git commit -m "Añade revisión por parejas"
git switch main

Abre README de nuevo. Resultado esperado: la línea añadida no aparece en main, porque el commit se creó en mejora-readme. El historial se puede representar así:

A -- B -- C          main
          \
           D        mejora-readme

Integra la mejora y observa el resultado:

git merge mejora-readme
git log --oneline --graph --all --decorate

En este caso, main no avanzó mientras trabajabas en la otra rama. Con la configuración predeterminada, Git puede hacer un avance rápido: mueve main hasta D sin crear un commit de merge. Si tu entorno tiene una política que fuerza commits de merge, el dibujo puede diferir aunque la mejora quede integrada. Pro Git: ramificar y fusionar.

Pregunta de comprobación: ¿por qué no ha sido necesario copiar y pegar la línea entre dos carpetas? El contenido que ves corresponde a la versión de la rama que tienes activa.

Ejercicio 3: resolver un conflicto con un criterio explícito

Objetivo: elegir un resultado cuando dos ramas cambian la misma línea. Reserva unos 15–20 minutos. Al terminar el ejercicio 2 debes estar en main, sin cambios pendientes. En normas.txt debe aparecer Entrega: martes.

Crea una rama para proponer otra fecha:

git switch -c entrega-jueves

Cambia el contenido de normas.txt a Entrega: jueves, guarda y registra el cambio:

git add normas.txt
git commit -m "Propone entrega el jueves"
git switch main

Ahora cambia esa misma línea en main a Entrega: viernes, guarda y ejecuta:

git add normas.txt
git commit -m "Propone entrega el viernes"
git merge entrega-jueves

Resultado esperado: con la configuración habitual y sin un resolutor automático personalizado, Git detiene el merge por un conflicto en normas.txt. Las dos ramas modificaron de forma distinta la misma línea desde un antepasado común. El artículo sobre conflictos de merge explica cómo leer los marcadores.

La decisión del ejercicio es que el equipo ha acordado entregar el viernes. Abre normas.txt y deja únicamente Entrega: viernes, sin los marcadores del conflicto. Guarda y termina la integración:

git add normas.txt
git diff --cached --check
git commit -m "Integra la propuesta y acuerda entrega el viernes"
git status
git log --oneline --graph --all --decorate

Al terminar, normas.txt contiene Entrega: viernes, el estado está limpio y el historial incluye un commit de integración con dos padres.

Pregunta de comprobación: ¿el resultado correcto era aceptar automáticamente «nuestro» cambio? No. Aquí se conserva el viernes porque ese es el acuerdo del enunciado. En otro proyecto habría que entender los requisitos antes de escoger o combinar versiones.

Ejercicio 4: compartir una mejora y revisarla por parejas

Objetivo: distinguir un commit local de una propuesta compartida. Reserva unos 20–30 minutos después de preparar los accesos. El profesor o la pareja crea un repositorio remoto de práctica con un README inicial y concede acceso de escritura a ambos participantes. Cada persona lo clona en una carpeta nueva: este ejercicio no utiliza el repositorio de los tres anteriores. Dentro de ese clon, configura git config user.name y git config user.email con la identidad que quieras asociar al historial compartido, siguiendo la configuración inicial. La identidad local del primer repositorio no se hereda.

No hacen falta datos personales, entregas reales ni código del centro. Elegid una frase del README como cambio y acordad su resultado antes de empezar. La autenticación y los permisos deben estar resueltos; si falla el acceso, la práctica está comprobando configuración, no comprensión de Git.

1. La primera persona crea una rama llamada mejora-instrucciones, modifica la frase y crea un commit.
2. Antes de hacer push, la segunda comprueba que el cambio todavía no aparece en la web del remoto.
3. La primera ejecuta git push -u origin mejora-instrucciones. La segunda selecciona esa rama en la web para ver el cambio; la rama principal todavía no lo incorpora.
4. Abre un pull request (merge request en GitLab) desde esa rama hacia la rama principal del repositorio.
5. La segunda revisa el diff, explica qué cambia y deja una observación concreta. La primera responde y, si procede, añade otro commit y hace push a la misma rama.
6. Con los permisos y las reglas del repositorio satisfechos, integran la propuesta y verifican el resultado en la rama principal del remoto.

Resultado esperado: hay una mejora integrada y una revisión que explica el cambio. El pull request es una función de la plataforma de alojamiento, no un comando de Git. Si es el primer contacto con esa interfaz, consulta qué es un pull request.

Qué entregar y cómo revisar los ejercicios

Pide evidencias pequeñas que muestren decisiones, no una captura interminable de comandos. Esta tabla sirve como pauta de revisión; no pretende sustituir la rúbrica del módulo.

Ejercicio	Evidencia	Pregunta para una explicación individual
Selección	Último commit y archivo todavía modificado, antes del commit final del ejercicio 1	¿Qué decidiste dejar fuera?
Ramas	Historial y contenido antes y después del merge	¿Dónde estaba la mejora antes de integrarla?
Conflicto	Archivo resuelto e historial de integración	¿Por qué elegiste ese resultado?
Parejas	Propuesta y comentario de revisión	¿Qué podía ver tu compañero antes del push?

Si el alumnado consulta IA, pídele una predicción antes de ejecutar el comando sugerido y una comprobación después. No des por correcto un ejercicio solo porque el asistente lo explique con seguridad. Antes de repetir estos casos con código real, cada alumno debería reconocer la rama activa y el estado pendiente de su repositorio.

Para organizar las prácticas por dificultad, consulta cómo enseñar Git desde cero. Si buscas un recorrido complementario con simulaciones y seguimiento del grupo, puedes valorar el curso de Git para alumnado de FP.

Preguntas Frecuentes

¿Se pueden hacer estos ejercicios de Git para principiantes sin GitHub?

Los tres primeros se realizan íntegramente en local. El cuarto utiliza un remoto y una plataforma con revisión de propuestas, como GitHub o GitLab, por lo que requiere preparar cuentas y permisos.

¿Qué conocimientos hacen falta para estos ejercicios de Git?

Saber crear y editar archivos de texto, abrir una terminal en una carpeta conocida y tener Git instalado. La preparación incluida crea el repositorio y configura una identidad de práctica sin cambiar la configuración global.

¿Cuánto tiempo necesita un grupo de FP?

Las duraciones indicadas son orientativas por ejercicio. Conviene repartir la práctica según el nivel del grupo y reservar tiempo aparte para instalación y accesos. La explicación individual del resultado determina si hace falta repetir una etapa.

¿Qué hago si el resultado no coincide con el esperado?

Comprueba la carpeta, la rama activa y la salida de git status antes de continuar. Revisa si has seguido los ejercicios en orden y guardado los archivos en el editor. No borres el repositorio ni ejecutes comandos de descarte para ocultar el problema; conserva el estado para poder explicarlo.