Saltar al contenido
Aula en la nube
1º DAM · Proyecto web personal · Sesión 2 (fase)

Tu proyecto en GitHub: Git sin comandos

Segunda fase del proyecto: mejoramos la web y la ponemos a salvo. Git es la herramienta que guarda la historia completa de tu proyecto; GitHub es donde esa historia vive en la nube. Con agentes de código trabajando contigo, esto deja de ser opcional: es tu máquina del tiempo y tu copia de seguridad del curso.

🕰 Historia, no copias☁️ GitHub = respaldo🧠 Conceptos, no comandos🤝 Base del proyecto final en grupo
Idea que tienes que entenderte: Git no guarda «la última versión»: guarda cada versión. Tu proyecto con Git es como un videojuego con guardado automático: si te equivocas con el jefe final, cargas la partida. Sin Git solo tienes la foto actual; con Git tienes la película entera.

Los cinco conceptos que sí o sí

No necesitas memorizar comandos: los agentes y las interfaces los escriben por ti. Lo que nadie puede hacer por ti es entender qué está pasando. Con estos cinco lo tienes todo:

Repositorio«la carpeta con memoria»

Tu proyecto convertido en historia: una carpeta donde cada guardado queda registrado con autor, fecha y mensaje. Todo trabajo del curso vivirá en repositorios —empezando por mi-web.

Cuándo lo vas a notar de verdad: cuando abras GitHub y veas tu web ahí, con todas sus versiones, desde cualquier ordenador del mundo.

Commit«un guardado con título»

Una foto de tu proyecto en un momento exacto, con un mensaje que dice qué cambió y por qué. Se hacen commits pequeños y frecuentes: uno por cosa, no «cosas varias».

Cuándo lo vas a notar de verdad: cuando rompes algo y necesitas volver al guardado anterior sin perder horas, o cuando repasas tu historia y ves cómo ha crecido el proyecto.

Push / Pull«sincronizar con la nube»

Tu portátil y GitHub son dos copias de la historia. Push: subo mis commits nuevos. Pull: bajo los que no tengo (de GitHub o de otro compañero). Nada mágico, solo mantener las dos películas sincronizadas.

Cuándo lo vas a notar de verdad: cuando el agente te avise: «estás X commits por detrás» o «hay cambios remotos: haz pull antes de continuar». Eso no es un error: es Git hablando, y tú sabrás qué significa.

Rama (branch)«un universo paralelo»

Una copia de tu historia donde experimentas sin tocar la principal. Si la idea funciona, se fusiona (merge); si no, se borra y no ha pasado nada. Los profesionales nunca experimentan en la rama principal (main).

Cuándo lo vas a notar de verdad: cuando quieras rehacer el diseño de tu web «por probar» sin arriesgar lo que ya funciona.

Pull Request (PR)«propuesta de cambio a revisión»

Cuando trabajas en equipo: tu rama terminada se propone al resto con un mensaje de lo que hace. Se revisa entre todos, se comenta, se aprueba y entonces entra en el proyecto común. Así funciona cualquier empresa de software.

Cuándo lo vas a notar de verdad: en el proyecto final en grupo: nadie subirá código directo a main; todo pasará por PR con revisión de tus compañeros.
Lo que vas a aprender a «leer» este curso (mensajes típicos de tu agente o de GitHub):«working tree limpio ✓» · «3 commits por detrás de origin/main, haz pull» · «conflicto de merge en style.css» · «ramas divergentes» · «PR aprobada, se puede fusionar»Detrás de cada frase hay uno de los cinco conceptos. Si sabes qué significa, siempre sabes qué hacer; si no, estás conduciendo a ciegas.

Tu primera vez en GitHub

Lo haremos en clase, juntos y sin prisa. Cada uno saldrá con su cuenta, su primer repositorio y su web dentro. Guía de lo que haremos (no hace falta que la traigas estudiada):

  1. 1 · Cuenta. github.com → Sign up (usuario serio: es tu nombre profesional; es lo primero que verá cualquier empresa de ti después del currículum).
  2. 2 · Repositorio nuevo. «New repository» → nombre mi-web → público → «Add a README». Ya tienes un repositorio vacío en la nube.
  3. 3 · Subir tu web. Con la interfaz web (Add file → Upload files) o con el agente, subes tu carpeta. En GitHub verás tus ficheros: tu primera copia en la nube.
  4. 4 · Primer commit honesto. En clase practicaremos escribir mensajes que expliquen el porqué: «año: web personal» vs «añadida sección de contacto con GitHub».
  5. 5 · Historia. Pestaña commits: tu película. Entra en uno y mira la «foto» exacta de ese momento.

Git + IA: tu forma de trabajar

A partir de ahora, con agentes de código, el flujo profesional es este. Guárdalo: lo usarás todo el curso y en el proyecto en grupo:

Antes de que un agente toque mi proyecto:
1) Hacer commit de lo que ya funciona (aunque esté imperfecto).
2) Crear una rama nueva para el experimento (feat/...).
3) Dejar que el agente trabaje en la rama, con commits pequeños.
4) Si funciona: merge a main y push. Si no: borrar la rama, main intacta.
Regla de oro del curso: el agente puede escribir el comando; la decisión de cuándo se guarda y por qué es tuya. Un proyecto que solo entiende su autor es un pasivo, no un activo. En la defensa me basta con pedirte: «muéstrame tus commits y cuéntame la historia de tu web».
¿Y «la máquina del tiempo» esa cómo se usa en un examen?

Cuando rompas algo y no sepas volver: en GitHub, pestaña Commits → busca el último estado bueno → abre sus ficheros → copia el contenido de vuelta. Sin tocar terminal: la interfaz web lo permite. En clase lo practicamos.

¿Git es solo para programar?

Sirve para cualquier cosa que cambie con el tiempo y quieras versionar: apuntes, este mismo proyecto, documentos. Programar es donde nació, pero tu TFG de DAM también podría vivir en un repo. Los datos curiosos vendrán en futuras sesiones.

¿Y si pierdo el portátil con todo en local?

Por eso push es sagrado. Regla del curso: si funciona, se sube. Tu GitHub es la copia de seguridad de todo lo que hagas este año: al final del curso tendrás tu historia literal en commits.

Para la próxima sesión: trae

← Sesión 1Volver al proyecto →