Git y GitHub

¿Alguna vez guardaste archivos como final.html, final2.html, final-ahora-si.html? Git resuelve ese caos. Es el sistema de control de versiones que usan prácticamente todos los equipos de desarrollo del mundo, y GitHub es la plataforma donde se guardan y comparten esos proyectos. En esta lección irás desde cero hasta trabajar con ramas y pull requests.

Concepto

• Git es un programa que se instala en tu computadora y guarda "fotografías" (commits) de tu proyecto a lo largo del tiempo. Puedes volver a cualquier foto, comparar cambios y trabajar en paralelo sin pisar el trabajo de otros.
• GitHub (o GitLab, Bitbucket) es un sitio web que aloja tus repositorios Git en la nube: respaldo, colaboración, portafolio y despliegue.

Analogía

Git es como el historial de un videojuego con puntos de guardado. Si te equivocas, cargas la partida guardada. Las ramas son partidas paralelas: pruebas un camino arriesgado sin perder tu partida principal.

Las tres zonas de Git

 Directorio de trabajo  ──git add──▶  Staging (área de preparación)  ──git commit──▶  Repositorio (historial)
   (tus archivos)                       (lo que irá en la foto)                         (fotos guardadas)

Instalación y configuración

• Windows: descarga de git-scm.com. Incluye Git Bash. Deja las opciones por defecto, pero elige VS Code como editor.
• Mac: ejecuta git --version; si no está, macOS te ofrecerá instalarlo. O usa brew install git.
• Linux: sudo apt install git (Debian/Ubuntu) o sudo dnf install git (Fedora).

Configura tu identidad una sola vez (usa el mismo correo que en GitHub):

git config --global user.name "Tu Nombre"
git config --global user.email "tu@correo.com"
git config --global init.defaultBranch main
git config --global core.editor "code --wait"

# Verifica
git config --list

Tu primer repositorio

# 1. Entra a la carpeta del proyecto
cd ~/Documents/landing-cafeteria

# 2. Convierte la carpeta en repositorio (crea una carpeta oculta .git)
git init

# 3. Mira el estado: archivos en rojo = sin seguimiento
git status

# 4. Prepara los archivos (staging)
git add index.html        # uno en particular
git add .                 # todos los cambios

# 5. Guarda la foto con un mensaje descriptivo
git commit -m "Estructura inicial de la landing"

# 6. Ver el historial
git log --oneline

Ciclo diario: editar → git status → git add → git commit.

Comandos para revisar y deshacer

git diff                     # qué cambió (aún sin add)
git diff --staged            # qué cambió (ya con add)
git restore archivo.html     # descarta cambios no guardados de un archivo
git restore --staged archivo.html  # lo saca del staging (no pierde cambios)
git commit --amend -m "Nuevo mensaje"  # corrige el último commit (si no lo subiste)
git revert abc123            # crea un commit que deshace el commit abc123
git log --oneline --graph --all    # historial visual con ramas

Error común

Usar git reset --hard sin entenderlo: borra cambios de forma permanente. Para deshacer algo que ya subiste a GitHub, usa git revert, que es seguro porque no reescribe el historial.

.gitignore: lo que no se sube

Crea un archivo .gitignore en la raíz con lo que Git debe ignorar:

# Dependencias (se reinstalan con npm install)
node_modules/

# Variables de entorno con contraseñas y claves
.env

# Archivos generados
dist/
build/

# Sistema operativo y editores
.DS_Store
Thumbs.db
.vscode/

Nunca subas secretos

Contraseñas, claves de API o el archivo .env jamás deben llegar a GitHub. Hay bots que escanean repositorios públicos buscando claves en minutos. Si subiste una por error, cámbiala inmediatamente: borrarla del repositorio no es suficiente.

Mensajes de commit profesionales

Un buen mensaje explica qué y por qué, en presente e imperativo. Muchos equipos usan Conventional Commits:

feat: agrega formulario de contacto
fix: corrige menú que no cerraba en móvil
style: ajusta espaciado del footer
refactor: separa estilos del header en su propio archivo
docs: actualiza instrucciones del README
chore: actualiza dependencias

Haz commits pequeños y frecuentes: uno por cada cambio lógico, no uno gigante al final del día.

GitHub: subir tu proyecto

1. Crea una cuenta en github.com.
2. Botón New repository → nombre (landing-cafeteria) → sin README (ya tienes archivos) → Create.
3. Conecta tu repositorio local y súbelo:

git remote add origin https://github.com/tu-usuario/landing-cafeteria.git
git branch -M main
git push -u origin main

La primera vez te pedirá autenticarte; el navegador abrirá una ventana para iniciar sesión (Git Credential Manager). En Mac/Linux, la opción recomendada es configurar una llave SSH (GitHub tiene una guía oficial: "Generating a new SSH key").

Después, para subir nuevos commits basta con:

git push

Clonar y actualizar

git clone https://github.com/usuario/proyecto.git   # descarga un repositorio
git pull                                            # trae los cambios nuevos del remoto

Ramas (branches)

Una rama es una línea de trabajo independiente. La rama principal se llama main y debe contener siempre código que funciona. Para cada funcionalidad nueva crea una rama:

git branch                       # lista ramas (* = actual)
git switch -c feature/galeria    # crea una rama y cámbiate a ella
# ... editas, haces add y commit ...
git switch main                  # vuelves a main
git merge feature/galeria        # integras los cambios de la rama
git branch -d feature/galeria    # borras la rama ya integrada

main:      A───B───────────E (merge)
                \         /
feature:         C───D───┘

Conflictos de merge

Si dos ramas modificaron la misma línea, Git no sabe cuál conservar y marca un conflicto:

<<<<<<< HEAD
<h1>Bienvenidos a Café Aroma</h1>
=======
<h1>El mejor café de la ciudad</h1>
>>>>>>> feature/nuevo-titulo

Para resolverlo:

1. Abre el archivo (VS Code muestra botones: Accept Current, Accept Incoming, Accept Both).
2. Deja el contenido final correcto y borra las marcas <<<<<<<, =======, >>>>>>>.
3. git add archivo.html y git commit.

Pull requests: colaborar como profesional

Un pull request (PR) es una propuesta para integrar una rama en main, que otros pueden revisar y comentar antes de aceptarla. Flujo típico en un equipo:

# 1. Actualiza main
git switch main
git pull

# 2. Crea tu rama
git switch -c fix/menu-movil

# 3. Trabaja y haz commits
git add .
git commit -m "fix: cierra el menú al tocar un enlace en móvil"

# 4. Sube la rama a GitHub
git push -u origin fix/menu-movil

5. En GitHub aparece el botón Compare & pull request. Escribe un título y una descripción (qué cambia, cómo probarlo, capturas si es visual).
6. Un compañero revisa, comenta o aprueba.
7. Se hace Merge y se borra la rama.
8. Localmente: git switch main y git pull.

Para contribuir a proyectos ajenos se usa un fork (tu copia del repositorio en tu cuenta) y se abre el PR desde ahí.

Buena práctica

Aunque trabajes solo, usa ramas y pull requests en proyectos de clientes. Tendrás un historial claro de qué se cambió y cuándo, y podrás revertir una funcionalidad completa si algo sale mal.

GitHub como herramienta profesional

• README.md: describe el proyecto, cómo instalarlo y ejecutarlo. Es lo primero que ven los reclutadores.
• GitHub Pages: publica sitios estáticos gratis (Settings → Pages → rama main).
• Issues: lista de tareas y errores.
• Repositorios privados: gratis e ilimitados; úsalos para proyectos de clientes.
• Tu perfil: es tu portafolio. Sube tus proyectos de práctica.

Ejercicios

1. Configura Git con tu nombre y correo.
2. Crea un repositorio local con un index.html, haz tres commits con mensajes descriptivos y míralos con git log --oneline.
3. Crea una rama feature/footer, añade un footer, haz commit, vuelve a main y haz merge.
4. Sube el proyecto a GitHub y publícalo con GitHub Pages.
5. Provoca un conflicto a propósito: cambia el mismo h1 en dos ramas distintas e intégralas. Resuélvelo.

Ver solución

# 2
mkdir practica-git && cd practica-git
git init
echo "<h1>Hola</h1>" > index.html
git add . && git commit -m "feat: agrega página inicial"
echo "<p>Bienvenido</p>" >> index.html
git add . && git commit -m "feat: agrega párrafo de bienvenida"
echo "<footer>2026</footer>" >> index.html
git add . && git commit -m "feat: agrega pie de página"
git log --oneline

# 3
git switch -c feature/footer
# edita el footer en index.html
git add . && git commit -m "feat: mejora el footer"
git switch main
git merge feature/footer
git branch -d feature/footer

# 4 (tras crear el repo vacío en GitHub)
git remote add origin https://github.com/tu-usuario/practica-git.git
git push -u origin main
# Luego en GitHub: Settings → Pages → Branch: main → Save

# 5
git switch -c titulo-a
# cambia el h1 a "Título A", commit
git switch main
# cambia el h1 a "Título B", commit
git merge titulo-a      # ¡conflicto!
# edita el archivo, elige el contenido final, borra las marcas
git add index.html
git commit -m "fix: resuelve conflicto del título"

Resumen

• Git guarda el historial de tu proyecto en commits; GitHub lo aloja en la nube.
• Ciclo básico: git status → git add → git commit → git push.
• .gitignore evita subir node_modules, .env y archivos generados. Nunca subas secretos.
• Las ramas permiten trabajar en paralelo; merge las integra.
• Los conflictos se resuelven editando el archivo y haciendo un nuevo commit.
• Los pull requests son la forma profesional de revisar e integrar cambios.

Siguiente: Estructura de un proyecto web.