Lo que lograrás

Harás rollback de un release problemático — primero revirtiendo commits para deshacer el cambio en la historia funcional, luego re-tageando una versión anterior para re-deployment.

Dos escenarios

• Rollback del deployment.
• Rollback del código.

Escenario 1: deploy un tag más antiguo

git tag --sort=-v:refname | head

gh workflow run deploy.yml -f tag=v2.3.5

Escenario 2: revertir los commits

git checkout main
git pull
git revert <bad-sha>
git push

Revertir un merge commit

git log --merges -10
git revert -m 1 <merge-sha>
git push

Revertir un rango

git revert <older-sha>..<newer-sha>

Tagear el rollback

git tag -a v2.4.1 -m "Roll back v2.4.0 due to checkout regression"
git push origin v2.4.1

El antipatrón forward-fix

• El fix toma horas y los clientes están impactados ahora.
• El bug es corruptor de datos.
• El fix necesita prueba cuidadosa.

Migraciones de base de datos y rollback

• Las migraciones deberían ser aditivas.
• Evita cambios disruptivos en migraciones.
• Ten un camino de down-migration probado.
• Usa feature flags para gatear caminos de código.

Coordinar con el equipo

• Anuncia el rollback.
• Documenta el SHA siendo revertido.
• Abre un issue de seguimiento.
• Programa un post-mortem.

Evitar rollbacks

• Releases canary.
• Feature flags.
• Validación pre-release.
• Releases más pequeños.

Reaplicar tras fix

git revert <revert-sha>
git commit -am "Fix the issue that caused the original revert"