Lección 3: Git en equipo — semantic commits, PRs y branch protection
Un historial de Git como: `fix`, `fix2`, `final`, `final-final` — eso no es Git. Git es una herramienta que documenta el historial de tus decisiones. Cuando el historial es legible, debuguear, incorporar gente nueva y hacer rollbacks toma 2 minutos en lugar de 2 horas.
Un semantic commit es como un buen nombre de archivo — `proyecto-v2-FINAL-usar-este.docx` no le sirve a nadie. `feat(auth): add login with Google` — todos saben qué es.
- semantic commit
- Un formato de commit que describe el tipo de cambio (feat/fix/docs...) y el alcance del impacto (auth/db/ui...) antes de la descripción.
- branch protection
- Configuraciones de GitHub que impiden el push directo a `main` — exigiendo un PR, review y CI en verde antes de mergear.
- trunk-based development
- Una estrategia de branching donde las feature branches viven poco tiempo (menos de un día) y se mergean a `main` con frecuencia — reduciendo los conflictos de merge.