Categoría: Pildoras

Introducción: bienvenidos al ministerio

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:

1. Instalar y configurar Git desde la terminal.
2. Crear e inicializar un repositorio local.
3. Comprender el directorio de trabajo, el área de preparación (staging) y los commits.
4. Añadir, modificar, eliminar y recuperar archivos.
5. Consultar el historial y comparar versiones.
6. Utilizar .gitignore para excluir determinados archivos.
7. Crear y utilizar ramas individualmente.
8. Trabajar con un repositorio remoto en GitHub.
9. Subir, descargar y sincronizar cambios.
10. 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.

Configura tu nombre y correo electrónico:

git config --global user.name "Tu Nombre"
git config --global user.email "tu-correo@example.com"

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.

Ahora registra la modificación:

git add programa.md

git commit -m "Economía limita los lunes festivos"

Comprueba:

git log --oneline

Ya deberías tener dos commits.

Paso 9. Segunda modificación: llega la oposición

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.

Será similar a:

https://github.com/TU_USUARIO/ministerio-promesas.git

Vuelve a la terminal, dentro de ministerio-promesas.

Ejecuta:

git remote add origin https://github.com/TU_USUARIO/ministerio-promesas.git

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.

Sal del directorio de trabajo:

cd ~/proyectos-git

Crea un directorio nuevo:

mkdir ordenador-nuevo
cd ordenador-nuevo

Clona tu repositorio:

git clone https://github.com/TU_USUARIO/ministerio-promesas.git

Entra en él:

cd ministerio-promesas

Comprueba:

git status
git remote -v
git log --oneline
ls -la

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.