Ruta Full Stack
0✦ 0
Proyectos · Fase 1

P01 · Tu repositorio de aprendizaje

Entregable: Repositorio privado ~/Work/taller en GitHub, con historial, ramas, issue, PR y CLAUDE.mdTiempo: 6-8 h, repartidas en las sesiones 2 a 6
0 de 13 casillas

El encargo

Tu primer cliente eres tú. Necesitas un sitio donde practicar sin miedo a romper nada, que se quede guardado en la nube, y donde Claude pueda trabajar contigo bajo tus reglas.

Alcance

Incluye: configurar Git, crear ~/Work/taller, commits, diff, deshacer, ramas, un conflicto provocado, GitHub (push, pull, issue, pull request) y Claude Code con tu CLAUDE.md. No incluye: programar nada. Los archivos de este repositorio son Markdown: lo que se practica es el taller, no el código.

Parte 0 · Preparar Git (sesión 2 · 10 min)

Tres ajustes que se hacen una vez en la vida. Antes de ejecutar cada uno, léelo:

git config --global init.defaultBranch main
git config --global core.editor "code --wait"
git config --global --list
  1. Que los repositorios nuevos empiecen en la rama main (ahora mismo tu Git usa master, el nombre antiguo). → rama
  2. Que cuando Git necesite que escribas algo (un mensaje de merge, por ejemplo), abra VS Code y espere a que cierres la pestaña, en lugar de Neovim dentro de la terminal.
  3. Ver tu configuración. Comprueba que aparecen tu user.name y tu user.email: son la firma de cada commit.

Parte 1 · El taller en la terminal (sesión 2 · 30 min)

cd ~/Work
pwd
mkdir taller
cd taller
pwd
mkdir notas
touch README.md notas/comandos.md
ls -la
  • Antes de cada comando, di qué va a pasar. Después, comprueba con pwd o ls que ha pasado.
  • Abre la carpeta en el editor: code .
  • En README.md escribe, en Markdown: un título (# Mi taller), una frase de qué es este repositorio, y una lista con las 15 fases del roadmap (solo los nombres).
  • En notas/comandos.md: los comandos de la tabla del apartado 4.2 de la Fase 1, explicados con tus palabras.

Parte 2 · Primeros commits, diff y deshacer (sesión 3 · 1 h)

Convertir la carpeta en repositorio:

git init
git status

Lee lo que dice git status: dos archivos en rojo, untracked (Git los ve, pero no los sigue).

Primer commit:

git add README.md
git status
git commit -m "Añade README inicial"
git status

Fíjate en cómo cambia git status en cada paso: rojo → verde → limpio. Eso son los tres estados del apartado 4.6.

Segundo commit:

git add notas/comandos.md
git commit -m "Añade chuleta de comandos de terminal"
git log --oneline

Ver un diff: cambia una línea del README en VS Code y guarda. Entonces:

git status
git diff

Rojo lo que quitaste, verde lo que pusiste. Ahora míralo también en VS Code (panel Control de código fuente → clic en el archivo). Haz commit con un mensaje que describa el cambio.

Deshacer (el ejercicio más importante de esta parte):

  1. Borra la mitad del README y guarda. Ábrelo: está destrozado.
  2. git status → modified. git diff → todo en rojo.
  3. git restore README.md
  4. Abre el README: está intacto.

Acabas de ver tu red de seguridad funcionando. Repítelo hasta que te parezca aburrido.

Parte 3 · Ramas y un conflicto provocado (sesión 4 · 1 h)

Una rama sin conflicto:

git switch -c idea-objetivos

Añade al README una sección ## Mis objetivos con tres objetivos tuyos (freelance, empleo, SaaS). Commit. Después:

git switch main

Abre el README: la sección no está. Vive en la otra rama. Ahora:

git merge idea-objetivos
git log --oneline
git branch -d idea-objetivos

Un conflicto a propósito:

  1. En main, cambia la primera frase del README a "Mi taller de prácticas de desarrollo web". Commit.
  2. git switch -c otra-frase. Cambia la misma frase a "Aquí aprendo a dirigir a la IA". Commit.
  3. git switch main y git merge otra-frase.
  4. Conflicto. Abre el README en VS Code: verás las dos versiones marcadas con <<<<<<<, ======= y >>>>>>>, y botones encima.
  5. Elige una (o escribe una mezcla), guarda, y:
git add README.md
git commit

Se abrirá VS Code con el mensaje de merge ya escrito (gracias a la parte 0). Cierra la pestaña y el commit se completa.

Parte 4 · GitHub (sesión 5 · 1,5 h)

Crear el repositorio remoto (privado) y subir todo:

gh auth status
gh repo create taller --private --source=. --remote=origin --push
git remote -v
gh repo view --web

El tercer comando hace tres cosas a la vez: crea el repositorio en GitHub, lo registra como remoto llamado origin y sube tus commits. En el navegador, mira: tu README aparece como portada.

Bajar un cambio hecho fuera (pull):

  1. En GitHub, edita el README desde la web (icono del lápiz): añade una línea al final. Confírmalo con Commit changes.
  2. En tu terminal: git pull. Abre el README: tienes el cambio.

Un issue cerrado desde un commit:

gh issue create --title "Añadir sección de recursos al README" --body "Enlazar los tres recursos que más uso."

Apunta el número que te da (será el #1). Haz el cambio en el README y:

git add README.md
git commit -m "Añade sección de recursos (closes #1)"
git push
gh issue list --state all

El issue aparece cerrado y enlazado al commit.

Un pull request:

git switch -c mejora-notas

Mejora notas/comandos.md (añade los tres errores típicos de la terminal). Commit, y:

git push -u origin mejora-notas
gh pr create --fill
gh pr view --web

En el navegador, mira la pestaña Files changed: es el diff presentado para revisión. Pulsa Merge pull request. Después, en la terminal:

git switch main
git pull
git branch -d mejora-notas

Parte 5 · Claude Code con tus reglas (sesión 6 · 1,5 h)

Tu CLAUDE.md, escrito por ti. Crea CLAUDE.md en la raíz del taller. Usa esto como punto de partida, pero cámbialo con tus palabras:

# Contexto
Soy principiante absoluto aprendiendo desarrollo web full stack (Fase 1 de mi roadmap).
Este repositorio es mi taller de prácticas: no hay código, solo notas en Markdown.

# Cómo quiero que trabajes
- Responde en español.
- Antes de cambiar nada, dime qué vas a hacer y por qué.
- Explica en una línea cada comando que propongas.
- No hagas commits, push ni ningún comando de Git: los hago yo.
- No uses sudo ni borres archivos sin preguntarme.
- Una cosa cada vez: cambios pequeños.

Commit: git commit -m "Añade CLAUDE.md con mis reglas de trabajo" (después del git add, claro).

Arrancar Claude en el sitio correcto:

cd ~/Work/taller
git status
claude

git status tiene que decir que todo está limpio. Esa es tu red.

Ronda 1 · Solo leer. Pídele:

Explícame qué hay en este repositorio y qué es cada archivo. No cambies nada.

Comprueba que ha respetado tu CLAUDE.md (idioma, no tocar nada).

Ronda 2 · Un cambio bueno. Pídele:

Añade a notas/comandos.md una sección con los 4 comandos de Git que más voy a usar y una línea explicando cada uno.

Cuando termine, sal de Claude o abre otra terminal y aplica el ciclo de seguridad:

git status
git diff

¿Ha tocado solo ese archivo? ¿Entiendes cada línea? ¿Es correcto lo que explica? Si sí: git add y commit tú.

Ronda 3 · Un cambio malo, a propósito. Pídele:

Reescribe el README entero en inglés y crea un archivo notas/ideas.md con diez ideas de proyectos.

Cuando termine:

git status

Verás el README modified y notas/ideas.md como untracked. Ahora deshaz todo:

git restore README.md
git clean -n

git clean -n solo enseña lo que borraría. Si la lista es exactamente notas/ideas.md, ejecuta git clean -fd. Después:

git status

Limpio. El README, en español, como estaba. Esto es lo que hará posible todo lo demás del roadmap.

Parte 6 (opcional, muy recomendable) · Versionar este vault

Tus apuntes merecen la misma red de seguridad, y una copia en la nube. Desde la terminal:

cd ~/Documents/web-development
pwd

Crea un archivo .gitignore en el vault con estas líneas (lo que Obsidian cambia constantemente y no aporta nada):

.obsidian/workspace.json
.obsidian/workspace-mobile.json
.trash/

Y:

git init
git add .
git commit -m "Vault inicial: roadmap, fases 0-1 y glosario"
gh repo create apuntes-fullstack --private --source=. --remote=origin --push

Criterios de aceptación

  • Git configurado: rama inicial main, editor VS Code, nombre y email visibles
  • ~/Work/taller creado desde la terminal, fuera del vault
  • He deshecho un destrozo con git restore y sé explicar qué ha pasado
  • Un merge con conflicto provocado y resuelto por mí
  • Repositorio privado en GitHub, con el README como portada
  • Un cambio hecho en la web de GitHub y traído con git pull
  • Un issue cerrado automáticamente desde un commit
  • Un pull request abierto, revisado en Files changed y fusionado
  • CLAUDE.md escrito con mis palabras, y Claude lo ha respetado
  • Un cambio de Claude revisado con git diff y confirmado por mí
  • Un cambio malo de Claude deshecho, incluido un archivo nuevo, sin perder nada
  • Al menos 6 commits con mensajes que explican qué cambió (git log --oneline)
  • (Opcional) El vault versionado en un repositorio privado

Cómo delegarlo (y qué no)

Sí: pedir explicaciones de cualquier comando o error, con los prompts de la Fase 1 (apartado 7) o de Prompts para Claude. Y, en la parte 5, los tres encargos de las rondas.

No: que Claude ejecute los comandos de Git por ti en este proyecto. Si te lo propone, dile que no: es justo lo que estás aprendiendo.

Cómo verificar que está bien

  1. git log --oneline → ¿cada mensaje se entiende sin abrir el commit?
  2. gh repo view --web → ¿dice Private? ¿Se ve bien el README?
  3. Tapa la nota y explica en voz alta el ciclo de seguridad de la ronda 3, incluido por qué hicieron falta dos comandos distintos para deshacerlo todo.

Qué has aprendido al terminarlo

(Rellénalo tú en 3-4 líneas.)