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.
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
Paso 1 · Iniciar
Crea una carpeta de practica y declara el repositorio. A partir de aqui, la carpeta tiene un historial invisible en el subdirectorio .git.mkdir demo; cd demo; git initPaso 2 · Primer status
Escribe un fichero mirame.txt y pregunta el estado: Git lo reporta como NO RASTREADO. Todavia nadie lo vigila.echo "hola datos" > mirame.txt; git statusPaso 3 · Preparar
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 add mirame.txt; git statusPaso 4 · Comitar
git commit congela la foto con mensaje. El historial ya tiene el nodo raiz y su identificador de 40 hexadecimales (abreviable a 7).git commit -m "Primera fotografia del proyecto"Paso 5 · Ciclo diario
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.echo "mas lineas" > mirame.txt; git diff; git log --oneline
Paso 1 de 5
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
Paso 1 · Abrir rama
Crea y salta a la rama del experimento. main sigue apuntando a su ultimo commit: alli nada ha cambiado todavia.git switch -c experimento-scalerPaso 2 · Comitar en rama
Comita tus cambios DENTRO de la rama. El historial se bifurca: ahora hay dos lineas de tiempo.git add .; git commit -m "Estandarizar antes del PCA"Paso 3 · Fusion limpia
Vuelve a main y fusiona: sin divergencia, Git hace un fast-forward y main apunta al ultimo commit de la rama.git switch main; git merge experimento-scalerPaso 4 · Conflicto
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.git status # ficheros unmerged; editar; git add .; git commit
Paso 1 de 4
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
Paso 1 · Enlazar
Crea el repositorio en la web y enlaza tu carpeta local, o clona uno existente.git clone URL-repo; o git remote add origin URLPaso 2 · Subir
Sube la rama y establece el seguimiento: a partir de aqui, push y pull a secas saben a donde van.git push -u origin mainPaso 3 · Ciclo con remoto
Antes de tu proxima jornada, baja lo ajeno: pull, resuelve conflictos locales, comita y sube.git pull origin main; git push
Paso 1 de 3
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
- Git diario
- Mirar
- status: donde estoy
- diff: que cambie
- log --oneline: el pasado
- Guardar
- add: preparar
- commit: fotografiar
- push: compartir
- Ramificarse
- switch -c: nueva rama
- merge: fusionar
- conflicto: decidir a mano
- Deshacer
- restore: descartar cambios
- revert: comitar el retroceso
- log: encontrar el punto sano
- Mirar
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)?
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 espanolGratis 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.
Tu texto se guarda sólo en este dispositivo.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.