El Gobierno de la República de Gitlandia acaba de crear el Ministerio de las Promesas Imposibles, una institución encargada de desarrollar un programa electoral que cambiará constantemente.
El problema es que cada vez que un político cambia de opinión, los funcionarios sobrescriben los documentos anteriores. Nadie sabe qué prometieron ayer, quién modificó una propuesta o cuándo desapareció una medida electoral.
El ministro de Tecnología ha decidido contratar a un administrador de sistemas para solucionar el problema: tú.
Tu misión será poner en funcionamiento un sistema de control de versiones que permita conservar todas las promesas electorales, identificar sus modificaciones, recuperar propuestas anteriores y publicar el programa en Internet.
A lo largo de la práctica se producirán varios incidentes: promesas incumplidas, presupuestos disparatados, borrados accidentales y hasta un intento de manipulación del programa electoral.
Toda la actividad es ficticia. La sátira se dirige a situaciones políticas generales, sin necesidad de utilizar partidos o políticos reales.
Objetivos de aprendizaje
Al terminar, cada alumno deberá ser capaz de:
Instalar y configurar Git desde la terminal.
Crear e inicializar un repositorio local.
Comprender el directorio de trabajo, el área de preparación (staging) y los commits.
Añadir, modificar, eliminar y recuperar archivos.
Consultar el historial y comparar versiones.
Utilizar .gitignore para excluir determinados archivos.
Crear y utilizar ramas individualmente.
Trabajar con un repositorio remoto en GitHub.
Subir, descargar y sincronizar cambios.
Clonar un repositorio y continuar trabajando sobre él.
En esta práctica cada estudiante trabaja individualmente. Las colaboraciones, los conflictos entre usuarios y las pull requests quedarán para la segunda práctica.
Antes de comenzar: comprender Git
Git es un sistema de control de versiones distribuido. Permite registrar el estado de los archivos de un proyecto en diferentes momentos y recuperar su historial.
Git no es lo mismo que GitHub: Git funciona localmente y no necesita Internet. GitHub es un servicio que puede alojar repositorios remotos y facilitar el intercambio de proyectos.
Esquema conceptual simplificado: primero se modifican archivos, después se seleccionan los cambios y finalmente se registran mediante un commit.
Fase 1. Preparación del entorno
Paso 1. Comprobar si Git está instalado
Abre una terminal de tu máquina virtual Ubuntu y ejecuta:
git --version
Si está instalado, aparecerá algo parecido a:
git version 2.x.x
Si aparece command not found, instala Git:
sudo apt update
sudo apt install git -y
Después, verifica nuevamente su versión.
Pregunta para el alumno: ¿Por qué crees que Git puede funcionar sin conexión a Internet?
Paso 2. Configurar nuestra identidad
Cada vez que realicemos un commit, Git registrará la identidad del autor.
Utiliza un correo propio o el correo privado que GitHub te proporcione para los commits.
Consulta tu configuración:
git config --global --list
Y configura la rama inicial predeterminada:
git config --global init.defaultBranch main
Importante: esta configuración es global para tu usuario de Linux. No es necesario repetirla para cada proyecto.
Paso 3. Crear nuestro espacio de trabajo
Crearemos una carpeta donde almacenar nuestros proyectos.
mkdir -p ~/proyectos-git
cd ~/proyectos-git
mkdir ministerio-promesas
cd ministerio-promesas
Comprueba dónde estás:
pwd
Visualiza el contenido:
ls -la
El directorio debería estar vacío.
Paso 4. Inicializar un repositorio
Ejecuta:
git init -b main
Acabamos de convertir una carpeta normal en un repositorio Git.
Compruébalo:
ls -la
Verás una carpeta oculta llamada .git.
Esta carpeta contiene la información necesaria para que Git pueda gestionar el repositorio: objetos, referencias, configuración e historial.
No es necesario modificar manualmente su contenido.
Ahora ejecuta:
git status
Debería aparecer un mensaje parecido a:
On branch main
No commits yet
nothing to commit
Primer reto: ¿Qué sucedería si eliminásemos la carpeta .git? ¿Desaparecerían los archivos de nuestro proyecto? ¿Y el historial?
Fase 2. Primer programa electoral
Paso 5. Crear el documento oficial
El presidente de Gitlandia ha anunciado el primer programa electoral:
«Prometemos que nadie volverá a quedarse sin batería en el móvil, que todos los lunes serán festivos y que los exámenes se resolverán por votación popular».
Vamos a escribir estas propuestas en un archivo Markdown.
Ejecuta:
nano programa.md
Introduce el siguiente contenido:
# Programa Electoral de Gitlandia
## Elecciones Generales
Presidente: Don Commit Permanente
## Promesas oficiales
1. WiFi gratis en todo el país.
2. Los lunes serán festivos.
3. Cada ciudadano tendrá un robot asistente.
4. Los exámenes serán voluntarios.
5. Las impresoras funcionarán siempre.
## Lema
"Prometemos hasta que se llene el disco duro".
Guarda con Ctrl + O, pulsa Intro y cierra con Ctrl + X.
Comprueba el contenido:
cat programa.md
Paso 6. Consultar el estado del repositorio
Ejecuta:
git status
Aparecerá el archivo programa.md como archivo no seguido (untracked).
Esto significa que Git todavía no está controlando sus versiones.
Ahora ejecuta:
git add programa.md
git status
El archivo aparecerá preparado para incluirse en un commit.
Acabas de añadirlo al área de preparación, también llamada staging area.
Paso 7. Registrar el primer commit
Un commit es un registro de una versión del proyecto, acompañado de información sobre su autor, fecha y mensaje.
Ejecuta:
git commit -m "Primer programa electoral de Gitlandia"
Consulta el historial:
git log
Verás una entrada con un identificador, autor, fecha y mensaje.
También puedes obtener una versión resumida:
git log --oneline
Comprobación: el profesor debe poder identificar el primer commit y comprobar que el repositorio está limpio mediante git status.
Fase 3. Primer escándalo: las promesas cambian
Paso 8. Modificar una promesa
El ministro de Economía acaba de descubrir que los lunes festivos son caros.
El Gobierno ha decidido modificar la segunda promesa:
Antes: Los lunes serán festivos.
Después: Los lunes serán festivos únicamente si no hay trabajo pendiente.
Edita el archivo:
nano programa.md
Modifica esa línea, guarda el archivo y ejecuta:
git diff
Git mostrará los cambios respecto de la versión preparada o registrada anteriormente.
Normalmente, las líneas eliminadas aparecen con - y las nuevas con +.
Ejemplo de comparación
– 2. Los lunes serán festivos.
+ 2. Los lunes serán festivos únicamente si no hay trabajo pendiente.
La oposición acusa al Gobierno de hacer promesas imposibles. El presidente responde anunciando nuevas medidas.
Añade al final de programa.md:
## Nuevas medidas
6. Un unicornio eléctrico para cada familia.
7. Internet gratuito incluso dentro de los túneles.
8. Los atascos serán declarados ilegales.
9. Se eliminarán los errores 404 por decreto.
Antes de confirmar, ejecuta:
git status
git diff
Añade el archivo al staging:
git add programa.md
Ahora observa qué se va a registrar:
git diff --staged
Finalmente:
git commit -m "Ampliación del programa con medidas revolucionarias"
Reto: interpreta lo que estás viendo
Responde en tu documentación: ¿qué diferencia existe entre git diff y git diff --staged? ¿Por qué puede interesarnos seleccionar los cambios antes de confirmarlos?
Fase 4. El presupuesto secreto
Paso 10. Crear varios documentos
El Ministerio comienza a tener departamentos.
Crea la estructura:
mkdir -p economia comunicacion secretos
Crea un archivo de presupuesto:
cat > economia/presupuesto.txt <<'EOF'
PRESUPUESTO GENERAL DE GITLANDIA
WiFi nacional: 500 millones
Unicornios eléctricos: 800 millones
Robot por ciudadano: 2000 millones
Publicidad institucional: 9000 millones
Total: pendiente de calcular
EOF
Ahora un comunicado oficial:
cat > comunicacion/nota.txt <<'EOF'
COMUNICADO DEL GOBIERNO
El presupuesto está perfectamente controlado.
Las calculadoras de la oposición están manipuladas.
EOF
Y un documento que no debería publicarse:
echo "Clave ficticia de demostración: VOTO123" > secretos/claves.txt
Paso 11. Evitar archivos innecesarios con .gitignore
Los archivos excluidos por .gitignore no se añadirán automáticamente al control de versiones cuando todavía no están siendo seguidos.
Crea:
nano .gitignore
Introduce:
# Documentos internos ficticios
secretos/
# Archivos temporales
*.tmp
# Copias de seguridad
*.bak
# Configuraciones locales
.env
Comprueba:
git status
El archivo dentro de secretos/ no aparecerá como pendiente de seguimiento.
Puedes verificar la regla:
git check-ignore -v secretos/claves.txt
Ahora registra los documentos públicos y las reglas de exclusión:
git add .gitignore economia/ comunicacion/
git status
git commit -m "Creación de departamentos y presupuesto oficial"
Advertencia: .gitignore no convierte una contraseña en segura. No debe utilizarse Git para publicar secretos. Si alguna credencial real se ha incluido en un commit, ignorarla posteriormente no elimina el secreto del historial.
Fase 5. Crisis institucional: recuperar los errores
Esta fase es especialmente importante: aprenderemos a solucionar problemas sin destruir nuestro trabajo.
Paso 12. Recuperar un archivo modificado
Un funcionario decide cambiar el presupuesto utilizando un procedimiento bastante cuestionable:
echo "TODO EL PRESUPUESTO PARA HELADOS" > economia/presupuesto.txt
Comprueba el resultado:
cat economia/presupuesto.txt
git diff
El ministro entra en pánico.
Necesitamos recuperar la última versión confirmada del archivo.
Ejecuta:
git restore economia/presupuesto.txt
Vuelve a comprobar:
cat economia/presupuesto.txt
El presupuesto original debería haber regresado.
git restore ha descartado la modificación no registrada. Si hubiésemos querido conservarla, primero tendríamos que haberla guardado en otro lugar.
Paso 13. Recuperar un archivo eliminado
Un nuevo ministro decide que la mejor manera de evitar las críticas es eliminar los comunicados.
Ejecuta:
rm comunicacion/nota.txt
Comprueba:
git status
El archivo aparecerá como eliminado.
Recupéralo:
git restore comunicacion/nota.txt
Comprueba que existe nuevamente:
ls comunicacion/
cat comunicacion/nota.txt
Paso 14. Quitar un cambio del staging
En esta ocasión, el funcionario ha preparado accidentalmente un cambio.
echo "Impuesto por respirar aire premium" >> economia/presupuesto.txt
git add economia/presupuesto.txt
git status
El archivo ya está en staging.
Para retirarlo sin perder la modificación:
git restore --staged economia/presupuesto.txt
Comprueba:
git status
cat economia/presupuesto.txt
La modificación continúa en el archivo, pero ya no está preparada para un commit.
Finalmente, descarta el experimento:
git restore economia/presupuesto.txt
Diferencia esencial
Comando
Resultado
git restore archivo
Descarta los cambios locales no preparados en ese archivo
git restore --staged archivo
Lo retira del staging, conservando el contenido
git add archivo
Prepara cambios para el próximo commit
git commit
Registra un nuevo punto del historial
Fase 6. La hemeroteca: Git nunca olvida
Paso 15. Investigar el historial de promesas
Un periodista solicita el programa electoral original para comprobar qué decía el Gobierno antes de modificar sus promesas.
Ejecuta:
git log --oneline
El resultado será parecido a este (los identificadores serán diferentes):
e3a45b1 Creación de departamentos y presupuesto oficial
b729c81 Ampliación del programa con medidas revolucionarias
a16d729 Economía limita los lunes festivos
c871a93 Primer programa electoral de Gitlandia
Cada línea representa un commit.
Consulta los detalles del último:
git show HEAD
HEAD indica el commit actual de nuestra rama.
Consulta la versión anterior:
git show HEAD~1
También podemos investigar los cambios de un archivo:
git log --oneline -- programa.md
Y comprobar cómo era en el primer commit. En nuestro caso, hemos realizado cuatro commits, por lo que:
git show HEAD~3:programa.md
Atención: HEAD~3 significa retroceder tres commits desde el actual, no necesariamente acceder siempre al primero. En esta práctica funciona si se ha seguido exactamente la secuencia.
Paso 16. Comparar dos momentos de la historia
Consulta el historial para localizar los identificadores de dos commits.
git log --oneline
Después ejecuta, sustituyendo los identificadores:
git diff ID_ANTIGUO ID_NUEVO -- programa.md
Por ejemplo, si los identificadores fueran c871a93 y b729c81:
git diff c871a93 b729c81 -- programa.md
Con este procedimiento puedes demostrar que el Gobierno cambió sus promesas.
Investigación periodística
Elabora un pequeño informe respondiendo: ¿cuál fue la promesa modificada? ¿En qué commit ocurrió? ¿Qué mensaje acompañaba al cambio? ¿Cómo puedes recuperar el contenido de la versión original sin modificar el proyecto actual?
Fase 7. El Gobierno comete un error histórico
Ahora vamos a ver otra de las funciones más útiles de Git: revertir un commit completo.
Paso 17. Registrar una medida equivocada
El presidente firma accidentalmente un decreto que establece:
«Todos los ciudadanos deberán pagar una cuota de 100 euros por utilizar el teclado de su ordenador».
Añade esta línea al programa electoral:
echo "10. Impuesto de 100 euros por utilizar el teclado." >> programa.md
Registra el cambio:
git add programa.md
git commit -m "Aprobado nuevo impuesto sobre los teclados"
La medida provoca una crisis nacional. El Gobierno quiere anularla, pero conservar la evidencia histórica de que fue aprobada.
Ejecuta:
git revert --no-edit HEAD
Observa el historial:
git log --oneline
Deberían aparecer tanto el commit que introdujo el impuesto como otro posterior que lo revierte.
¿Por qué es importante? Porque Git no ha borrado el commit anterior. Ha registrado una nueva operación que anula su efecto.
Comprueba que la medida ya no aparece:
cat programa.md
Así queda la historia del impuesto
No confundas git revert con git restore. El primero crea un commit que deshace otro commit; el segundo permite recuperar archivos o quitar cambios del staging sin registrar necesariamente un nuevo commit. git Documentation+1
Fase 8. Crear una rama: el programa electoral alternativo
Aunque todavía no vamos a trabajar en equipo, es importante comprender las ramas. Un desarrollador individual puede utilizarlas para experimentar sin modificar su versión principal.
Paso 18. Crear el programa de la oposición
El partido de la oposición, llamado Partido del Código Libre (PCL), propone sustituir algunas medidas por otras todavía más absurdas.
Desde main, crea una rama:
git switch -c oposicion
Comprueba:
git branch
Debería aparecer:
main
* oposicion
El asterisco identifica la rama actual.
Ahora crea un archivo nuevo:
cat > oposicion.md <<'EOF'
# Programa de la oposición
Partido del Código Libre
1. Prohibir las reuniones que pudieron ser un correo.
2. Obligar a que todos los políticos usen Linux.
3. Convertir el Congreso en un servidor de Minecraft.
4. Que los ministros aprueben un examen de informática.
5. Sustituir los discursos por mensajes de 140 caracteres.
EOF
Registra el documento:
git add oposicion.md
git commit -m "Programa alternativo de la oposición"
Comprueba:
ls
git log --oneline
Paso 19. Volver al Gobierno
Regresa a la rama principal:
git switch main
Lista los archivos:
ls
Observa que oposicion.md ya no aparece.
Esto ocurre porque el archivo se creó y se registró en otra rama.
Vuelve a la oposición:
git switch oposicion
El archivo vuelve a aparecer.
Paso 20. Fusionar la oposición con el Gobierno
El presidente anuncia un pacto histórico: incorporará las propuestas de la oposición al repositorio oficial.
Regresa a la rama principal:
git switch main
Fusiona la rama de la oposición:
git merge oposicion
Comprueba:
ls
git log --oneline --graph --all --decorate
El archivo oposicion.md debe aparecer en la rama principal.
En esta situación lo normal es que Git pueda realizar una fusión de tipo fast-forward, porque main no tenía nuevos commits desde que se creó la rama.
No siempre aparece un commit específico de fusión. Es importante que los alumnos entiendan este comportamiento.
Puedes eliminar la rama individual una vez integrada:
git branch -d oposicion
El contenido fusionado no desaparece.
Fase 9. Llega la revolución: publicar en GitHub
Hasta este momento hemos trabajado completamente en local. El repositorio existe únicamente dentro de nuestra máquina virtual.
Ahora vamos a publicarlo en un servicio remoto.
Paso 21. Crear una cuenta en GitHub
Entra en GitHub y crea una cuenta si no tienes una.
Después, crea un nuevo repositorio desde el botón de creación de repositorios.
Configúralo con estos datos:
Campo
Valor
Repository name
ministerio-promesas
Description
Programa electoral ficticio de Gitlandia
Visibilidad
Público, o privado si así lo indica el profesor
Add README
Desactivado
Add .gitignore
Desactivado
Choose a license
Ninguna por ahora
Es importante no inicializar el repositorio remoto con archivos, porque ya tenemos un proyecto local con su propio historial. GitHub Docs
Paso 22. Vincular Git local con GitHub
Copia la dirección HTTPS del repositorio que acabas de crear.
Sustituye TU_USUARIO por tu nombre de usuario de GitHub.
Consulta los remotos:
git remote -v
Verás una dirección de envío (push) y otra de descarga (fetch).
origin es simplemente el nombre que hemos asignado al repositorio remoto. No es una palabra reservada que tenga que utilizarse obligatoriamente.
Paso 23. Publicar el primer repositorio
Ejecuta:
git push -u origin main
La opción -u establece la relación de seguimiento entre nuestra rama local main y la rama remota correspondiente.
A partir de ese momento, los siguientes envíos podrán hacerse simplemente mediante:
git push
Importante: autenticación
GitHub no admite utilizar la contraseña normal de tu cuenta como contraseña de Git para operaciones HTTPS. Tendrás que usar un método de autenticación compatible, como Git Credential Manager, GitHub CLI o un token de acceso personal con los permisos adecuados.
Una opción especialmente cómoda para un entorno de prácticas es utilizar GitHub CLI:
gh auth login
Este comando requiere tener gh instalado. En el asistente selecciona GitHub.com, HTTPS y sigue las instrucciones de autenticación.
Nunca escribas tokens ni contraseñas reales dentro de los archivos de la práctica.
Paso 24. Comprobar la publicación
Vuelve al navegador, abre tu repositorio de GitHub y actualiza la página.
Deberían aparecer programa.md, oposicion.md, los directorios públicos, .gitignore y el historial.
Comprueba especialmente que secretos/claves.txt no se ha publicado.
Paso 25. Crear un README para los visitantes
Un repositorio debería explicar qué contiene y cómo utilizarlo.
Crea:
nano README.md
Añade:
# Ministerio de las Promesas Imposibles
Bienvenido al repositorio oficial del Gobierno
de Gitlandia.
## Objetivo
Aprender Git mediante un programa electoral
ficticio que cambia constantemente.
## Archivos
- programa.md: Programa electoral oficial.
- oposicion.md: Propuestas de la oposición.
- economia/: Presupuestos.
- comunicacion/: Comunicados oficiales.
## Tecnología
- Linux
- Git
- GitHub
- Markdown
## Advertencia
Todos los personajes y propuestas son ficticios.
Proyecto educativo individual.
Registra y publica los cambios:
git add README.md
git commit -m "Documentación oficial del repositorio"
git push
Actualiza la página de GitHub.
El contenido del README debería mostrarse automáticamente en la página del proyecto.
Fase 10. Sincronización y clonación
Paso 26. Simular una modificación desde otro ordenador
Queremos comprobar qué sucede cuando el repositorio remoto tiene cambios que aún no existen en nuestra máquina virtual.
Abre el archivo README.md directamente en GitHub y utiliza su opción de edición.
Añade al final:
## Comunicado de última hora
El ministro anuncia que se estudiará
la posibilidad de cumplir alguna promesa.
Guarda la modificación mediante un commit desde GitHub.
Acabamos de crear una versión nueva que existe en GitHub, pero todavía no en nuestra máquina virtual.
Paso 27. Descargar los cambios
Vuelve a la terminal de Ubuntu.
Ejecuta:
git fetch origin
Este comando descarga información y objetos del repositorio remoto, pero no integra automáticamente los cambios en tu rama local.
Comprueba las diferencias:
git log --oneline HEAD..origin/main
Después ejecuta:
git pull --ff-only
En este caso, como no hemos realizado nuevos commits locales después de la publicación, Git debería poder actualizar mediante fast-forward.
Comprueba el README:
cat README.md
La modificación introducida desde GitHub debería estar disponible localmente.
Pregunta: ¿Qué diferencia existe entre git fetch, git pull y git push?
Paso 28. Clonar el proyecto en otro directorio
Vamos a simular que hemos adquirido un nuevo ordenador o que necesitamos restaurar el proyecto después de perder la máquina virtual.
El repositorio clonado tendrá los archivos publicados y su historial Git.
No contendrá los archivos locales ignorados que no se subieron a GitHub.
Última misión
Desde este nuevo clon, añade a README.md una sección titulada «El Ministerio sobrevive al cambio de ordenador».
Después:
git add README.md
git commit -m "El Ministerio sobrevive al cambio de ordenador"
git push
Regresa al repositorio original:
cd ~/proyectos-git/ministerio-promesas
Y actualízalo:
git pull --ff-only
Comprueba que el cambio realizado en el nuevo clon aparece también en el original.
Hemos trabajado sobre el mismo proyecto desde dos directorios diferentes, sin necesitar un trabajo colaborativo entre personas.
Fase 11. El examen del ministro
En esta última fase, los alumnos realizarán pequeñas operaciones sin copiar exactamente la secuencia anterior. Deben identificar los comandos necesarios y justificar su elección.
Misiones finales
Marca las completadas
0 de 7 misiones
0%Crear un archivo ministros.md con tres ministros ficticios y registrar un commit.Añadir una cuarta promesa al programa electoral, identificar el cambio con git diff y registrarlo.Modificar accidentalmente economia/presupuesto.txt y recuperar la versión confirmada.Crear un archivo temporal discurso.tmp y comprobar que Git lo ignora.Crear una rama llamada reforma, añadir una propuesta, registrarla y fusionarla con main.Publicar todos los cambios en GitHub y comprobar que el repositorio local está sincronizado.Mostrar el historial completo con un gráfico de los commits.
Comandos que deben dominar
Comando
Función
git init -b main
Inicializar repositorio
git status
Consultar estado
git add archivo
Preparar cambios
git commit -m "mensaje"
Registrar versión
git log --oneline
Consultar historial
git diff
Comparar cambios
git show HEAD
Inspeccionar último commit
git restore archivo
Recuperar contenido
git restore --staged archivo
Retirar del staging
git revert HEAD
Revertir un commit
git switch -c rama
Crear y cambiar de rama
git merge rama
Fusionar ramas
git remote -v
Consultar remotos
git push
Enviar commits
git fetch
Descargar información remota
git pull
Descargar e integrar cambios
git clone URL
Clonar repositorio
Adaptación para Windows
En Windows pueden instalar Git for Windows y utilizar Git Bash, que permite ejecutar prácticamente todos los comandos Linux de esta práctica.
Para quienes utilicen PowerShell, las principales diferencias están en los comandos del sistema, no en Git.
Operación
Bash (Linux y Git Bash)
PowerShell
Directorio actual
pwd
pwd
Listar archivos
ls -la
Get-ChildItem -Force
Crear carpeta
mkdir proyecto
mkdir proyecto
Mostrar archivo
cat archivo.txt
Get-Content archivo.txt
Eliminar archivo
rm archivo.txt
Remove-Item archivo.txt
Editar archivo
nano archivo.txt
notepad archivo.txt
Consultar Git
git status
git status
Para mantener la práctica sencilla, recomiendo que todos trabajen con la terminal Linux de su máquina virtual, usando Windows solamente como demostración adicional.
Entrega de la práctica
Cada alumno deberá entregar un archivo README.md o informe.md con las respuestas a las preguntas, las explicaciones de los incidentes y las capturas necesarias.
Además, deberá facilitar el enlace de su repositorio en GitHub y demostrar que contiene el historial de commits.
![[Prueba competencial] - Servicios utilizando Docker y Docker Compose](https://laaventuradeaprender.com/wp-content/plugins/contextual-related-posts/default.png "[Prueba competencial] - Servicios utilizando Docker y Docker Compose")
