Práctica 36: Git, GitHub y tu primera web publicada en GitHub Pages

• Entender qué es el control de versiones y por qué Git se ha convertido en el estándar de facto.
• Distinguir claramente Git (el programa que llevas en tu ordenador) de GitHub (un servicio web que aloja repositorios). Son cosas distintas y se confunden constantemente.
• Instalar Git para Windows y la GitHub CLI (gh), y configurar tu identidad de Git por primera vez.
• Crear una cuenta de GitHub bien configurada (correo verificado, 2FA, nombre de usuario decente) y autenticarla en tu PC con gh auth login.
• Hacer tus primeros commits "de verdad" desde la consola: git init, git add, git commit, git log, git status; entender qué es el staging area.
• Escribir una mini web personal en HTML+CSS a la que pondrás tu nombre, una foto/avatar, una mini-bio y dos o tres enlaces.
• Subir la web a un repositorio público de GitHub y entender la diferencia entre el repositorio local y el remoto.
• Activar GitHub Pages sobre ese repositorio y comprobar la URL pública desde tu PC y desde el móvil con datos (para verificar que sale de verdad a internet).
• Modificar la web y publicar los cambios usando un cliente gráfico (Visual Studio Code), entendiendo qué comandos está ejecutando por debajo.
• Diagnosticar cinco fallos típicos: olvidar git add, conflicto al hacer push contra un repo no vacío, Pages tarda en activarse, caché del navegador, cambios sin commit que se pierden.
• Documentar tu repositorio y su URL pública en una ficha técnica que entregarás al profesor.

0.1 - El problema que resuelve Git: el control de versiones

Antes de que existiera Git, casi todo el mundo guardaba sus proyectos así:

trabajo.docx
trabajo_v2.docx
trabajo_v2_final.docx
trabajo_v2_final_BUENO.docx
trabajo_v2_final_BUENO_(este_sí).docx

Esto es el control de versiones a mano, y todo el mundo lo ha hecho alguna vez. Funciona regular para un documento, fatal en cuanto entran dos personas a tocarlo, e imposible en cuanto se trata de un proyecto con cientos de archivos.

Un sistema de control de versiones (VCS, version control system) es un programa que automatiza esa idea de "guardar versiones", pero hecho en serio: guarda cada cambio que haces, con su autor, su fecha, una descripción de qué cambió y por qué, y te permite volver a cualquier versión anterior sin tener que mantener veinte copias del archivo. Y, sobre todo, deja que varias personas trabajen sobre lo mismo a la vez sin pisarse.

Git es el sistema de control de versiones más usado del mundo. Lo creó Linus Torvalds en 2005 para llevar el código del propio Linux. Hoy lo usa prácticamente cualquier proyecto de software, y muchos otros tipos de proyecto: documentación técnica, configuraciones de servidores, libros, recetas, contenido web. Cualquier cosa que sean archivos de texto.

0.2 - Git no es GitHub (y todos los confunden)

Esto es lo primero que hay que tener claro, porque la gente lo mezcla constantemente:

Una analogía que ayuda: Git es como Word (el programa que tienes en el PC para editar documentos), y GitHub es como OneDrive o Google Drive (un sitio en internet donde guardas y compartes esos documentos). Puedes usar Word sin OneDrive perfectamente. Y puedes usar Git sin GitHub también: tu repositorio local sigue siendo un repositorio Git completo. Lo que aporta GitHub es alojamiento, colaboración, control de issues, integración con servicios... y, en esta práctica, publicación web.

0.3 - Los cuatro conceptos de Git que tienes que entender

Olvídate del resto. Con estos cuatro ya puedes hacer el 95 % del trabajo:

Repositorio (repo)

Una carpeta que Git "vigila". Por dentro es una carpeta normal con tus archivos, más una subcarpeta oculta .git donde Git guarda toda la historia. Cuando haces git init sobre una carpeta, se crea ese .git y a partir de ahí esa carpeta es un repositorio. Borrar .git es lo único que devuelve la carpeta a su estado "tonto" (sin historial).

Commit

Una foto del repositorio en un instante. Cada commit lleva: el estado completo de los archivos en ese momento, quién lo hizo, cuándo, una descripción ("mensaje de commit") y un identificador único de 40 caracteres (un hash, normalmente se ven los 7 primeros, tipo 3a4ac0e). Un commit es inmutable: una vez hecho, queda ahí para siempre, y el historial es una cadena de commits unos detrás de otros.

Hacer un commit es el equivalente a "esto que tengo ahora me convence, guárdalo en el historial". Si más adelante todo se rompe, siempre puedes volver a cualquier commit anterior y recuperar exactamente cómo estaba el proyecto entonces.

Rama (branch)

Una línea de commits en paralelo. Por defecto hay una rama que se llama main (antes era master) y, en proyectos sencillos como este, no vas a usar otra. Las ramas son lo que permite que dos personas trabajen a la vez en cosas distintas sin pisarse, y se fusionan luego con merge. En esta práctica vamos a quedarnos sólo con main: ramas las verás cuando el proyecto sea más complejo.

Remoto (remote)

Una copia del repositorio que vive en otro sitio, normalmente en internet. El remoto típico se llama origin y es la dirección del repositorio en GitHub. Subir tus commits al remoto se llama push; bajar los commits que haya nuevos en el remoto se llama pull. Mientras no haces push, tu trabajo está sólo en tu PC; en cuanto haces push, está en GitHub y otros pueden verlo.

0.4 - El flujo de trabajo básico (el que vas a usar todo el rato)

Una y otra vez vas a hacer este ciclo:

El staging area (paso 2) confunde a todo el mundo al principio. La idea es que pueda haber muchos archivos cambiados a la vez pero tú quieras agruparlos en commits distintos. "Estos tres archivos los he tocado por el bug del menú; estos dos, por la mejora del login. Quiero dos commits separados". El git add es el que decide qué entra en el próximo commit.

Si todo lo cambiado tiene que entrar de golpe (que será tu caso casi siempre en esta práctica), puedes hacer git add . (un punto: "todo lo que hay en este directorio").

0.5 - Qué es GitHub Pages

GitHub Pages es un servicio gratuito de GitHub que sirve como página web pública cualquier repositorio que contenga HTML. Si tu repo tiene un index.html en la raíz, GitHub te da una URL del tipo:

https://tu-usuario.github.io/nombre-del-repo/

Y si el repositorio se llama exactamente tu-usuario.github.io (mismo nombre que tu usuario), GitHub lo trata como tu "sitio personal" y te lo sirve en la raíz, sin la parte del nombre del repo:

https://tu-usuario.github.io/

Esta es la URL que vas a conseguir en esta práctica. Es gratis, no requiere tarjeta, no requiere dominio propio, y la mantiene Microsoft: te vas a casa y la web sigue ahí. Limitaciones:

• Sólo sirve contenido estático: HTML, CSS, imágenes, JavaScript que se ejecuta en el navegador. No hay PHP ni base de datos: no puedes hacer un foro o un blog dinámico con esto solo.
• El repositorio que la sirve tiene que ser público (en la capa gratuita).
• Hay un límite blando de tamaño y tráfico (1 GB de repo, 100 GB de ancho de banda al mes). Para una web personal sobra dos órdenes de magnitud.

0.6 - Por qué hacemos esta práctica

Tres motivos profesionales, no académicos:

• Cualquier oferta de empleo técnico medio asume que tienes cuenta en GitHub. Pueden pedirte tu usuario en la propia entrevista para mirar qué tienes subido. Vacía es mejor que nada, pero con algo, aunque sea pequeño, es mucho mejor.
• Es la forma más profesional de tener un portfolio: una URL pública que enseñas en tu CV, mantenida sin coste, que puedes mejorar año tras año.
• Y en el día a día técnico, casi cualquier documentación de software (Docker, scripts de PowerShell, drivers, herramientas de diagnóstico) está en GitHub. Saber clonar un repo, leer un README y abrir un issue es vocabulario básico de la profesión.

0.7 - Metodología de la práctica

Necesitas dos programas en tu Windows: Git (el control de versiones en sí) y GitHub CLI (una herramienta que conecta tu Git con la web de GitHub sin que tengas que pelearte con contraseñas y tokens).

1.1 - Comprobar si ya están instalados

Abre PowerShell (Win+R, escribe powershell, Enter). Comprueba las dos versiones:

git --version
gh --version

Posibles respuestas:

1.2 - Instalar Git para Windows

La forma más limpia es con winget, el gestor de paquetes que ya trae Windows 11. En PowerShell:

winget install --id Git.Git -e --source winget

Acepta los avisos. Tarda un par de minutos. Cuando acabe, cierra y vuelve a abrir PowerShell (porque la variable PATH se actualiza al abrir consolas nuevas) y vuelve a probar:

git --version

Ahora debería responder con la versión instalada.

1.3 - Instalar GitHub CLI

Igual, con winget:

winget install --id GitHub.cli -e --source winget

Cierra y abre PowerShell otra vez. Comprueba:

gh --version

1.4 - Configurar tu identidad en Git

Git pone tu nombre y correo en cada commit que haces. No te identifica ante GitHub (eso lo hará el gh en la Parte 2), pero sí firma cada commit con esos datos. Tienes que configurarlos una sola vez en este PC, y se quedan guardados para siempre.

git config --global user.name "Nombre Apellido"
git config --global user.email "[email protected]"

Usa el mismo correo con el que te vas a registrar en GitHub en la Parte 2: así GitHub asociará automáticamente tus commits con tu cuenta y aparecerá tu avatar al lado de cada uno. Si pones otro correo, los commits saldrán como "anónimos" en GitHub aunque los hayas hecho tú.

Configura también que la rama por defecto se llame main (es el estándar moderno; las versiones viejas de Git la creaban con el nombre master y a veces da problemas con GitHub que asume main):

git config --global init.defaultBranch main

Comprueba tu configuración:

git config --global --list

Tienen que aparecer al menos user.name, user.email e init.defaultBranch=main.

La cuenta de GitHub te va a sobrevivir al curso. Vas a tener un usuario en internet con tu nombre, posiblemente para muchos años. Vale la pena dedicar 10 minutos a elegir bien el nombre y a configurar la seguridad como Dios manda.

2.1 - Elegir el nombre de usuario

El nombre de usuario en GitHub se ve en cada URL pública que generas. La URL de tu web va a tener tu nombre dentro:

https://tu-usuario.github.io/

Por eso conviene que sea profesional. Recomendaciones:

• Algo parecido a tu nombre real: juan-perez, jperez85, juan-perez-dev. Si tu nombre es muy común y está pillado, añade una sigla, una profesión o un número discreto.
• Letras, números y guion medio. Sin tildes, sin ñ, sin espacios.
• Evita los nombres de gaming, motes de instituto o referencias que dentro de cinco años te van a dar vergüenza si te miran un CV. Esto se va a ver en una entrevista de trabajo.
• Cambiarlo después se puede, pero rompe enlaces y es engorroso. Es mucho mejor pensarlo dos minutos ahora.

2.2 - Crear la cuenta

2.3 - Verificación en dos pasos (2FA): obligatoria

Desde 2023, GitHub exige activar la verificación en dos pasos para poder hacer push de código. Lo va a pedir antes o después, así que mejor configurarlo ya.

La 2FA significa que para entrar en tu cuenta hace falta tu contraseña y un código de un solo uso que cambia cada 30 segundos, generado por una app en tu móvil. Aunque alguien te robe la contraseña, no puede entrar sin tu móvil.

2.4 - Autenticar tu Windows ante GitHub con gh auth login

Ya tienes la cuenta. Ahora vamos a vincularla con tu PC para no tener que estar metiendo usuario y contraseña cada vez que subes algo. El truco moderno es la GitHub CLI: hace un flujo OAuth (el mismo que cuando "entras con Google" en una web cualquiera) y deja la sesión guardada en tu Windows.

En PowerShell:

gh auth login

gh te va a preguntar varias cosas, contesta así:

Te enseñará un código de un solo uso en la consola, tipo 1A2B-3C4D, y te dirá que pulses Enter para abrir el navegador. Pulsa Enter:

Comprueba que efectivamente quedaste logueado:

gh auth status

Tiene que decir algo del estilo "Logged in to github.com account tu-usuario" con un check verde.

Antes de tocar la web, vamos a ensayar el ciclo de Git en una carpeta tonta. Aquí lo importante es entender los comandos, no el contenido: trabajarás con tres notas en .txt para que veas el flujo en estado puro.

3.1 - Crear la carpeta de prácticas

3.2 - Convertir la carpeta en un repositorio Git

git init

Una sola línea. Git responde algo como "Initialized empty Git repository in C:/Proyectos/practica-git/.git/". Lo que ha pasado:

• Ha creado una subcarpeta oculta .git dentro de tu proyecto. Si activas "ver archivos ocultos" en el Explorador la verás. Ahí es donde Git guarda toda la historia y la configuración del repo.
• A partir de ahora esa carpeta es un repositorio Git. Cualquier comando git que ejecutes dentro entenderá que pertenece a este repo.
• Aún no hay ningún commit. La historia está vacía.

Comprueba el estado del repo recién creado:

git status

Te dice "On branch main", "No commits yet", "nothing to commit". Es decir: el repo existe, estás en la rama main, no hay historial, y de momento no hay archivos que registrar. Perfecto.

3.3 - Crear tu primer archivo

En VS Code, crea un archivo notas.txt (en el panel del Explorador del proyecto, botón derecho → New File) y escribe dentro algo cualquiera, por ejemplo:

Practica 36 - Git y GitHub
Esto es mi primera nota.

Guarda. Vuelve a la terminal:

git status

Ahora Git ya tiene algo que decir: aparece Untracked files y lista notas.txt. "He visto un archivo nuevo, pero no sé nada de él porque no lo has añadido".

Untracked ("sin seguir") significa que Git ve que el archivo existe pero no le está prestando atención todavía. Hasta que tú no le digas explícitamente "este archivo me interesa, sígueme los cambios", lo va a ignorar.

3.4 - Añadir al staging area y hacer el primer commit

git add notas.txt
git status

Ahora git status dice "Changes to be committed" y lista el archivo en verde. Está en el staging area: "esto entra en el próximo commit". Hagamos el commit:

git commit -m "Primer commit: notas iniciales"

Git responde con algo del estilo:

[main (root-commit) 3a4ac0e] Primer commit: notas iniciales
 1 file changed, 2 insertions(+)
 create mode 100644 notas.txt

Anota lo que aparece:

"root-commit" significa "es el primer commit del repositorio", no tiene padre detrás. A partir de ahora cada nuevo commit tendrá como padre al anterior.

Mira la historia:

git log

Aparece un solo commit con su hash completo (40 caracteres), tu nombre, tu correo, fecha y mensaje. Pulsa q para salir del visor.

3.5 - Ciclo completo: editar → add → commit (otra vez)

Edita notas.txt en VS Code, añade una línea más:

Practica 36 - Git y GitHub
Esto es mi primera nota.
Y esta es la segunda, anadida en otro commit.

Guarda. Ahora hay dos cosas interesantes que probar antes de hacer el commit:

git status
git diff

git status te dice "modified: notas.txt": ha visto que cambia pero todavía no le has dicho que añada el cambio al staging.

git diff te enseña el cambio en sí, línea a línea: en rojo lo eliminado, en verde lo añadido. Esta es la herramienta que más vas a usar para revisar tu propio trabajo antes de hacer commit, y es lo que te enseñará VS Code en la Parte 6 cuando uses el cliente gráfico.

Cierra el visor (q) y haz el ciclo:

git add notas.txt
git commit -m "Anadir segunda nota"

Y mira la historia ahora:

git log --oneline

--oneline es la forma compacta: un commit por línea, hash corto y mensaje. Ya tienes dos. Anótalos:

3.6 - Crear un segundo archivo y agruparlos con git add .

Crea dos archivos a la vez en la carpeta: ideas.txt y tareas.txt con cualquier contenido. git status los listará a los dos como untracked. En lugar de hacer dos git add, atajo:

git add .
git status

El punto significa "todos los cambios del directorio actual y subdirectorios". Los dos archivos están ahora en staging. Comítelos juntos:

git commit -m "Anadir ideas y tareas"

Y otra vez:

git log --oneline

Tres commits. Has hecho ya un mini-historial real.

3.7 - Limpiar (opcional)

Cuando termines de jugar con esta carpeta puedes borrarla entera y olvidarte. Para la práctica real (la web) usarás otra carpeta en la Parte 4.

Vamos a montar la web que después subirás a GitHub Pages. No es una práctica de diseño web: el objetivo es tener un index.html presentable, no que el resultado parezca una agencia de Madrid. La estructura está hecha; lo que cambia de un alumno a otro son los datos.

4.1 - Crear la carpeta del proyecto

El nombre de la carpeta da igual en local, pero conviene llamarla como vas a llamar al repositorio en GitHub. Como queremos que la URL final sea https://tu-usuario.github.io/ (sin la parte del nombre del repo), el repo se tiene que llamar exactamente tu-usuario.github.io. Por tanto:

4.2 - El archivo index.html

Crea un archivo index.html en la raíz de la carpeta con este contenido. Cambia las partes en MAYÚSCULAS por tus datos reales. Si quieres, modifica también colores, textos y enlaces; lo único que tiene que estar es la estructura mínima.

<!DOCTYPE html>
<html lang="es">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>TU NOMBRE - Tecnico informatico</title>
    <style>
        * { box-sizing: border-box; margin: 0; padding: 0; }
        body {
            font-family: -apple-system, "Segoe UI", Roboto, sans-serif;
            line-height: 1.6;
            color: #2d3748;
            background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
            min-height: 100vh;
            padding: 40px 20px;
        }
        .tarjeta {
            max-width: 700px;
            margin: 0 auto;
            background: white;
            border-radius: 16px;
            box-shadow: 0 20px 60px rgba(0,0,0,.3);
            overflow: hidden;
        }
        .cabecera {
            background: #1a365d;
            color: white;
            padding: 40px 32px;
            text-align: center;
        }
        .avatar {
            width: 120px;
            height: 120px;
            border-radius: 50%;
            background: #4a5568;
            margin: 0 auto 16px;
            display: flex;
            align-items: center;
            justify-content: center;
            font-size: 48px;
            font-weight: bold;
            color: white;
            border: 4px solid white;
        }
        .cabecera h1 { font-size: 28px; margin-bottom: 6px; }
        .cabecera p { opacity: .85; font-size: 16px; }
        .contenido { padding: 32px; }
        .contenido h2 {
            color: #1a365d;
            font-size: 20px;
            margin: 0 0 12px;
            padding-bottom: 8px;
            border-bottom: 2px solid #e2e8f0;
        }
        .contenido p { margin-bottom: 16px; font-size: 15px; }
        .enlaces {
            display: flex;
            gap: 12px;
            flex-wrap: wrap;
            margin-top: 24px;
        }
        .enlaces a {
            display: inline-block;
            padding: 10px 20px;
            background: #2b6cb0;
            color: white;
            text-decoration: none;
            border-radius: 6px;
            font-weight: 600;
            font-size: 14px;
            transition: background .2s;
        }
        .enlaces a:hover { background: #1a365d; }
        footer {
            text-align: center;
            padding: 20px;
            background: #f7fafc;
            color: #718096;
            font-size: 13px;
        }
    </style>
</head>
<body>
    <div class="tarjeta">
        <div class="cabecera">
            <div class="avatar">TN</div>
            <h1>TU NOMBRE Y APELLIDOS</h1>
            <p>Tecnico microinformatico en formacion</p>
        </div>
        <div class="contenido">
            <h2>Sobre mi</h2>
            <p>
                Soy alumno del certificado de profesionalidad IFCT0309
                (Montaje y reparacion de sistemas microinformaticos)
                en el centro CEDECO. Esta es mi primera web publicada
                en internet, y la estoy usando para aprender Git,
                GitHub y como funciona el control de versiones.
            </p>
            <h2>Lo que estoy aprendiendo</h2>
            <p>
                Montaje y diagnostico de hardware, instalacion y
                administracion de Windows y Linux, redes basicas,
                copias de seguridad, virtualizacion con VirtualBox
                y contenedores con Docker.
            </p>
            <h2>Donde encontrarme</h2>
            <div class="enlaces">
                <a href="https://github.com/TU-USUARIO">Mi GitHub</a>
                <a href="mailto:[email protected]">Escribirme</a>
            </div>
        </div>
        <footer>
            Hecho con HTML, Git y GitHub Pages - Practica 36
        </footer>
    </div>
</body>
</html>

4.3 - Probar la web en local (sin GitHub aún)

Antes de subirla, vamos a verla en el navegador para asegurarnos de que se ve bien. Abre el Explorador de Windows, ve a la carpeta del proyecto, y haz doble click en index.html. Se abre en el navegador. Verás tu web tal cual.

Comprueba:

• Aparece tu nombre, no "TU NOMBRE Y APELLIDOS".
• El círculo del avatar muestra tus iniciales (puedes editar el <div class="avatar">TN</div> y poner las que correspondan, por ejemplo JP para Juan Pérez).
• El botón de "Mi GitHub" enlaza a https://github.com/tu-usuario real, no a TU-USUARIO.
• El botón de "Escribirme" lleva a tu correo de verdad.

Si no se ve como esperas, edítalo en VS Code, guarda, y refresca el navegador (F5). Itera hasta que estés contento.

4.4 - Primer commit del proyecto

Con la web razonablemente lista, hacemos el primer commit en este repositorio:

git status
git add .
git commit -m "Version inicial de la web personal"
git log --oneline

Un commit en el historial. Estado:

4.5 - Mejora opcional: añadir un favicon

Esto no es obligatorio, pero es un detalle que da el pego. Un favicon es ese iconito que aparece en la pestaña del navegador. Si quieres añadir uno:

Hasta ahora todo lo que has hecho vive sólo en tu PC. Si se rompe el disco, lo pierdes. Ahora vas a subir el repositorio a GitHub y a activar Pages para que esa carpeta se sirva como web pública.

5.1 - Crear el repositorio en GitHub con gh

Podríamos crear el repo en la web de GitHub (botón "+" arriba a la derecha → New repository), pero como ya tienes gh instalado y autenticado, lo haces en una sola línea sin salir de la consola. Desde la terminal de VS Code, en la carpeta del proyecto:

gh repo create tu-usuario.github.io --public --source=. --remote=origin --push

Reemplaza tu-usuario por tu usuario real de GitHub. Explicación de cada parte:

• tu-usuario.github.io: el nombre del repo. Es imprescindible que coincida exactamente con tu usuario seguido de .github.io para que la URL final sea limpia (https://tu-usuario.github.io/).
• --public: lo crea público. GitHub Pages gratuito requiere repos públicos.
• --source=.: usa la carpeta actual como contenido inicial. El punto significa "el directorio donde estoy ahora".
• --remote=origin: configura el remoto y lo llama origin (el nombre estándar para el remoto principal).
• --push: hace el push de tus commits acto seguido. Es el equivalente a hacer git push -u origin main a mano.

Cuando termine, gh te dará la URL del repo en GitHub (algo como https://github.com/tu-usuario/tu-usuario.github.io). Ábrela en el navegador: tu index.html ya está ahí, junto con tu commit. Mira el historial pulsando en la pestaña Commits.

git remote -v

5.2 - Activar GitHub Pages

El repositorio existe en GitHub, pero Pages todavía no está activo: GitHub no sirve el contenido como web salvo que lo pidas explícitamente. Lo activas desde la web del repo:

Aparecerá un mensaje del estilo "Your site is live at https://tu-usuario.github.io/". Tarda entre 30 segundos y un par de minutos la primera vez (GitHub procesa el contenido y lo sirve por su CDN). Si entras antes de tiempo verás un 404. Espera, refresca y aparecerá.

5.3 - Comprobar que sale a internet de verdad

Ver la URL en tu PC del aula no demuestra del todo que esté en internet: si tuvieras un servidor web en local, también responderías. La prueba real es verla desde una red distinta.

5.4 - Inspeccionar el commit en GitHub

Vuelve al repo en GitHub. Haz click en el último commit (arriba a la derecha de la lista de archivos, donde pone el mensaje del último commit + el hash corto). Verás:

• Tu avatar y nombre al lado (si configuraste el mismo correo en la Parte 1.4). Si en lugar de tu avatar sale un cuadrado de colores genérico, es que tu correo de Git no coincide con el de GitHub: revisa git config --global user.email.
• El diff del commit: las líneas añadidas en verde, las eliminadas en rojo, igual que git diff en consola.
• El hash completo del commit. Compáralo con el que viste en git log: tiene que ser idéntico. Es la misma foto, no una copia ni una sincronización rara.

Ya sabes hacer el ciclo en consola. Ahora vas a hacer lo mismo desde el panel Source Control de VS Code, que es el cliente gráfico de Git más usado de la profesión. La idea de esta parte es que veas que "lo gráfico" es exactamente los mismos comandos que ya conoces, sólo con botones por encima.

6.1 - Abrir el panel Source Control

En VS Code, mira la barra de iconos a la izquierda (la activity bar). Hay un icono con forma de rama o tres puntos conectados; es Source Control. También se abre con Ctrl + Shift + G.

Al abrirlo verás:

• Arriba, un campo de texto vacío para el mensaje del commit.
• Debajo, un botón "Commit" que ahora mismo no hace nada porque no hay cambios pendientes.
• Más abajo, dos secciones (Changes y Staged Changes) que también están vacías por el mismo motivo.

6.2 - Hacer un cambio en la web

Abre index.html en VS Code. Cambia algo visible. Por ejemplo, modifica el texto del subtítulo bajo tu nombre:

<p>Alumno IFCT0309 - Promocion 2026</p>

O añade una nueva sección al final del bloque .contenido, antes del </div> que cierra esa caja, con algún hobby tuyo:

<h2>Aficiones</h2>
<p>
    Cuando no estoy delante del PC, me gusta...
</p>

Guarda. Pasa al panel Source Control. Ahora:

• Aparece index.html bajo Changes con una "M" amarilla a la derecha (Modified).
• Si haces click en el archivo, VS Code te abre la vista de diff lado a lado: a la izquierda la versión del último commit, a la derecha lo que has cambiado. Las líneas nuevas en verde, las quitadas en rojo. Esto es exactamente lo que verías con git diff en consola, presentado en visual.

6.3 - Hacer el commit desde la interfaz

Comprueba en la terminal de VS Code:

git log --oneline

Aparece tu nuevo commit arriba del todo. Lo has hecho con clicks, pero por debajo VS Code ha ejecutado los mismos git add y git commit que harías a mano.

6.4 - Subir los cambios con un botón

El commit está en local, pero la web pública sigue mostrando la versión anterior porque no has hecho push todavía. En el panel Source Control:

• Verás que el botón que antes ponía "Commit" ahora pone "Sync Changes" con un número (los commits que tienes en local pero no en el remoto: debería ser 1).
• Pulsa Sync Changes. VS Code hace un git push (y un git pull antes, por si hubiera cambios remotos).
• El número desaparece. Tu commit ya está en GitHub.

Si quieres ver el equivalente puro de push (sin pull previo), abre el menú "..." arriba del panel Source Control y elige Push. Hace exactamente git push. Como en consola.

6.5 - Ver el cambio reflejado en la web pública

Vuelve a tu URL pública https://tu-usuario.github.io/ en el navegador. Refresca con Ctrl+F5 para forzar que el navegador no use caché. Pueden pasar dos cosas:

Cuando aparezca, ya tienes el ciclo completo de Git+GitHub+Pages: editar → commit gráfico → sync → web actualizada.

6.6 - GitHub Desktop (mención breve)

Si en algún momento prefieres una app dedicada para Git (separada del editor), existe GitHub Desktop, gratuito, hecho por GitHub. Misma idea que Source Control pero con su propia ventana. Para esta práctica no hace falta: tienes ya VS Code y va de sobra. Pero conviene saber que está, por si en otro PC no tienes VS Code instalado y quieres apañarte rápido.

La mejor forma de entender una herramienta es ver lo que pasa cuando algo va mal. En esta parte vas a provocar a propósito cinco errores muy comunes con Git y GitHub Pages, y vas a aprender a salir de cada uno.

Caso A - "He editado el archivo pero el commit sigue saliendo igual"

Provoca el fallo:

Qué pasa: Git responde algo como "Changes not staged for commit" o "nothing to commit, working tree clean", y no hace el commit. Sí, tu archivo está modificado. Sí, lo has guardado. Pero Git no se entera de los cambios si no los añades al staging primero.

Diagnóstico: git status te dice claramente "Changes not staged for commit". Es el síntoma de que olvidaste el git add.

Cómo arreglarlo:

git add index.html
git commit -m "Cambio en el footer"

O directamente, atajo: git commit -am "..." hace add + commit en una sola línea, pero sólo para archivos ya seguidos por Git (no funciona para archivos nuevos).

Caso B - "El push da un error de 'updates were rejected'"

Este lo provocarás a mano simulando que tienes el repo desfasado respecto al remoto.

Provoca el fallo:

Qué pasa: Git rechaza el push con un mensaje del estilo:

! [rejected]        main -> main (fetch first)
error: failed to push some refs to '...'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally.

Diagnóstico: hay un commit en el remoto que tú no tienes en local. Git no quiere sobrescribirlo de un manotazo, te avisa.

Cómo arreglarlo: baja primero los cambios remotos y luego haz push:

git pull --rebase
git push

El --rebase coge los commits remotos, los pone debajo de los tuyos, y reorganiza la historia para que quede limpia. Comprueba el resultado con git log --oneline: tendrás ambos commits, en orden.

Caso C - "Mi web da 404 aunque la URL parece correcta"

Posibles causas y cómo descartarlas, en orden:

1. Pages todavía no ha hecho el primer despliegue. Sólo si acabas de activarlo. Espera 2-3 minutos. En Settings → Pages tiene que aparecer "Your site is live at..." con un check verde.
2. El nombre del repo no coincide con tu-usuario.github.io. Si lo llamaste de otra forma (por ejemplo mi-web), la URL tiene el nombre del repo dentro: https://tu-usuario.github.io/mi-web/. No es 404, es que estás mirando la URL equivocada.
3. El archivo no se llama index.html exactamente, sino algo como Index.html (mayúscula) o index.htm sin la "l" final. GitHub Pages distingue mayúsculas y minúsculas y sólo sirve por defecto index.html.
4. El index.html no está en la raíz del repo sino en una subcarpeta. Pages, configurado con "/ (root)", sólo mira la raíz.
5. Source no está bien configurada en Settings → Pages. Asegúrate de que pone Deploy from a branch → main → / (root).

Cómo arreglarlo: identifica el caso y corrige según corresponda. Si el archivo está mal nombrado, renómbralo en VS Code (no basta con copiar uno nuevo: tienes que borrar el viejo del repo) y haz un commit + push. Si el archivo no está en la raíz, muévelo a la raíz y commitea el movimiento.

Caso D - "Hice push pero la web sigue mostrando lo viejo"

Provoca / observa: tras un push, recarga la URL pública sin Ctrl+F5. Verás todavía el contenido anterior en muchos casos.

Diagnóstico: son dos cachés distintas en cadena. Tu navegador guarda copia local de la página (caché del navegador) y, además, GitHub sirve a través de su propia red CDN, que también cachea durante un rato corto.

Cómo verificarlo bien:

• Refresca con Ctrl + F5 (recarga sin caché del navegador).
• Abre la URL en una ventana de incógnito (Ctrl + Shift + N en Chrome / Edge). Esa ventana arranca sin caché.
• Ábrela en el móvil con datos: caché distinta.
• Si aun así no aparece el cambio, comprueba en GitHub (pestaña Actions o Settings → Pages) que el último despliegue de Pages terminó después del commit que quieres ver. Si pone "deployed 2 minutes ago" y tu commit es de hace 30 segundos, el despliegue siguiente está pendiente: espera otro minuto.

Caso E - "He cambiado código pero no he hecho commit; ¿puedo volver atrás?"

Provoca el fallo: en VS Code, edita index.html y carga el archivo a saco con texto malo. Por ejemplo, borra todo el contenido del <body>. No guardes todavía.

Si ahora cierras VS Code sin guardar, no pasa nada: el archivo en disco sigue como estaba. Pero supongamos que sí lo guardas (Ctrl+S) por error. Ahora el archivo en disco está roto.

Cómo recuperarlo (lo bueno de Git):

git status
git restore index.html

git restore sobrescribe el archivo en tu carpeta de trabajo con la versión del último commit. Como tu último commit estaba bien, la edición desastrosa desaparece. Refresca el navegador o vuelve a abrir el archivo en VS Code: vuelve a estar la versión buena.

Última parte de la práctica: documentar tu repositorio para que cualquiera pueda encontrarlo y para tener un registro de lo que has hecho.

8.1 - Añadir un README al repositorio

Cuando alguien entra en tu repo en GitHub, lo primero que GitHub le muestra debajo de la lista de archivos es el contenido de un archivo llamado README.md si existe. Es la portada del repo. Vamos a ponerle una.

# TU NOMBRE - Web personal

Web personal hecha como parte de la **Practica 36** del curso
IFCT0309 (Montaje y reparacion de sistemas microinformaticos) en CEDECO.

## URL publica

https://tu-usuario.github.io/

## Que aprendi haciendo esto

- Que es Git y como funciona el control de versiones
- Crear repositorios y hacer commits desde consola
- Crear y configurar una cuenta en GitHub con 2FA
- Subir un proyecto a GitHub con `gh repo create`
- Activar GitHub Pages y servir HTML estatico como web publica
- Editar y publicar cambios con el panel Source Control de VS Code

## Tecnologias

HTML, CSS, Git, GitHub, GitHub Pages.

Markdown es muy sencillo: # es título principal, ## es subtítulo, los guiones son listas, los **asteriscos** son negrita. GitHub lo renderiza solo cuando alguien entra en el repo.

Commit + push:

git add README.md
git commit -m "Anadir README"
git push

Refresca tu repo en GitHub: debajo de la lista de archivos, ahora aparece la portada con tu nombre y la URL pública.

8.2 - Ficha técnica de la entrega

8.3 - Preguntas para fijar conceptos