Casi todo principiante dice "voy a aprender Git" cuando en realidad se refiere a tres cosas distintas: Git, GitHub y GitLab. Confundirlos no es grave al principio, pero te va a complicar la primera vez que un compañero te diga "súbelo al repo" y no sepas si habla de tu computadora, de una cuenta web o de un servidor de la empresa.
Git es el programa, GitHub y GitLab son el lugar donde vive
- ▸Git: el sistema de control de versiones que instalas en tu computadora (Windows, Mac o Linux). Corre local, no necesita internet, y es el que registra cada cambio que haces en tu código con un commit.
- ▸GitHub: una plataforma web que aloja tus repositorios de Git en la nube para que los compartas, colabores y los muestres en tu portafolio. Es la más usada en proyectos abiertos y en procesos de selección.
- ▸GitLab: hace lo mismo que GitHub — alojar repositorios — pero muchas empresas la prefieren porque integra además el pipeline de CI/CD y la pueden instalar en su propio servidor por temas de seguridad y compliance.
En la práctica vas a usar Git todos los días desde la terminal (o desde una interfaz gráfica), y vas a tener cuenta en GitHub, en GitLab o en ambos, dependiendo de dónde trabajes. Ninguna reemplaza a la otra: sin Git instalado, GitHub y GitLab no tienen nada que guardar.
La instalación cambia según tu sistema operativo y es uno de los puntos donde más gente se traba sin necesidad: en Windows viene con Git Bash incluido, en Mac muchas veces ya está preinstalado o se activa con una sola línea en la terminal, y en Linux depende del gestor de paquetes de tu distribución. No es difícil, pero si nunca lo hiciste conviene seguir los pasos para tu sistema específico en vez de copiar un tutorial genérico que asume otro sistema operativo.
Lo que de verdad necesitas dominar primero
Antes de preocuparte por cuál plataforma usar, el orden que funciona es: instalar Git según tu sistema operativo, configurar una llave SSH (así no tienes que meter tu contraseña cada vez que subes un cambio), hacer tu primer push y aprender a trabajar con ramas. Recién ahí tiene sentido crear cuenta en GitHub o GitLab — de nada sirve una cuenta vacía si no sabes qué mandarle.
Lo que nadie te advierte: el primer "undo changes" que necesitas hacer de verdad suele ser bajo presión — borraste algo que no debías o hiciste commit de un archivo con credenciales. Si no practicaste revertir cambios en un entorno sin presión, ese momento te va a doler el doble.
Las dos confusiones que más frenan a un principiante
La primera: pensar que "hacer push" es lo mismo que "guardar". Un commit guarda el cambio en tu historial local; el push recién lo manda a GitHub o GitLab. Puedes hacer veinte commits sin conexión a internet y ninguno existe fuera de tu computadora hasta que corres ese push — algo que confunde a cualquiera que viene de Google Docs, donde todo se guarda solo.
La segunda: creer que las ramas (branches) son solo para proyectos grandes con muchos desarrolladores. En realidad, hasta trabajando solo te conviene crear una rama antes de probar algo que podría romper tu código principal. Si funciona, la fusionas (merge); si no, la borras y tu rama principal queda intacta. Es el hábito que más diferencia a alguien que aprendió Git de verdad de alguien que solo memorizó tres comandos.
Por qué esto importa más si trabajas con datos en la nube
Un pipeline de datos, un notebook o un script de transformación que vive solo en tu laptop es un riesgo: si tu equipo falla, se pierde el trabajo y nadie más puede retomarlo. Versionar con Git y respaldar en GitHub o GitLab es lo que te permite colaborar, volver a una versión anterior cuando algo se rompe en producción y, de paso, construir un historial de commits que funciona como evidencia de tu trabajo frente a un reclutador.
El README que de verdad suma en una entrevista
Casi nadie le da importancia al README hasta que un reclutador abre su GitHub y encuentra veinte repositorios sin ninguna explicación. Un README útil no describe el código línea por línea: dice qué problema resuelve el proyecto, qué tecnologías usaste y cómo correrlo. Para un proyecto de datos, suma además una sección de "estructura del proyecto" que muestre que organizas carpetas por etapa (datos crudos, procesados, notebooks, scripts) — es la primera señal de orden que ve alguien que revisa tu portafolio en treinta segundos.
Dónde aprenderlo de cero
Fundamentos de Git en Cloud cubre justo este orden en 30 sesiones cortas: qué es cada herramienta, instalación en los tres sistemas operativos, configuración de SSH, ramas, resolución de conflictos, y cómo estructurar un proyecto de datos con un README que de verdad sirve para un portafolio. Es un curso de nivel básico, de 2 horas en total, pensado para quien nunca tocó una terminal.
Es el primer escalón de la ruta Data Engineer en DataPath — después de Git, el siguiente fundamento que te va a pedir cualquier equipo de datos es SQL.
