GitFlow
Flujo de trabajo con ramas para equipos de desarrollo
develop → main | Easypanel Deploy | GitHub Branch Protection
Ambiente Desarrollo Ambiente Producción
rama: develop rama: main
1. Las 4 ramas que vas a usar
Rama Para qué sirve Ambiente Quien pushea
main Código en producción. Solo PRODUCCIÓN NADIE directo. Solo PR
código probado. (Easypanel) desde develop.
develop Integración de features. Donde DESARROLLO El equipo, via PR desde
se juntan todos los cambios. (Easypanel) feature/...
feature/xxx Una nueva funcionalidad o Local / preview El dev dueño de la
mejora puntual. Sale de develop, feature.
vuelve a develop.
hotfix/xxx Fix urgente en producción. Sale Local / preview Dev que atiende la
de main, vuelve a main Y a urgencia. Requiere 2
develop. PRs.
2. Flujo paso a paso
1 Crear rama feature desde develop
git checkout develop && git pull && git checkout -b feature/mi-nueva-feature
2 Desarrollar y commitear en la feature
git add . && git commit -m 'feat: descripción del cambio'
3 Subir la rama al repositorio
git push origin feature/mi-nueva-feature
4 Abrir Pull Request: feature -> develop
En GitHub/GitLab: PR de feature/mi-nueva-feature hacia develop. Pedir review si aplica.
5 Merge a develop (aprobado el PR)
Se mergea a develop. Easypanel detecta el push y despliega al ambiente de desarrollo automáticamente.
6 Probar en desarrollo (Easypanel dev)
Validar que todo funcione correctamente en el ambiente de desarrollo antes de subir a producción.
7 Abrir PR: develop -> main (para producción)
Cuando el conjunto de cambios está listo. PR de develop hacia main. Se requiere aprobación.
8 Merge a main + tag automatico
Se aprueba y mergea. El CI/CD crea el tag de versión automáticamente. Easypanel prod se actualiza.
3. Flujo hotfix (urgencias en producción)
Caso: hay un bug crítico en producción que no puede esperar el ciclo normal develop -> main.
1 Crear hotfix desde main (no desde develop)
git checkout main && git pull && git checkout -b hotfix/descripcion-del-bug
2 Corregir el bug y commitear
git add . && git commit -m 'fix: descripción del fix urgente'
3 Subir la rama
git push origin hotfix/descripción-del-bug
4 PR hotfix -> main (producción)
Abrir PR hacia main. Se aprueba rápido. Al mergearse, GitHub Actions genera el nuevo tag
automáticamente y Easypanel despliega.
5 IMPORTANTE: PR hotfix -> develop (backport)
Abrir un segundo PR del mismo hotfix hacia develop. Esto es crítico: si no se hace, el fix se pierde la
próxima vez que se merge develop a main.
6 Verificar en ambos ambientes
Confirmar que el fix funciona en producción (main) y que develop también tiene el fix incorporado.
REGLA CLAVE del hotfix: siempre 2 PRs. Uno a main (para producción urgente) y otro a develop (para no
perder el fix). Si solo se mergea a main, la próxima release va a volver a tener el bug.
4. Ejemplo real de nombres de ramas
# Features nuevas
feature/login-google
feature/dashboard-reportes
feature/api-pagos
# Hotfixes urgentes (salen de main, se backportean a develop)
hotfix/error-calculo-precio
hotfix/fix-crash-mobile
hotfix/token-expirado-login
# Regla: nombres en minuscula, guiones medios, sin espacios ni tildes
TIP: Cada feature debe ser pequeña y enfocada. Si una rama tarda más de 2-3 días, probablemente se
puede dividir en features más chicas.
Protección de la rama main
Restricciones para que nadie pueda romper producción
Objetivo: a main SOLO se llega por Pull Request desde develop, con aprobación, y el tag de versión se crea
automáticamente. Ningún desarrollador puede hacer push directo.
1. Configurar Branch Protection en GitHub
Ir a: Settings del repo > Branches > Add branch ruleset (o Add rule)
# Regla Descripción Nivel
1 Requerir Pull Request Activar "Require a pull request before merging". Mínimo 1 CRÍTICO
aprobación. Nadie puede hacer merge sin PR.
2 Bloquear push directo Activar "Restrict pushes that create files" o directamente CRÍTICO
"Block force pushes". Impide push y force-push directos a
main.
3 Requerir branch Activar "Require branches to be up to date before ALTO
actualizado merging". El PR de develop debe tener los últimos
cambios de main antes de poder mergearse.
4 No eliminar main Activar "Restrict deletions". Evita que alguien borre ALTO
accidentalmente la rama principal.
2. Tag automático al mergear a main (GitHub Actions)
Crear el archivo .github/workflows/[Link] en el repositorio:
name: Auto Tag on Main
on:
push:
branches: [main]
jobs:
tag:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Get next version
id: version
run: |
LAST=$(git tag --sort=-v:refname | head -n1)
if [ -z "$LAST" ]; then LAST="v0.0.0"; fi
PATCH=$(echo $LAST | awk -F. '{print $NF+1}')
echo "tag=$(echo $LAST | sed "s/\.[0-9]*$/.$PATCH/")" >> $GITHUB_OUTPUT
- name: Create tag
run: |
git config [Link] 'github-actions'
git config [Link] 'actions@[Link]'
git tag ${{ [Link] }}
git push origin ${{ [Link] }}
Este workflow crea tags automáticos tipo v1.0.1, v1.0.2 cada vez que se mergea un PR a main. Easypanel
puede usar el tag o el evento push a main para disparar el deploy a producción.
3. Resumen: quien puede hacer que
Acción feature -> develop develop -> main push directo a main
Developer del equipo SI (via PR) NO NO
Tech Lead / Admin SI (via PR) SI (aprueba PR) NO (igual bloqueado)
GitHub Actions (CI/CD) - - SI (solo tags)
CONSEJO: Si sos el único admin y a veces necesitas hacer hotfix urgente, podes crear una regla de
excepción para admins o usar un bypass temporal. Pero como hábito, incluso los admins deberían usar el
flujo de PRs.