El día que arranca tu proyecto arranca tu repositorio. Flujo mínimo de Git, commits que puedes defender, y tu proyecto en línea desde hoy.
Etiquetas
Por qué esta clase existe
Tu proyecto integrador se califica con el resultado y con tu historial de Git. En la defensa final voy a abrir tus commits y a preguntarte por uno de ellos. Sería injusto evaluarte en algo que nunca te enseñé — así que hoy lo aprendes, justo el día que tu proyecto arranca.
Pero el motivo real no es la calificación. Git es lo que hace que puedas volver atrás cuando algo se rompe, y en la era de la IA eso importa más que nunca: cuando integras código generado y la app deja de funcionar, la diferencia entre "reviso qué cambió en el último commit" y "borro todo y empiezo de nuevo" es exactamente esta clase.
Git no es "subir archivos"
La confusión más común: pensar que Git es un Google Drive para código. No lo es. Git guarda una secuencia de cambios, no una carpeta.
- Google Drive te dice cómo se ve tu proyecto hoy.
- Git te dice cómo llegó a verse así, paso por paso, y te deja regresar a cualquier punto.
Por eso tu historial cuenta una historia. Y por eso un historial de dos commits gigantes la noche anterior no cuenta ninguna.
El flujo mínimo
Solo necesitas cuatro comandos para todo el semestre (están en el primer snippet). El ciclo es siempre el mismo:
git status— antes de cualquier cosa. Te dice qué archivos cambiaron. Si no lo usas, commiteas a ciegas.git add— eliges qué entra en este commit. No todo lo que cambiaste tiene que ir junto.git commit -m "..."— congelas ese conjunto de cambios con un mensaje que lo describe.git push— lo subes a GitHub. En tu proyecto, esto además dispara el deploy.
Qué es "un commit"
Un commit debe ser un cambio con sentido propio: algo que puedas describir en una frase sin usar la palabra "y".
- ✅
agrega validación de email al formulario de registro - ✅
corrige el cálculo del total cuando hay descuento - ❌
agrega validación y arregla el header y cambia colores← son tres commits
¿Por qué importa? Porque si mañana el total del carrito sale mal, quieres poder revertir solo ese cambio, no perder también el header y los colores.
La regla práctica del curso: mínimo 3 commits por semana. No es una cuota burocrática — es el ritmo natural de trabajar por partes. Si en una semana solo tienes un commit gigante, es señal de que trabajaste todo la noche anterior.
.gitignore: lo que nunca debe entrar
Hay dos categorías de archivos que jamás van al repositorio:
1. Lo que se regenera — node_modules/, dist/, build/. Son cientos de megas que cualquiera reconstruye con npm install. Subirlos hace tu repo lentísimo y tus diffs ilegibles.
2. Los secretos — .env, llaves de API, contraseñas. Esto es lo serio.
⚠️ Un archivo que entra al historial se queda ahí para siempre. Borrarlo después NO lo elimina del pasado: sigue visible en los commits anteriores. Si subes una llave de API por accidente, la única solución real es revocarla y generar una nueva — asume que ya se filtró. Hay bots escaneando GitHub que encuentran llaves públicas en minutos.
Por eso el .gitignore se crea antes del primer commit, no después.
Cuando algo se rompe
Antes de borrar la carpeta y volver a empezar (todos lo hemos hecho), prueba los tres salvavidas del último snippet: git log para ver qué hiciste, git diff para ver qué cambiaste, git restore para descartar cambios que no has commiteado.
Y si necesitas deshacer algo que ya subiste: git revert, que crea un commit nuevo revirtiendo el anterior. Deja registro honesto de que te arrepentiste — que es exactamente lo que quieres en un historial que vas a defender.
Deploy: tu proyecto en línea desde hoy
No esperes al final del semestre para desplegar. Despliega hoy, con el proyecto casi vacío, y deja que cada push lo actualice solo. Así el deploy nunca es un problema de última hora, y desde la semana 9 tienes un link que puedes enseñar.
Si tu proyecto es web
Vercel (o Netlify) se conecta a tu repo de GitHub y reconstruye el sitio en cada push a main. Configuración típica: entras con tu cuenta de GitHub, eliges el repositorio, aceptas los valores por defecto que detecta y listo. A partir de ahí:
editas → git push → tu sitio se actualiza solo
Ojo con las variables de entorno: como tu .env no está en el repo (correcto), las variables se configuran en el panel de Vercel. Es normal que el primer deploy falle por esto; no es un error tuyo, es el paso que falta.
Si tu proyecto es móvil
Tu "deploy" es un build compartible con Expo. Durante el desarrollo, Expo Go ya te permite abrir la app en tu teléfono con un QR. Para la entrega final, EAS Build genera el instalable que puedes compartir por link — sin necesidad de publicar en las tiendas.
El historial como narrativa
Cierro con lo que más te va a servir en la defensa. Un buen historial se lee así:
agrega filtro por categoría al catálogo
corrige el buscador cuando el texto tiene acentos
extrae la tarjeta de producto a su propio componente
conecta el listado con la API
estructura inicial del proyecto
Cualquiera que lea eso entiende cómo creció tu proyecto — y tú entiendes cómo lo construiste, aunque hayan pasado seis semanas. Cuando en la defensa te pregunte "muéstrame el commit donde agregaste X y qué se rompió", el historial es tu propia guía de estudio.
Un proyecto sin historial se defiende de memoria. Uno con historial se defiende leyendo.
Ejemplos de Código
4 ejemplos
El flujo mínimo de cada sesión de trabajo
Estos cuatro comandos cubren el 90% de tu semestre.
1git status # ¿qué cambió? (úsalo SIEMPRE antes de commitear)
2git add src/carrito.js # elige qué entra a este commit
3git commit -m "agrega cálculo del total del carrito"
4git push # sube al remoto (y dispara el deploy).gitignore — créalo ANTES del primer commit
Lo que entra al historial una vez, se queda ahí para siempre.
1# Dependencias (se reinstalan con npm/pnpm install)
2node_modules/
3
4# Secretos: NUNCA al repositorio
5.env
6.env.local
7
8# Builds (se regeneran)
9dist/
10build/
11.next/
12
13# Sistema operativo / editor
14.DS_Store
15.vscode/Mensajes de commit — antes y después
La regla: imperativo, qué cambió, sin mencionar la herramienta.
1❌ cambios ✅ agrega validación de email al registro
2❌ arreglo ✅ corrige total del carrito con descuentos
3❌ ya jala!!! ✅ conecta el listado con la API de productos
4❌ Update App.jsx ✅ extrae la tarjeta de producto a su componente
5❌ lo que me dijo la IA ✅ integra búsqueda con debounce de 300msTus tres salvavidas cuando algo se rompe
Antes de borrar la carpeta y empezar de nuevo, prueba esto.
1git log --oneline # ¿qué hice y en qué orden?
2git diff # ¿qué cambié desde el último commit?
3git restore src/App.jsx # descarta cambios NO commiteados de un archivo
4
5# Deshacer un commit ya subido, dejando registro honesto del cambio:
6git revert a3f9c21Recursos
4 recursos disponibles
¡Hora de Practicar!
Práctica Guiada — Tu repo y tu primer deploy
De cero a "mi proyecto está en línea" en una sesión.
Trabaja sobre el proyecto que propusiste esta semana (fase 1).
git initen la carpeta de tu proyecto.- Crea tu
.gitignoreantes del primer commit (usa el snippet de la clase). - Primer commit:
git add .ygit commit -m "estructura inicial del proyecto". - Crea el repositorio en GitHub y conéctalo (
git remote add origin ...). git push -u origin main. Verifica en GitHub que no subistenode_modulesni.env.- Despliega: conecta el repo a Vercel (web) o genera tu build de Expo (móvil).
- Haz un cambio pequeño y visible, commitea y pushea. Confirma que el sitio se actualizó solo.
Entrega: la URL de tu repo y la URL de tu sitio/build desplegado.
Desafío de Código
Ejercicios — Mensajes que se pueden defender
Reescribe mensajes de commit reales para que digan qué pasó y por qué.
Reescribe cada mensaje. Regla: en imperativo, describiendo el cambio, sin mencionar herramientas.
cambiosarregloya funciona el formulario!!!Update index.htmllo que me dijo la IAavance del viernes
Después responde: para el commit 3, ¿qué información necesitaría tu profesor en la defensa que ese mensaje NO da?
Reto de Lectura
Reto de Lectura — El historial que cuenta una mentira
Un `git log` real delata cómo se construyó un proyecto. Este delata cuatro problemas, y uno de ellos es un incidente de seguridad.
Este es el historial completo del proyecto de un alumno, entregado el lunes a las 9:00. Encuentra los 4 problemas y explica qué revela cada uno. Uno es grave de verdad.
$ git log --stat --oneline
a3f9c21 ya jala
48 files changed, 1204 insertions(+), 89 deletions(-)
Date: Mon Nov 24 02:47:13 2026
7d1e044 avance
3891 files changed, 512847 insertions(+)
.env | 6 +
node_modules/... | (3874 archivos)
src/App.jsx | 340 +
src/api.js | 88 +
Date: Sun Nov 23 23:12:05 2026
1b0f8ae Initial commit
2 files changed, 24 insertions(+)
Date: Wed Oct 15 10:03:41 2026
Y este es el .env que aparece en el segundo commit:
VITE_API_KEY=sk_live_4eC39HqLyjWDarjtT1zdp7dc
DB_PASSWORD=proyecto2026
Preguntas:
- ¿Qué te dice la línea de tiempo (15 oct → 23 nov → 24 nov) sobre cómo se construyó el proyecto?
- ¿Qué problema causa el commit de 3,891 archivos y cómo se evita?
- El alumno se da cuenta del
.env, lo borra y hace un commit nuevo. ¿Ya quedó resuelto? - Si fueras el profesor en la defensa, ¿qué pregunta harías con este historial enfrente?
Documentación Oficial
Documentación de apoyo
Referencias oficiales para el flujo de la clase.
Clase 10 de 31 en la ruta Desarrollo movil