Branch protection para coding agents: no force-push a main, no bypass
Resumen
Una branch protection rule bloquea force push y delete por default, y puede exigir status checks y PRs. Un solo rule aplica a la vez (fnmatch). Los admins pueden bypassear salvo que la regla los incluya. El agente no desactiva reglas ni mergea a main. Docs GitHub About protected branches.
Qué resuelve
Esta pieza se queda en la decisión práctica: qué instalar, qué riesgo agrega y cómo aplicarlo sin romper operación.
main protegida no es un estilo: es una regla. GitHub: collaborators no pueden pushear/force-push/borrar la rama si la protection lo dice, y un PR puede exigir status checks verdes o historial linear. Default de una rule: sin force push, sin delete.
Un agente que hace git push --force origin main o gh api para bajar la protection es un incidente. Este loop: nunca merge. Entrega un PR (gh pr).
Qué exige la rule (típico)
- PR obligatorio antes de merge.
- N reviews.
- Status checks concretos (nombres de job únicos entre workflows: la doc avisa que el mismo job name en dos workflows ambigua el check y bloquea el merge).
- Conversation resolution.
- Linear history (rebase/squash only).
- Incluir admins (opcional; si no, un admin agent con PAT bypassea).
Pattern fnmatch: *release*. Solo una branch protection rule aplica a la vez; si hay varias, es difícil saber cuál. Rulesets no tienen esa restricción. El agente no “arregla” creando una segunda rule.
Bypass lists: solo en repos de organización. No te agregues.
Receta AGENTS.md
Never push or force-push protected branches (main).
Never edit branch protection via API unless the ticket is that.
If CI is red, fix the job; do not rename jobs to dodge required checks.
Job names unique across workflows.
Deliver a PR URL, not a merge.
Si el check requerido se llama test y tienes dos workflows con test, GitHub no sabe cuál. Renombrar a test-unit / test-e2e es el fix, no quitar el required check.
FAQ
¿Auto-merge? GitHub puede mergear cuando todo está verde. El agente no lo activa en un repo ajeno.
¿Rulesets vs protection? Rulesets son el modelo nuevo; pueden apilarse. No conviertas protection a rulesets de paso.
¿Admin PAT? Sigue sin force-push a main en este flujo. “Puedo” ≠ “debo”.
¿Borrar la rama del agente? Las de feature no están protegidas. main sí.
El curso instalar un agente no cubre protection. Sandboxing no bloquea git push.
Verificado 2026-09-03 contra GitHub Docs — About protected branches (defaults, unique job names, one rule at a time).
Si gh pr merge falla porque main está checked out en otro worktree, no uses gh api merge como atajo para saltarte checks. El merge API aún puede respetar protection; si no, peor. Reporta el bloqueo.
Lecturas relacionadas
Sigue explorando Coding Agents y otras piezas para builders.
git status para coding agents: porcelain, XY, no el long
Reusable workflows: workflow_call, no copies el YAML entre repos
schedule (cron) en GitHub Actions: UTC, no cada minuto
