E13 - Cómo usar Git: Tutorial básico y buenas prácticas

Resumen

El episodio 13 de enCoders presenta un tutorial básico de Git y buenas prácticas, enfocado en proyectos de ciencia de datos más que en desarrollo de software. Parte de un ejemplo de lo que no hay que hacer (una carpeta de tesis con ocho versiones de un mismo caso, sin saber qué las diferencia) y explica qué es el control de versiones, la historia de Git, sus diferencias con sistemas centralizados como SVN y Mercurial, y las plataformas para alojar repositorios. Luego recorre los comandos básicos (status, add, commit, push, pull, merge, checkout), las ramas (main/master y develop, con ramas de features como en gitflow), los tags y la resolución de conflictos. Las conclusiones: con lo básico se cubre gran parte de las necesidades de un data scientist; hay que commitear seguido con mensajes claros que expliquen el porqué; no hay que trabajar solo en master; hay que hacer push para respaldar el trabajo; los tags permiten volver a versiones que funcionaban; y saber Git quita el miedo a borrar código y facilita retomar el trabajo de otros. Cierran mencionando temas pendientes: pull requests, rebase, tipos de merge, gitflow en detalle y la carpeta .git.

Capítulos

• 00:00
  IntroPresentan el episodio 13: qué es Git, por qué es útil y su aplicación a Data Science. Destacan que es una herramienta fundamental para el trabajo en equipo y para coordinar el desarrollo de un proyecto común.
• 01:33
  Ejemplo de lo que no hay que hacerSe muestra la carpeta de una tesis con ocho versiones del mismo caso (caso 4, caso 4c, etc.), sin saber qué diferencia a cada una ni qué significan los nombres. Un Excel de "versionamiento" casero no resuelve el problema, y es la motivación para usar control de versiones.
• 06:00
  Qué es el control de versiones y por qué Git es útilControl de versiones es llevar la cuenta de los cambios para poder volver atrás; Word tiene algo mínimo (control Z, recuperación). En código, Git guarda solo las líneas modificadas y no el archivo completo, a diferencia de un PDF o binario, lo que hace el historial mucho más eficiente.
• 08:41
  Historia de GitComentan que el creador de Linux (Torvalds) impulsó Git, que nació para el kernel de Linux tras la muerte de una herramienta anterior (mencionan "Big Keeper", probablemente BitKeeper). Se dice que fue un proyecto personal para ordenarse él mismo. También explican que Git se puede usar local, pero un proveedor en la nube sirve de respaldo, y que montar un servidor propio solo se justifica por exigencias de privacidad o ciberseguridad.
• 11:41
  Ejemplo de repoSe muestra un repositorio en GitHub: archivos, contribuyentes, historial de cambios por archivo e issues. Revisan el repositorio del kernel de Linux, donde cada commit muestra la línea modificada, y discuten la transparencia del código abierto y quién lo revisa.
• 16:11
  Tipos de sistemas para control de versionesMencionan SVN y Mercurial como alternativas, pero Git es el más popular. Su ventaja es ser descentralizado: cada uno hace sus cambios y luego los envía al remoto, mientras que en los centralizados se cambia directamente un repositorio central. Insisten en que conviene conocer las ventajas de Git frente a las otras opciones, sin necesidad de aprender SVN.
• 19:45
  Plataformas donde almacenar los reposGitHub, Bitbucket y GitLab son las tres más típicas, todas con plan gratuito. Bitbucket permite equipos de hasta cinco personas gratis; los planes de pago apuntan a empresas (CI/CD, acceso restringido) y para uso personal sale barato (cerca de tres dólares).
• 21:58
  Comandos básicosDemostración con el proyecto Titanic: `git status`, `git add` (archivo, `.` o carpeta/asterisco), `git diff`, `git commit -m` y `git push`. Explican el stage, la rama local adelantada respecto a `origin/develop`, y debaten sobre commits pequeños y temáticos frente a `git add .`. También discuten el largo de los mensajes (sugerencia de 50 caracteres frente a commits largos del kernel) y que el mensaje debe explicar el porqué del cambio.
• 34:21
  Ramas, commits y cómo usarlos en un proyecto de DSLas ramas son punteros a un commit que se mueven con el desarrollo y permiten trabajar versiones separadas sin romper lo que funciona. Proponen una rama principal (main/master/producción) con código que funciona y una rama develop para trabajar, con ramas aparte para tareas complejas; aclaran que es su forma de trabajar y que para quien se inicia basta con master y develop.
• 46:21
  MergeSe hace un merge de `origin/main` en develop; si los cambios están en líneas distintas se juntan automáticamente. Si dos personas modifican la misma línea aparece un conflicto de merge que hay que resolver a mano.
• 48:05
  MemesSesión de memes de Git: el pánico ante los primeros conflictos, trabajar en master, el uso de `git remote add origin <URL>` (origin es solo el alias por defecto del remoto, podría haber varios), el `push --force` que borra el trabajo de otros, los commits sin sentido, la importancia de hacer push al final del día y de commitear con frecuencia. Cuentan anécdotas de pérdida de trabajo, como una macro de Excel sobrescrita.
• 01:00:37
  Resolución de conflictosDemostración: un push es rechazado, se hace pull y aparece el conflicto en un archivo. Los marcadores `<<<<<<<`, `=======` y `>>>>>>>` delimitan los cambios; se edita el archivo dejando lo correcto, se hace `git add` y un commit de merge con el mensaje por defecto. Se muestra también un `push --force` de Mati que pisa los cambios.
• 01:07:24
  ResumenRepasan que `git pull` actualiza el repositorio local y que no hay conflicto si los cambios son en líneas distintas. Precisan que lo que aparece arriba del marcador `=======` son los cambios de la rama donde se está parado, y lo de abajo son los cambios que se traen.
• 01:09:44
  ExperienciasUn integrante relata que tuvo que tomar un proyecto ajeno a última hora: pidió el repositorio, creó una rama aparte y, gracias a la estructura y buenas prácticas, entendió el código rápido. Concluyen que saber Git suma, y que no saberlo resta puntos, como el inglés.
• 01:13:09
  Flujos de trabajo con Git típicosRecomiendan git flow como punto de partida en Data Science: rama principal, develop y ramas de features. Ejemplo: probar una red neuronal en una rama aparte en lugar de un Random Forest, y descartarla o integrarla según funcione. Piden disciplina para crear ramas y escribir buenos comentarios, porque el esfuerzo se paga al trabajar en equipo.
• 01:18:25
  Herramientas que facilitan y agilizan el uso de GitEn Visual Studio Code se puede sincronizar, cambiar de rama, hacer checkout de un commit, agregar al stage y commitear con botones. Explican `git checkout` y cuentan cómo recuperaron el trabajo de un compañero que creía haberlo perdido. Aconsejan saber los comandos de terminal, pero aprovechar las herramientas, y debaten qué es más rápido.
• 01:24:17
  TagsLas ramas son punteros móviles, los tags son punteros fijos a hitos del código, útiles para volver a una versión que funcionaba (ej. versión 0.0.1). Recomiendan un tag por cada merge a master, y cambios directos en master solo para hotfixes. Saber usar Git quita el miedo a borrar código, porque se puede recuperar del historial.
• 01:30:35
  CierreConcluyen que lo visto es lo esencial y que cubre gran parte de las necesidades. Explican los pull requests como pedirle a quien tiene poder sobre el repositorio que revise e incorpore los cambios. Mencionan temas para futuros episodios (tipos de merge, rebase, git flow en detalle, la carpeta .git) y despiden el stream invitando a Discord.

Palabras clave