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:
- 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
.gitignorepara 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 --versionSi está instalado, aparecerá algo parecido a:
git version 2.x.xSi aparece command not found, instala Git:
sudo apt update
sudo apt install git -yDespué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 --listY configura la rama inicial predeterminada:
git config --global init.defaultBranch mainImportante: 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-promesasComprueba dónde estás:
pwdVisualiza el contenido:
ls -laEl directorio debería estar vacío.
Paso 4. Inicializar un repositorio
Ejecuta:
git init -b mainAcabamos de convertir una carpeta normal en un repositorio Git.
Compruébalo:
ls -laVerá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 statusDebería aparecer un mensaje parecido a:
On branch main
No commits yet
nothing to commitPrimer 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.mdIntroduce 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.mdPaso 6. Consultar el estado del repositorio
Ejecuta:
git statusAparecerá 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 statusEl 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 logVerás una entrada con un identificador, autor, fecha y mensaje.
También puedes obtener una versión resumida:
git log --onelineComprobació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.mdModifica esa línea, guarda el archivo y ejecuta:
git diffGit 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 --onelineYa 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 diffAñade el archivo al staging:
git add programa.mdAhora observa qué se va a registrar:
git diff --stagedFinalmente:
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 secretosCrea 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
EOFAhora 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.
EOFY un documento que no debería publicarse:
echo "Clave ficticia de demostración: VOTO123" > secretos/claves.txtPaso 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 .gitignoreIntroduce:
# Documentos internos ficticios
secretos/
# Archivos temporales
*.tmp
# Copias de seguridad
*.bak
# Configuraciones locales
.envComprueba:
git statusEl archivo dentro de secretos/ no aparecerá como pendiente de seguimiento.
Puedes verificar la regla:
git check-ignore -v secretos/claves.txtAhora 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.txtComprueba el resultado:
cat economia/presupuesto.txt
git diffEl ministro entra en pánico.
Necesitamos recuperar la última versión confirmada del archivo.
Ejecuta:
git restore economia/presupuesto.txtVuelve a comprobar:
cat economia/presupuesto.txtEl 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.txtComprueba:
git statusEl archivo aparecerá como eliminado.
Recupéralo:
git restore comunicacion/nota.txtComprueba que existe nuevamente:
ls comunicacion/
cat comunicacion/nota.txtPaso 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 statusEl archivo ya está en staging.
Para retirarlo sin perder la modificación:
git restore --staged economia/presupuesto.txtComprueba:
git status
cat economia/presupuesto.txtLa modificación continúa en el archivo, pero ya no está preparada para un commit.
Finalmente, descarta el experimento:
git restore economia/presupuesto.txtDiferencia 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 --onelineEl 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 GitlandiaCada línea representa un commit.
Consulta los detalles del último:
git show HEADHEAD indica el commit actual de nuestra rama.
Consulta la versión anterior:
git show HEAD~1También podemos investigar los cambios de un archivo:
git log --oneline -- programa.mdY comprobar cómo era en el primer commit. En nuestro caso, hemos realizado cuatro commits, por lo que:
git show HEAD~3:programa.mdAtenció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 --onelineDespués ejecuta, sustituyendo los identificadores:
git diff ID_ANTIGUO ID_NUEVO -- programa.mdPor ejemplo, si los identificadores fueran c871a93 y b729c81:
git diff c871a93 b729c81 -- programa.mdCon 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.mdRegistra 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 HEADObserva el historial:
git log --onelineDeberí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.mdAsí 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 oposicionComprueba:
git branchDebería aparecer:
main
* oposicionEl 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.
EOFRegistra el documento:
git add oposicion.md
git commit -m "Programa alternativo de la oposición"Comprueba:
ls
git log --onelinePaso 19. Volver al Gobierno
Regresa a la rama principal:
git switch mainLista los archivos:
lsObserva 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 oposicionEl 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 mainFusiona la rama de la oposición:
git merge oposicionComprueba:
ls
git log --oneline --graph --all --decorateEl 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 oposicionEl 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.gitVuelve a la terminal, dentro de ministerio-promesas.
Ejecuta:
git remote add origin https://github.com/TU_USUARIO/ministerio-promesas.gitSustituye TU_USUARIO por tu nombre de usuario de GitHub.
Consulta los remotos:
git remote -vVerá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 mainLa 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 pushImportante: 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 loginEste 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.mdAñ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 pushActualiza 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 originEste 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/mainDespués ejecuta:
git pull --ff-onlyEn 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.mdLa 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-gitCrea un directorio nuevo:
mkdir ordenador-nuevo
cd ordenador-nuevoClona tu repositorio:
git clone https://github.com/TU_USUARIO/ministerio-promesas.gitEntra en él:
cd ministerio-promesasComprueba:
git status
git remote -v
git log --oneline
ls -laEl 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 pushRegresa al repositorio original:
cd ~/proyectos-git/ministerio-promesasY actualízalo:
git pull --ff-onlyComprueba 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.
