Resumen

  • CODEOWNERS define una política de asignación por rutas y ramas: GitHub puede solicitar automáticamente revisión a propietarios cuando una pull request que no es borrador modifica código de su ámbito.
  • El resultado depende del archivo de la rama base, de la ubicación elegida, del último patrón coincidente, de las rutas alteradas y de los permisos actuales. Un archivo visible no certifica un resultado pasado.
  • Un comprobante de revisión debe conservar por separado la configuración aplicable, el diff, la solicitud, la respuesta y las demás condiciones de fusión.

La regla estática no es el acontecimiento

La frase «los propietarios revisaron el cambio» parece breve, pero contiene una cadena. ¿Cuál era la rama base? ¿Qué rutas entraron en el diff? ¿Qué patrón prevaleció? ¿Las cuentas o equipos nombrados podían actuar en ese momento? ¿GitHub envió la solicitud y alguien respondió? ¿La aprobación de propietario era obligatoria o solo posible? Un archivo puede responder parcialmente a la primera pregunta y no responder las demás.

GitHub describe CODEOWNERS como un modo de definir personas o equipos responsables del código de un repositorio. Cuando una pull request no borrador modifica código con propietario, GitHub solicita automáticamente una revisión. Las pull requests en borrador no generan esa solicitud automática hasta que pasan a estar listas para revisión. La diferencia importa: una notificación encaminada no equivale a una revisión realizada.

Cada archivo pertenece a una rama. Las solicitudes usan la versión situada en la rama base de la pull request; desde un fork hacia una rama base ascendente se usa el archivo de esa rama ascendente. Por tanto, el mismo parche puede tener un mapa de propietarios distinto si se dirige a una rama de mantenimiento en lugar de a main. Un archivo que hoy aparece en la rama predeterminada, o uno introducido por la rama de origen, no acredita por sí mismo qué política resolvió el evento.

También hay una precedencia de ubicación. GitHub busca .github/, la raíz y docs/, en ese orden, y usa el primer archivo encontrado. Si el archivo supera tres megabytes no se carga; entonces no se muestra la propiedad ni se solicita a los propietarios correspondientes. No son detalles cosméticos: distinguen una política escrita de una política que realmente participó en una solicitud.

El último patrón puede cambiar el destinatario

Los patrones parecen acumulativos hasta que el orden interviene. GitHub indica que el último patrón coincidente tiene prioridad. Una regla amplia para * puede quedar desplazada por una regla posterior para *.js. Varios propietarios en una misma línea comparten el patrón; poner propietarios en líneas coincidentes diferentes hace que solo el último resultado prevalezca. Atribuir la revisión al propietario general sin reconstruir el orden puede describir una responsabilidad que no se aplicó.

Las condiciones de validez también cuentan. Las rutas son sensibles a mayúsculas y minúsculas. Una línea con sintaxis inválida se omite. Un usuario o equipo inexistente, o sin acceso suficiente, no queda asignado. Nada de esto acusa a un repositorio concreto. Solo impide que una captura de configuración se convierta en prueba automática de una decisión.

GitHub recomienda proteger el propio archivo CODEOWNERS definiendo quién lo posee. La recomendación es reveladora: una política que distribuye responsabilidad necesita una historia visible de quién puede cambiarla. De otro modo, el control de los propietarios del código descansa sobre una regla cuya modificación puede quedar sin explicar.

La revisión y la fusión usan superficies distintas

GitHub separa la solicitud automática de revisión de la opción de exigir aprobación de un propietario antes de fusionar. Esa exigencia se configura de forma separada. Si varios propietarios comparten un patrón, la aprobación de cualquiera de ellos puede bastar cuando la exigencia está activa. El archivo no convierte por sí solo a todos sus nombres en un bloqueo obligatorio.

Además, reglasets y protecciones de rama pueden operar juntos. Las reglas aplicables se agregan y, cuando una misma regla difiere, rige la versión más restrictiva. Puede haber requisitos independientes de pull request, aprobaciones, controles de estado, despliegues, comentarios resueltos o tipo de fusión, además de permisos de bypass. GitHub advierte que una pull request puede seguir bloqueada incluso con todas las revisiones requeridas si otra pull request que apunta al mismo commit de cabeza tiene una revisión pendiente o rechazada.

La aprobación sigue siendo información relevante: señala que los cambios parecen listos para fusionarse. Pero no es un historial completo de autoridad. Dice algo de una revisión; no demuestra por sí sola que la política de rutas se resolvió como se afirma ni que el resto de las puertas se abrió.

Un recibo de configuración a revisión

Para una afirmación importante, conviene conservar el identificador de pull request, referencias de base y cabeza y el conjunto de rutas cambiadas. A ello se añade la ubicación y la identidad del contenido CODEOWNERS de la rama base, el patrón ganador y los propietarios resultantes. Después vienen los eventos: solicitud de revisión, respuesta, fecha y diff cubierto.

Una afirmación sobre fusión debe nombrar por separado las reglas de protección o rulesets aplicables, los estados observados de cada condición y cualquier bypass documentado. Si falta un enlace de esa cadena, el relato debe terminar allí. Este recibo no crea una obligación nueva de GitHub; evita que una política estática actual se presente como la crónica completa de un acontecimiento anterior.

Fuentes

  1. GitHub Docs — About code owners
  2. GitHub Docs — Pull request reviews
  3. GitHub Docs — About rulesets
  4. GitHub Docs — Available rules for rulesets