Por qué `main` es sagrado

"Main siempre está en verde" significa una cosa: en cualquier momento, la rama main es desplegable a producción. No "funciona en su mayoría", no "funciona si sabes qué commits omitir" — desplegable. Ahora mismo. Sin intervención manual.

Esta es una barra más alta de lo que la mayoría de los equipos se da cuenta. Significa que cada commit en main ha pasado pruebas automatizadas, ha sido revisado por un humano y no depende de trabajo incompleto de otra rama. Significa que puedes desplegar un viernes a las 4 PM sin ansiedad, porque main no es un trabajo en progreso — es el producto terminado en cada commit.

El mecanismo que hace cumplir esto es la integración continua (CI). Cada PR ejecuta el conjunto de pruebas, el linter y el verificador de tipos antes de poder fusionarse. Si alguna verificación falla, el PR se bloquea. El ingeniero corrige el problema en su rama — no en main, no después de fusionar, no "más tarde". CI es el guardián que asegura que main nunca se degrade.

Los equipos sin esta disciplina regularmente se encuentran en un estado donde main está roto y nadie sabe cuál de las últimas cinco fusiones lo causó. En ese punto, todos en el equipo están bloqueados — no pueden hacer pull de código nuevo, no pueden iniciar nuevas ramas desde un estado funcional y no pueden desplegar. El costo de un main en rojo no es el problema de un ingeniero. Es el problema de todo el equipo, agravándose cada minuto que permanece roto.

Las reglas de protección de rama son la aplicación automatizada de "main siempre está en verde". Cada plataforma importante de alojamiento Git — GitHub, GitLab, Bitbucket — las soporta, y deben configurarse el día uno de cualquier proyecto serio.

Las tres reglas que más importan:

• Revisiones de PR requeridas. No hay pushes directos a main. Cada cambio pasa por un PR y al menos una aprobación. Esto atrapa el impulso de "solo voy a hacer push de esta corrección rápida" que representa una parte desproporcionada de incidentes de producción.
• Verificaciones de estado requeridas. CI debe pasar antes de fusionar. Pruebas, linting, verificación de tipos — lo que sea que ejecute tu pipeline. Una verificación fallida bloquea el botón de fusión. Sin anulaciones, sin "lo arreglaré en el siguiente commit".
• Historial lineal. Requiere que las ramas estén actualizadas con main antes de fusionar (rebase o cola de fusión). Esto previene la situación donde dos PRs pasan CI individualmente pero se rompen cuando se combinan — porque cada PR se prueba contra el estado actual de main, no una instantánea desactualizada.

Algunos equipos resisten las reglas de protección porque se sienten como fricción. Son fricción — fricción intencional que previene la clase más costosa de errores. Configurar estas reglas toma cinco minutos. Recuperarse de un force-push que sobrescribe el trabajo de un compañero toma horas, más el daño a la confianza. Las matemáticas no están cerca.

Cuando un despliegue rompe producción, los ingenieros enfrentan una elección: corregir hacia adelante o revertir. El instinto es casi siempre corregir hacia adelante — encontrar el bug, escribir un parche, hacer push. Pero ese instinto está equivocado bajo presión.

Un revert es un solo comando que deshace un commit conocido limpiamente:

git revert abc123f
# Creates a new commit that undoes abc123f
# Main is green again in minutes

La alternativa de corrección de pánico se ve así: un ingeniero encorvado sobre su teclado a las 11 PM, escribiendo código nuevo bajo presión, omitiendo pruebas porque "es solo una corrección de una línea", haciendo push directamente a main porque "no tenemos tiempo para un PR". Esa corrección de una línea introduce un segundo bug el 40% del tiempo, porque el código escrito bajo adrenalina es código escrito sin contexto completo.

La regla es simple: revertir primero, corregir después. Regresa main a verde inmediatamente — eso desbloquea a todo el equipo y detiene la hemorragia. Luego, sin la presión, escribe una corrección adecuada en una rama con pruebas, revisión y CI. La corrección se envía una hora o un día después, pero se envía correctamente.

Los reverts se sienten como admitir un fracaso. No lo son. Son el camino más rápido de regreso a un estado funcional, y dejan el commit original en el historial como documentación de lo que salió mal. Un equipo que revierte rápidamente es un equipo que envía con confianza, porque el costo de un mal despliegue es minutos de inactividad en lugar de horas de apagar incendios.