¿Qué es Git?
Llevas varias secciones construyendo cosas reales. Con HTML creaste la estructura de Café Estelar, con CSS le diste personalidad visual, y con JavaScript hiciste que la página reaccionara a lo que hace el usuario. Pero hay algo que todavía no has resuelto: qué pasa cuando metes la pata.
Imagina esta situación: llevas dos horas modificando el CSS de tu página. Cambias colores, reorganizas el layout, ajustas tipografías. De repente, todo se rompe. El menú se solapa con el contenido, el footer desapareció y no recuerdas exactamente qué cambiaste. Quieres volver atrás, pero no puedes. Hiciste Ctrl+Z tantas veces que ya no funciona. Cierras el editor frustrado.
O peor: estás trabajando con otra persona en el mismo proyecto. Los dos modificáis el mismo archivo al mismo tiempo. Cuando intentáis juntar vuestro trabajo, es un desastre. Líneas que se pisan, cambios que desaparecen, horas de trabajo perdidas.
Git existe para que nada de esto te pase nunca más.
Qué es el control de versiones
Piensa en escribir una novela. Cada día avanzas un poco: escribes un capítulo, corriges diálogos, eliminas una escena que no funcionaba. Ahora imagina que pudieras volver a cualquier versión anterior de tu novela en cualquier momento. No solo eso: imagina que pudieras ver exactamente qué cambiaste cada día, comparar la versión de hoy con la de hace una semana, e incluso crear una "realidad alternativa" donde pruebas un final diferente sin afectar tu historia principal.
Eso es un sistema de control de versiones. Y Git es, con diferencia, el más utilizado del mundo. Es el estándar de la industria. No es una herramienta opcional ni un "nice to have" — es tan fundamental como saber usar un editor de código.
Por qué Git es imprescindible
Cualquier oferta de empleo de desarrollo web incluye Git como requisito. No importa si buscas trabajo en frontend, backend, mobile o DevOps. Git está en todas partes. Pero no solo es cuestión de empleabilidad:
- Te salva de ti mismo: ¿rompiste algo en tu código? Vuelves a la versión anterior en segundos.
- Te permite experimentar sin miedo: ¿quieres probar una idea loca? Creas una rama, experimentas, y si no funciona, la borras. Tu código principal sigue intacto.
- Hace posible trabajar en equipo: cinco desarrolladores pueden trabajar en el mismo proyecto al mismo tiempo sin pisarse.
- Es tu diario de trabajo: cada cambio queda registrado con fecha, autor y descripción. Dentro de seis meses puedes saber exactamente por qué se hizo cada modificación.
Git vs GitHub: no son lo mismo
Esta es una confusión muy común entre principiantes, así que vamos a dejarla clara desde el principio.
Git es una herramienta que se instala en tu ordenador. Funciona en local, sin conexión a internet. Es como Microsoft Word: tú escribes y guardas en tu máquina.
GitHub es una plataforma web donde puedes subir tus proyectos de Git para compartirlos, colaborar con otros y tener una copia de seguridad en la nube. Es como Google Drive: almacenamiento remoto con funciones sociales y de colaboración.
- Git = la herramienta (local, en tu ordenador).
- GitHub = la plataforma (remota, en internet).
Puedes usar Git sin GitHub perfectamente. Pero en la práctica, casi todo el mundo usa ambos. GitHub no es la única plataforma de este tipo — también existen GitLab y Bitbucket — pero GitHub es la más popular y la que usaremos en este curso.
Piensa en Git como el motor del coche y en GitHub como la carretera. El motor funciona solo, pero necesitas la carretera para llegar a algún sitio con otras personas.
Un poco de historia
Git fue creado en 2005 por Linus Torvalds, el mismo creador de Linux. El equipo de desarrollo de Linux usaba un sistema de control de versiones que dejó de ser gratuito, así que Linus decidió crear el suyo propio. En pocas semanas tenía un prototipo funcional, y en poco tiempo se convirtió en el estándar mundial.
Lo que hace especial a Git frente a sistemas anteriores es que es distribuido: cada persona que trabaja en un proyecto tiene una copia completa de todo el historial. No dependes de un servidor central. Si el servidor se cae, tú sigues teniendo todo el proyecto con toda su historia en tu ordenador.
Cómo funciona Git: las instantáneas
Muchos sistemas de control de versiones guardan los cambios entre archivos (las diferencias de una versión a otra). Git funciona diferente: guarda instantáneas (snapshots) completas del estado de tu proyecto en cada momento.
Imagina que tu proyecto es Café Estelar con estos archivos:
cafe-estelar/
index.html
styles.css
app.js
Cada vez que haces un "commit" en Git (ya veremos qué es), Git toma una foto de todos tus archivos en ese momento exacto. Si más tarde modificas solo styles.css, Git guarda una nueva instantánea donde index.html y app.js apuntan a la versión anterior (porque no cambiaron) y styles.css apunta a la nueva versión. Es muy eficiente.
Los tres estados de Git
Este es el concepto más importante de esta lección. Git organiza tu trabajo en tres estados. Entender esto es entender Git:
1. Working Directory (directorio de trabajo)
Es tu carpeta de proyecto tal como la ves en tu editor. Aquí editas archivos libremente. Git sabe que existen pero todavía no les está haciendo seguimiento de los cambios nuevos.
2. Staging Area (área de preparación)
Es una zona intermedia donde colocas los archivos que quieres incluir en tu próximo "guardado" (commit). Es como preparar una caja antes de enviarla: eliges qué va dentro y qué no.
3. Repository (repositorio)
Es donde Git guarda permanentemente las instantáneas de tu proyecto. Cada commit es un punto en la historia al que puedes volver en cualquier momento.
El flujo básico de trabajo con Git sigue estos tres pasos:
# 1. Modificas archivos en tu directorio de trabajo
# (editas styles.css, por ejemplo)
# 2. Agregas los cambios al staging area
git add styles.css
# 3. Guardas la instantánea en el repositorio
git commit -m "Mejorar colores del menú de navegación"
Vamos a verlo con un ejemplo concreto. Imagina que estás trabajando en Café Estelar:
- Modificas
styles.csspara cambiar el color del fondo. - Modificas
app.jspara arreglar un bug en el saludo. - Modificas
index.htmlpara añadir un nuevo producto al menú.
Pero solo quieres guardar los cambios de CSS y JavaScript por ahora, porque el cambio de HTML todavía no está terminado. Con Git puedes hacer esto:
# Solo envías al staging area los archivos que quieres guardar
git add styles.css
git add app.js
# Creas el commit solo con esos dos archivos
git commit -m "Corregir color de fondo y bug del saludo"
# index.html sigue modificado en tu directorio de trabajo,
# pero no forma parte de este commit
El staging area es lo que diferencia a Git de un simple "guardar". Te da control total sobre qué cambios agrupas en cada punto de la historia. Esto es muy útil cuando trabajas en varias cosas a la vez.
Visualizando el flujo
Piensa en los tres estados como una cadena de producción:
- Working Directory (tu escritorio): donde trabajas y haces cambios.
- Staging Area (la caja de envío): donde seleccionas qué va en el próximo paquete.
- Repository (el almacén): donde se guardan todos los paquetes, etiquetados y ordenados por fecha.
Working Directory ──git add──> Staging Area ──git commit──> Repository
(editas) (preparas) (guardas)
Cada commit en el repositorio es como un punto de guardado en un videojuego. Puedes avanzar, puedes retroceder, puedes explorar caminos alternativos. Tu código está seguro.
Resumen
En esta lección has aprendido:
- Git es un sistema de control de versiones que guarda instantáneas de tu proyecto.
- Es una herramienta imprescindible para cualquier desarrollador — no es opcional.
- Git (local) y GitHub (remoto) son cosas diferentes pero complementarias.
- Git fue creado por Linus Torvalds en 2005 y es el estándar mundial.
- Git trabaja con tres estados: Working Directory, Staging Area y Repository.
- El flujo básico es: editar archivos,
git addpara preparar,git commitpara guardar.
En la siguiente lección vamos a instalar Git y configurarlo en tu ordenador para que puedas empezar a usarlo de verdad.
Reflexión: Git en tu propio contexto
Este ejercicio es de reflexión e investigación. No necesitas escribir código:
- Describe con tus propias palabras qué es Git y por qué es útil. Inténtalo sin mirar la lección — usa tus propias analogías.
- Piensa en 3 situaciones reales donde el control de versiones te habría salvado. Por ejemplo: "Aquella vez que borré sin querer el CSS del footer y no sabía cómo era antes" o "Cuando mi compañero y yo editamos el mismo archivo y se perdieron mis cambios".
- Explica la diferencia entre Git y GitHub como si se lo explicaras a alguien que no sabe nada de programación.
- Dibuja (en papel o en una app) el diagrama de los tres estados de Git con tus propias palabras. Incluye un ejemplo con archivos del proyecto Café Estelar.
lightbulb Pistas
Para las situaciones reales, piensa en momentos donde has perdido trabajo, donde has tenido que deshacer cambios manualmente o donde has trabajado con alguien más en el mismo documento (no tiene que ser código — vale un documento de Word, una presentación, etc.). Para la analogía de Git vs GitHub, la clave está en "local vs remoto" y "herramienta vs plataforma".