Estructura de Ramas

El repositorio tiene hasta tres ramas permanentes. Todas las demás son temporales y se eliminan al fusionarse.

feat/456-login-google main ← MR formal
feat/456-login-google testing ← merge directo
feat/456-login-google next / stage ← condicional
mainProducción. Solo código aprobado vía MR formal.
testingQA e integración. Permite push/merge directo por developers.
next / stagePre-producción. Solo si el proyecto cuenta con instancia stage.

Protección por rama

Configuración main testing next / stage
Merge por Maintainers Developers Maintainers
Push directo Nadie Developers Maintainers
Force push Desactivado Desactivado Desactivado
Approval MR Sí (mín. 1) N/A N/A
Pipeline debe pasar
Justificación de permisos en testing: testing es un entorno volátil y reconstruible. Permitir push/merge directo por developers agiliza los procesos de integración y QA, evitando esperas innecesarias por aprobación del Team Leader para desplegar cambios al ambiente de pruebas.

Reset periódico de testing

testing puede acumular estado corrupto. Se recomienda resetearlo periódicamente (force-push de main a testing) solo por el Team Leader.

# Reset de testing desde main (solo Team Leader)
git checkout main
git pull origin main
git push origin main:testing --force
Regla de oro: Nunca push directo a main. testing permite push directo por developers para agilizar procesos de integración y QA.

Anexo: Diagrama de Arquitectura

Relación entre las tres ramas permanentes y las feature branches, con sus reglas de integración.

main Producción · Solo vía MR formal con approval + CI verde · Squash merge 🔒 Protegida testing QA · Push/merge directo por developers · Reconstruible ⚡ Push directo OK next / stage Pre-producción · Solo si el proyecto tiene instancia stage · Solo Maintainers 🔒 Protegida (opcional) feat/456-login-google fix/101-crash-pago MR formal merge directo MR formal merge directo