Configurando Reglas de Protección de Ramas
Configura protección de ramas para hacer cumplir la calidad de código y prevenir cambios accidentales en ramas críticas.
5 min de lectura
Las reglas de protección de ramas son tus guardianes automatizados. Aseguran que los code reviews ocurran, los tests pasen, y las ramas críticas permanezcan estables. Una protección correctamente configurada previene errores costosos y hace cumplir estándares del equipo sin policía manual.
Opciones de Protección
| Protección | Propósito | Recomendado |
|---|---|---|
| Requerir PR | Sin push directo | ✓ Siempre |
| Requerir review | Calidad de código | ✓ Siempre |
| Requerir CI | Tests pasen | ✓ Siempre |
| Actualizada | Sin conflictos de merge | ✓ Usualmente |
| Bloquear force push | Preservar historial | ✓ Siempre |
Configuración en GitHub
Configurando Protección
PROTECCIÓN DE RAMAS EN GITHUB
═════════════════════════════
ACCESO:
─────────────────────────────────────
Settings → Branches → Add rule
├── Patrón de nombre de rama: main
└── Configurar protecciones
PROTECCIONES REQUERIDAS:
─────────────────────────────────────
☑ Requerir pull request antes de merge
├── Aprobaciones requeridas: 1 (equipo pequeño) o 2 (más grande)
├── Descartar aprobaciones de PR obsoletas
│ └── Cambios después de aprobación necesitan re-review
├── Requerir review de Code Owners
│ └── Usar archivo CODEOWNERS
└── Requerir aprobación del push más reciente
└── Previene commits a escondidas después de aprobación
☑ Requerir que status checks pasen
├── Requerir que ramas estén actualizadas
├── Agregar checks:
│ ├── ci/build
│ ├── ci/test
│ ├── ci/lint
│ └── security/scan
└── Todos deben pasar antes de merge
☑ Requerir resolución de conversaciones
└── Todos los comentarios de PR deben estar resueltos
☑ Requerir commits firmados (opcional)
└── Para repos de alta seguridad
RESTRICCIONES DE PUSH:
─────────────────────────────────────
☑ Restringir quién puede hacer push a ramas coincidentes
├── Seleccionar equipos/usuarios permitidos
├── Solo para emergencias
└── Usualmente: nadie (todo vía PR)
☑ No permitir bypass de configuraciones anteriores
└── Incluso admins deben seguir reglas
☑ Bloquear force pushes
└── Proteger historial
☑ Bloquear eliminaciones
└── No se pueden eliminar ramas protegidas
Rulesets de GitHub
RULESETS DE GITHUB (MÁS NUEVO)
══════════════════════════════
VENTAJAS SOBRE BRANCH RULES:
─────────────────────────────────────
├── Aplicar a nivel de organización
├── Apuntar múltiples ramas/repos
├── Permisos de bypass más granulares
├── Reglas de tags incluidas
├── Mejor audit trail
└── Recomendado para enterprise
CREANDO UN RULESET:
─────────────────────────────────────
Repository → Settings → Rules → Rulesets
Nuevo ruleset:
├── Nombre: "Protección de Producción"
├── Enforcement: Activo
├── Ramas objetivo: main, release/*
└── Configurar reglas
OPCIONES DE RULESET:
─────────────────────────────────────
Reglas de rama:
├── Restringir creaciones
├── Restringir actualizaciones
├── Restringir eliminaciones
├── Requerir historial lineal
├── Requerir que deployments tengan éxito
├── Requerir commits firmados
├── Requerir pull request
├── Requerir status checks
└── Bloquear force pushes
Lista de bypass:
├── Administradores del repo
├── Equipos específicos (ej., Equipo de Release)
├── Deploy keys
└── GitHub Actions (si aplica)
Configuración por Rama
Niveles de Protección
PROTECCIÓN POR TIPO DE RAMA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MAIN (Producción): │
│ ├── Máxima protección │
│ ├── 2 aprobaciones requeridas │
│ ├── Todos los status checks │
│ ├── Code owners requeridos │
│ ├── No bypass (incluso admins) │
│ └── Bloquear force push y eliminación │
│ │
│ DEVELOP (Integración): │
│ ├── Protección alta │
│ ├── 1 aprobación requerida │
│ ├── Status checks principales │
│ ├── Code owners opcional │
│ └── Bloquear force push │
│ │
│ RELEASE/* (Releases): │
│ ├── Protección similar a main │
│ ├── 1-2 aprobaciones │
│ ├── Todos los status checks │
│ └── Bloquear cambios después de code freeze │
│ │
│ FEATURE/* (Features): │
│ ├── Protección ligera o ninguna │
│ ├── CI checks solamente │
│ └── Flexibilidad para desarrollo │
│ │
└─────────────────────────────────────────────────────────────┘
Manejo de Emergencias
Procesos de Bypass
PROCEDIMIENTO DE HOTFIX:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ESCENARIO: Bug crítico en producción │
│ │
│ OPCIÓN 1: Rama hotfix con reglas reducidas │
│ ├── Crear rama hotfix/* │
│ ├── Reglas: 1 aprobación, tests críticos │
│ ├── Merge rápido a main │
│ └── Backport a develop │
│ │
│ OPCIÓN 2: Bypass temporal │
│ ├── Admin aprueba bypass │
│ ├── Documentar razón │
│ ├── Hacer fix │
│ ├── Review post-merge │
│ └── Registrar en audit log │
│ │
│ IMPORTANTE: │
│ • Siempre documentar el por qué │
│ • Hacer review post-mortem │
│ • No normalizar bypasses │
│ │
└─────────────────────────────────────────────────────────────┘