Aprende a mantener un historial legible (rebase interactivo, squash, tags) y automatiza checks de calidad con workflows en GitHub Actions.
En nivel pro no basta con que el código funcione: el historial debe contar una historia clara y la calidad debe validarse sola en cada push 🚀.
Aquí unirás dos piezas: commits limpios (squash/rebase) y pipelines mínimas de CI con GitHub Actions.
Si todavía te cuesta gestionar conflictos, te conviene consolidar primero <a href="/curso/git-github/leccion/git-github-conflictos-rebase-ramas">la lección de conflictos y rebase</a>.
Reescribe localmente antes de publicar para que la PR sea fácil de revisar.
Con <code>git rebase -i</code> puedes agrupar commits ruidosos en uno o reordenarlos para que tengan sentido narrativo. Esto mejora revisión y reduce fricción en auditorías técnicas.
Usa tags para marcar versiones estables (<code>v1.2.0</code>) y conectar historial con despliegues.
Cada push ejecuta checks y evita romper main.
Un workflow básico ejecuta instalación de dependencias y tests en cada pull request. Si falla, no se mergea hasta resolverlo. Esa barrera automática evita regressions tontas.
Aunque el YAML no sea complejo, el impacto en calidad de equipo es enorme. Empieza simple y evoluciona con tus necesidades reales.
Aprende a mantener un historial legible (rebase interactivo, squash, tags) y automatiza checks de calidad con workflows en GitHub Actions.
Código del tema: git commit -m "feat: agrega validacion"
Reescribe localmente antes de publicar para que la PR sea fácil de revisar.
Con git rebase -i puedes agrupar commits ruidosos en uno o reordenarlos para que tengan sentido narrativo. Esto mejora revisión y reduce fricción en auditorías técnicas.
Usa tags para marcar versiones estables (v1.2.0) y conectar historial con despliegues.
git rebase -i HEAD~5
git tag -a v1.2.0 -m "release 1.2.0"
git push origin v1.2.0Cada push ejecuta checks y evita romper main.
Un workflow básico ejecuta instalación de dependencias y tests en cada pull request. Si falla, no se mergea hasta resolverlo. Esa barrera automática evita regressions tontas.
Aunque el YAML no sea complejo, el impacto en calidad de equipo es enorme. Empieza simple y evoluciona con tus necesidades reales.
mkdir -p .github/workflows
# crear archivo ci.yml con jobs de test
git add .github/workflows/ci.yml
git commit -m "ci: añade workflow de tests"Encaja con la parte de GitHub Actions porque hace visible que la automatización también necesita gobierno y reglas dentro del repositorio.
Aporta un ejemplo real de automatización útil: detectar dependencia vulnerable y proponer una vía concreta de actualización.
Refuerza la idea de que los checks automáticos no solo ejecutan tests: también pueden revisar seguridad y bloquear riesgos antes del merge.
