E59 - Git intermedio

Resumen

En este episodio (E59, grabado el 17 de octubre de 2023) se presenta Git a nivel intermedio, orientado a quienes trabajan en ciencia de datos, análisis e ingeniería de datos. Se explica por qué versionar código evita archivos tipo "versión final final", y se repasa el origen de Git (2005, descentralizado, a diferencia de Subversion y Mercurial). Se cubren los objetos (blob, tree, commit), el flujo working directory → staging → repositorio local → remoto, y los punteros (ramas y tags). Luego se ven remotos, forks y Pull Requests, restricciones de ramas en GitHub, configuración (`gitconfig`), alias y convenciones de mensajes de commit. Se cierra con la diferencia entre merge y rebase, y con `stash` y `cherry-pick` como otras fuentes de conflictos. La conclusión principal es que Git es complejo pero es la mejor herramienta para versionar código, y conviene usarlo con commits agrupados por funcionalidad, tags para versiones importantes y reglas de ramas con revisión.

Capítulos

• 00:00
  IntroSe anuncia el episodio 59, Git intermedio, que sigue a un workshop de Git básico hecho semanas antes.
• 00:24
  ContextoSe motiva Git para evitar archivos "versión final, final final", típico en tesis con feedback iterativo. Git está especializado en código, no en Word ni binarios, aunque se puede mezclar con otros documentos. Se comenta que apareció en 2005 y que antes existían otros controles de versiones.
• 03:18
  Origen de GitSe cuenta que Linus Torvalds lo creó para el desarrollo del kernel de Linux. Subversion y Mercurial eran centralizados (un servidor con "la verdad"), mientras que Git es descentralizado: cada persona tiene su copia completa y todos los repositorios pesan igual.
• 05:03
  Por qué Git en DS?Quienes trabajan con datos también construyen software (por ejemplo, modelos de ML detrás de Spotify). Necesitan versionar, volver atrás si un modelo nuevo es peor que el anterior y colaborar en equipos pequeños o grandes.
• 07:30
  Tipos de objetos en GitSe describen los blobs (cambios en archivos individuales), los trees (estructura de carpetas y archivos) y los commits, que son los más importantes porque son con los que más se interactúa. Hay una conversación lateral sobre la percepción del paso del tiempo.
• 10:02
  Flujo de trabajo y comandos básicosSe explican clone, push, fetch, merge y pull (fetch + merge), y la diferencia entre repositorio local y remotos. Se describen las zonas working directory, staging area y repositorio (la carpeta oculta `.git`), y que `add` mueve archivos al staging antes de `commit`.
• 14:09
  Punteros: Branches y tagsRamas y tags son punteros a commits: la rama avanza con cada commit y el tag es fijo. Los tags sirven para marcar versiones importantes (producción, parches de juegos, versiones de librerías). Se muestra un caso de pandas donde se encontró la fecha de un cambio que rompió una función. También hay una anécdota sobre un commit "scrapping de Mac sin testear" en un proyecto de análisis del mundial, en el que una página bloqueó el acceso por scraping.
• 26:13
  Más comando básicosSe repasan init, status, config, add y commit (`-m`, `-a`, que no agrega archivos nuevos). Se debate si hacer `git add` de todo o agrupar commits por funcionalidad, y se recomienda revisar los cambios antes de commitear. Se menciona el efecto de que una respuesta incorrecta en internet atrae más correcciones que una pregunta (Ley de Cunningham) y se comenta la reputación en Stack Overflow.
• 33:36
  RemotosSe explican fetch, merge, branch, tag, `checkout` y el estado detached HEAD, y que `rebase` linealiza el historial (el expositor prefiere merge). `origin` es solo el nombre habitual de un remoto, y `master`/`main` son nombres de ramas por defecto. Se explica la sintaxis `git remote add <nombre> <url>`, que aparece en un meme.
• 39:55
  DemoSe demuestra que `git init` local crea `master` mientras que GitHub crea `main`. Se cambia la rama por defecto en la configuración de GitHub.
• 41:35
  Restricciones de ramasSe configuran reglas de rama en GitHub (requerir Pull Request y aprobación de dos personas). Los repositorios públicos se pueden clonar, pero para hacer push se necesitan permisos de colaborador.
• 44:08
  Pull RequestSe explica el flujo con fork: copiar el repositorio, crear una rama, hacer commits y abrir un Pull Request al original. Con un diagrama se explica cómo mantener un segundo remoto para traer cambios del repositorio original y resolver el merge antes de enviar el PR. Se discute el caso de OBS y Streamlabs como fork, y las licencias.
• 55:30
  MemesSe muestran memes sobre `git push --force`, que sobrescribe el remoto, y sobre lo difícil que es entender Git. Se comenta que el carácter descentralizado permite tener respaldos.
• 58:05
  Ambientes de trabajo y gitconfigSe repasan los ambientes (working copy, staging, local, remoto) y `git config` con `--global` frente a local, útil para tener distintos usuarios y correos según el proyecto (trabajo, personal, enCoders). También se mencionan el archivo `config` dentro de `.git` y el archivo de credenciales.
• 01:02:35
  AliasSe muestra un alias de `git log` con colores, y alias como `st` (status) y checkout, definidos con `git config --global alias.<nombre>`. Los alias que empiezan con `!` ejecutan comandos de shell. También se explican las convenciones de mensajes de commit con prefijos (`feat/`, `fix`, `hotfix`, `refactor`) y un prefijo `param` para cambios de hiperparámetros.
• 01:10:48
  Diferencia entre merge y rebaseCon diagramas se explica que merge necesita un ancestro común y crea un commit que junta ambas líneas, mientras que rebase cambia la base de los commits y deja una línea. El expositor reconoce que podría estar confundiendo el sentido y que habría que verificarlo con código.
• 01:14:30
  Otras formas de obtener conflictos: stash, cherry-pick`cherry-pick` aplica los cambios de un solo commit. `stash` guarda los cambios sin commitear para trabajar en otra cosa y luego se aplican con `stash apply`, lo que puede dar conflictos. Se demuestra con `stash list`, `apply` y `clear`.
• 01:18:50
  CierreSe dice que Git es difícil pero la mejor herramienta de versionado. Se invita al Discord y se proponen temas futuros, como disponibilizar un modelo vía API y una charla sobre streaming de datos con Spark o Kafka.

Palabras clave