Este es el flujo completo que sigue un desarrollador desde que toma un workitem hasta que el código llega a producción.
main actualizado# Actualizar main primero
git checkout main
git pull origin main
# Crear la rama con el número del workitem de GitLab
git checkout -b feat/456-login-con-googlemain, no desde testing.git add .
git commit -m "feat: agrega pantalla de login con Google" \
-m "Refs #456"
git push origin feat/456-login-con-googlemainEl MR se abre hacia main desde el primer momento (puede abrirse como Draft). Se debe:
main, nunca directamente a testing. Puede abrirse como Draft desde el primer push.testing para validación QAUna vez que el MR está en revisión o aprobado, integrar los cambios a testing para que QA pueda validar:
git checkout testing
git pull origin testing
git merge feat/456-login-con-google
git push origin testingtestingQA ejecuta las pruebas definidas en el workitem. Si encuentra errores:
testing (repite Paso 4). El MR hacia main se actualiza automáticamente.mainUna vez que:
testing.Se procede a hacer merge del MR a main con squash commit.
Eliminar la feature branch después del merge para mantener el repositorio limpio. GitLab puede configurarse para hacerlo automáticamente.
Para mantener la feature branch sincronizada con los cambios que otros devs han integrado a main:
git checkout feat/456-login-con-google
git fetch origin main
git merge origin/main
# Resolver conflictos si existen
git push origin feat/456-login-con-googleVisión general de los 7 pasos: desde la creación de la rama hasta el merge a producción.
