Git y control de versiones: la memoria de tu trabajo

Ningun otro habito separa tan rapido al aficionado del profesional. Sin Git, un proyecto de datos es una carpeta con versiones_final.xlsx, version_2.py y copia_segura.zip; con Git, cada cambio queda fotografificado, justificado y reversible. Este objeto te da el idioma completo: los tres estados, las ramas, el trabajo remoto con GitHub y las reglas para no envenenar tu repositorio con datos gigantes o claves secretas.

Diagrama de flujo Git: area de trabajo, zona de preparacion y repositorio local conectado a remoto. — Git mueve cambios por tres estaciones: tu carpeta, la zona de preparacion y el historial.

Para que sirve en datos Reproducibilidad: la grafica del articulo debe poder reconstruirse desde el commit exacto que la genero. Trazabilidad: culpar (y corregir) al cambio preciso que rompio el pipeline. Y colaboracion: dos personas en el mismo notebook sin pisarse.

Los tres estados: la teoria que lo explica todo

Todo comando de Git es un transporte entre tres zonas: el AREA DE TRABAJO (tus ficheros actuales), la ZONA DE PREPARACION o staging (lo que entrara en la proxima foto) y el REPOSITORIO (el historial de fotos). Entender este triangulo hace que git add y git commit dejen de ser rituales magicos.

Tu primer repositorio, paso a paso

Crea una carpeta de practica y declara el repositorio. A partir de aqui, la carpeta tiene un historial invisible en el subdirectorio .git.
Escribe un fichero mirame.txt y pregunta el estado: Git lo reporta como NO RASTREADO. Todavia nadie lo vigila.
git add lo mete en la zona de preparacion. Vuelve a preguntar el estado: ahora dice "cambios preparados". add no guarda nada definitivo: solo declara intenciones.
git commit congela la foto con mensaje. El historial ya tiene el nodo raiz y su identificador de 40 hexadecimales (abreviable a 7).
Modifica el fichero y usa git diff: te muestra lineas +/- sin comitar nada. Para descartar el cambio: git restore mirame.txt. Para volver atras en el historial: git log --oneline.

El mensaje del commit Primera linea imperativa y corta ("Arreglar divisor cero en normalizacion"), cuerpo opcional explicando el POR QUE. Un commit es una carta a tu yo de dentro de seis meses, que no recordara nada.

Ramas: trabajar sin romper nada

Una rama es un puntero movil al commit donde nacio: crear una cuesta lo mismo que crear una carpetica, y por eso se usan sin tacañeria. La practica estandar: main guarda el trabajo estable, y cada feature o experimento vive en su rama hasta que madura.

Rama, cambio, fusion y conflicto

Crea y salta a la rama del experimento. main sigue apuntando a su ultimo commit: alli nada ha cambiado todavia.
Comita tus cambios DENTRO de la rama. El historial se bifurca: ahora hay dos lineas de tiempo.
Vuelve a main y fusiona: sin divergencia, Git hace un fast-forward y main apunta al ultimo commit de la rama.
Conflicto: si dos ramas tocaron la MISMA linea, Git no adivina: inserta los separadores de conflicto en el fichero y espera. Abres el fichero, eliges o mezclas las opciones, borras las marcas, add + commit. El conflicto no es un error: es Git pidiendo una decision humana.

Remoto: tu historial compartido

GitHub es un repositorio Git accesible por red. clone baja el historial completo (no solo los ficheros), push sube tus commits nuevos y pull baja los ajenos. El flujo profesional pasa por PULL REQUEST: nadie comita directamente a main; se propone la rama, se revisa y se fusiona en la plataforma. Regla de oro del trabajo en equipo: pull antes de empezar y antes de push.

Conectar con el remoto

Crea el repositorio en la web y enlaza tu carpeta local, o clona uno existente.
Sube la rama y establece el seguimiento: a partir de aqui, push y pull a secas saben a donde van.
Antes de tu proxima jornada, baja lo ajeno: pull, resuelve conflictos locales, comita y sube.

Lo que JAMAS entra en un repositorio Git Datos crudos o modelos de cientos de MB (rompen el clone de todos), claves de API y .env (si comitas una clave, asume comprometida: hay que revocarla, no borrar el commit), y builds generables. Usa un fichero .gitignore con data/, *.pkl, .env, __pycache__/ y revisalo git status antes de cada add.

Git en proyectos de datos

Notebooks: limpia los outputs antes de comitar (nbstripout); salidas de celdas gigantes inflan el repo y ensucian el diff.
Datos versionados: para conjuntos grandes existe DVC (version de datos aparte del codigo) y tabs de datos en el repositorio solo si son KB.
Etiquetas por release: git tag v1.2-modelo-produccion marca el commit exacto de cada modelo desplegado.
README vivo: un repo sin documentacion te obliga a ti mismo, dentro de seis meses, a preguntar que pasaba aqui.

Mapa de comandos

Que comando uso

Autoexamen cronometrado (15 minutos)

¿Cual es la funcion exacta de la ZONA DE PREPARACION (staging)?

Un conflicto de merge es un error de Git que hay que reinstalar.

Acabas de comitar una clave de API por accidente. La accion correcta es:

El comando muestra las lineas modificadas que aun no han pasado a la zona de preparacion.

Empareja comando con su efecto.

Con git log --oneline ves 7 commits. ¿Cuantos nodos tiene como MINIMO el historial (cada commit es un nodo)?

Video de repaso

Para profundizar

Learn Git Branching (interactivo, en espanol)
El mejor playground gratuito para practicar ramas y merges con visualizacion.

Pro Git: el libro oficial en espanol
Gratis y completo; los capitulos 2 y 3 son tu manual de cabecera.

Mira tu ultima carpeta de proyecto: si hay ficheros copia y sin control, asignale una hora a git init, .gitignore y un commit inicial honesto. ¿Cual era el cambio que NO podias reconstruir? Ese es tu primer caso de amor con Git.