Git y control de versiones

En el módulo anterior creamos la base del PROYECTO FINAL (entorno virtual + requirements.txt). Ahora le ponemos un historial: convertimos esa carpeta en un repositorio Git. Al terminar este módulo, cada cambio de tu proyecto quedará registrado, etiquetado y reversible. Es la pieza que hace posible colaborar y, sobre todo, no perder trabajo nunca.

¿Qué es?

Git es un sistema de control de versiones (en inglés, version control system). Su trabajo es registrar la historia de tu proyecto: qué cambió, cuándo, quién lo hizo y por qué. Cada vez que guardas un punto en esa historia, creas un commit: una foto del estado del proyecto en ese momento, con un mensaje que lo describe.

No confundas Git con GitHub. Git es el programa que corre en tu máquina y guarda la historia localmente. GitHub (que veremos en el siguiente módulo) es un sitio web para alojar repositorios en la nube y colaborar. Puedes usar Git perfectamente sin internet.

¿Cómo funciona?

Git trabaja en tres "zonas" que conviene tener clarísimas:

1. Directorio de trabajo (working directory): tus archivos tal como los editas.
2. Área de preparación (staging area o index): la antesala donde eliges qué cambios entrarán en el próximo commit. Pones cosas aquí con git add.
3. Repositorio (repository): el historial confirmado. Mueves del staging al repositorio con git commit.

El flujo siempre es el mismo: editas → git add → git commit. Cada commit queda identificado por un código único (un hash) y guarda quién lo hizo y cuándo.

¿Para qué sirve?

• Viajar en el tiempo: vuelves a cualquier estado anterior sin miedo.
• Entender el porqué: cada cambio tiene un mensaje y un autor.
• Experimentar sin riesgo: pruebas ideas en ramas (branches) y, si no funcionan, las descartas sin tocar lo estable.
• Colaborar: es la base de todo trabajo en equipo de software.

Construyamos esta pieza del proyecto

Paso 1: configura Git (solo la primera vez)

Antes de tu primer commit, dile a Git quién eres. Esto se hace una vez por máquina.

git config --global user.name "Tu Nombre"
git config --global user.email "tu-correo@ejemplo.com"
git config --global init.defaultBranch main

La última línea hace que la rama principal se llame main (el estándar actual). Verifica:

git config --list

Paso 2: inicializa el repositorio

Ve a la carpeta del proyecto del módulo anterior y conviértela en repositorio:

cd mi-entorno-pro
git init

Esto crea una carpeta oculta .git/ donde Git guardará toda la historia. Comprueba el estado:

git status

Git te dirá que estás en la rama main y que hay archivos "sin seguimiento" (untracked): los que aún no le has pedido que controle.

Paso 3: prepara y haz tu primer commit

Primero llevamos los archivos al área de preparación con git add. El punto significa "todo lo de esta carpeta":

git add .
git status

Ahora los archivos aparecen en verde, listos para el commit. Confirmamos el punto en la historia:

git commit -m "Primer commit: entorno virtual y requirements"

El -m es el mensaje del commit: una descripción corta y en presente de lo que hace ese cambio. Verifica que quedó registrado:

git log --oneline

Paso 4: trabaja con ramas

Las ramas te dejan desarrollar una idea sin tocar main. Creemos una para añadir un archivo de ejemplo:

git switch -c feature/saludo

-c crea la rama y te mueve a ella de un tirón. Crea un archivo y haz un commit en esa rama:

echo "print('Hola, entorno pro')" > app.py
git add app.py
git commit -m "Añade script de saludo"

Vuelve a main y fusiona (merge) los cambios de tu rama:

git switch main
git merge feature/saludo

main ahora incluye tu app.py. La rama ya cumplió su función; puedes borrarla:

git branch -d feature/saludo

Paso 5: deshacer con cabeza

Dos rescates que usarás mucho:

git restore app.py # descarta cambios no guardados de un archivo
git restore --staged app.py # saca un archivo del área de preparación (sin perder el cambio)

Ejercicios

1. Inicializa un repositorio en una carpeta nueva, crea un archivo notas.txt, haz un primer commit y luego modifica el archivo y haz un segundo commit. Muestra el historial con git log --oneline y verifica que hay dos puntos en la historia.
2. Crea una rama feature/prueba, añade un archivo en ella y haz un commit. Cámbiate a main, comprueba con ls que el archivo no está, fusiona la rama y comprueba que ahora sí aparece. Explica en una frase por qué.