Git y GitHub en Platzi: control de versiones que debí aprender antes

Hay cosas que uno hace mal durante años sin saberlo. Git fue una de las mías.

Usaba Git — hacía commits, hacía push — pero no entendía la lógica de las ramas, los merges conflictivos me paralizaban y un rebase mal ejecutado me costó horas de trabajo más de una vez. El curso de Platzi ordenó todo eso.

Qué cubre el curso que cambia la forma de trabajar

El modelo mental de Git es lo primero: entender que los commits son snapshots, no diferencias. Que las ramas son punteros. Que el historial es un grafo. Cuando eso hace clic, todos los comandos tienen sentido en lugar de ser fórmulas mágicas.

GitHub como plataforma de colaboración también se cubre bien — pull requests, code review, issues, Actions básico. Para trabajar en equipo en proyectos de desarrollo web, esas herramientas no son opcionales.

Por qué importa para los proyectos de clientes

Cada proyecto que entregamos tiene su repositorio en GitHub, con historial limpio, branches por feature y documentación básica. Eso significa que si el cliente quiere incorporar otro desarrollador meses después, o si algo sale mal y necesitamos volver a una versión anterior, tenemos esa capacidad.

No es burocracia — es la diferencia entre un proyecto que puede crecer y uno que queda atrapado en su estado inicial. Lo podés ver en la forma en que organizamos los proyectos del portafolio.

Lo que Git no te enseña pero la práctica sí

Cómo escribir mensajes de commit que tengan sentido seis meses después. Cuándo hacer squash de commits y cuándo no. Cómo organizar el flujo de trabajo en equipo sin que cada merge sea un sufrimiento.

Eso viene de proyectos reales, de cometer errores reales. Pero empieza con una base sólida — y el curso de Platzi construye esa base bien. Si querés hablar sobre cómo mejorar el proceso técnico de tu equipo, escribínos.