Frecuentemente publicamos actualizaciones de nuestra documentación. Es posible que la traducción de esta página esté en curso. Para conocer la información más actual, visita la documentación en inglés. Si existe un problema con las traducciones en esta página, por favor infórmanos.

Esta versión de GitHub Enterprise se discontinuó el 2021-03-02. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener un mejor desempeño, más seguridad y nuevas características, actualiza a la última versión de GitHub Enterprise. Para obtener ayuda con la actualización, contacta al soporte de GitHub Enterprise.

Acerca de los propietarios del código

Puedes usar un archivo CODEOWNERS para definir individuos o equipos que sean responsables del código en un repositorio.

Puedes definir a los propietarios del código en repositorios públicos con GitHub Free y GitHub Free para organizaciones, y en repositorios privados y públicos con GitHub Pro, GitHub Team, GitHub Enterprise Cloud, y Servidor de GitHub Enterprise.

En este artículo

Las personas con permisos administrativos o de propietario pueden configurar un archivo CODEOWNERS en un repositorio.

Las personas que elijas como propietarios del código deben tener permisos de escritura para el repositorio. Cuando el propietario del código es un equipo, ese equipo debe tener permisos de escritura, incluso si todos los miembros individuales del equipo ya tienen permisos de escritura, a través de la membresía de la organización o a través de la membresía de otro equipo.

Acerca de los propietarios del código

Cuando alguien abre una solicitud de extracción que modifica el código que pertenece a alguien, automáticamente se les solicita una revisión a los propietarios del mismo. Lo que no se solicita automáticamente a estos propietarios es la revisión de los borradores de solicitudes de extracción. Para obtener más información acerca de las solicitudes de extracción en borrador "Acerca de las solicitudes de extracción". Se notificará automáticamente a los dueños del código cuando marques un borrador de solicitud de extracción como listo para revisión. Si conviertes una solicitud de extracción en borrador, las personas que ya estén suscritas a las notificaciones no se darán de baja automáticamente. Para obtener más información, consulta la sección "Cambiar el estado de una solicitud de extracción".

Cuando alguien con permisos administrativos o de propietario ha activado las revisiones requeridas, opcionalmente, también pueden solicitar aprobación de un propietario del código antes de que el autor pueda fusionar una solicitud de extracción en el repositorio. Para obtener más información, consulta la sección "Habilitar revisiones requeridas para solicitudes de extracción".

Si un equipo habilitó las tareas de revisión de código, las aprobaciones individuales no satisfarán el requisito de aprobación del propietario del código en una rama protegida. Para obtener más información, consulta la sección "Administrar una tarea de revisión de código para tu equipo".

Ubicación del archivo CODEOWNERS

Para usar un archivo CODEOWNERS, crea un archivo nuevo llamado CODEOWNERS en la raíz, docs/, o en el directorio .github/ del repositorio, en la rama en la que quieras agregar los propietarios del código.

Cada archivo CODEOWNERS asigna los propietarios del código para una única rama en el repositorio. Por lo tanto, puedes asignar propietarios diferentes para el código en ramas diferentes, tal como @octo-org/codeowners-team para una base de código en la rama predeterminada y @octocat para un sitio de Páginas de GitHub en la rama de gh-pages.

Para que los propietarios del código reciban las solicitudes de revisión, el archivo CODEOWNERS debe estar en la rama base de la solicitud de extracción. Por ejemplo, si asignas @octocat como el propietario del código para los archivos .js en la rama gh-pages de tu repositorio, @octocat recibirá las solicitudes de revisión cuando una solicitud de extracción con cambios en los archivos .js se abra entre la rama de encabezado y gh-pages.

Sintáxis de CODEOWNERS

Un archivo CODEOWNERS usa un patrón que sigue las mismas reglas usadas en los archivos gitignore. El patrón es seguido por uno o más nombres de usuarios o nombres de equipos de GitHub usando el formato estándar @username o @org/team-name. También puedes hacer referencia a un usuario mediante una dirección de correo electrónico que haya sido agregada a su cuenta de GitHub Enterprise, por ejemplo user@example.com.

Si cualquier línea de tu archivo de CODEOWNERS contiene una sintaxi inválida, el archivo no se detectará y no se utilizará para solicitar revisiones. Las sintaxis inválidas contemplan a los comentarios dentro de las líneas y a los nombres de usuario o equipo que no existen en GitHub Enterprise.

Ejemplo de un archivo CODEOWNERS

# Este es un comentario.
# Cada línea es el patrón de un archivo seguido por uno o más propietarios.

# Estos propietarios serán los propietarios predeterminados para todo en # el repositorio. A menos que una coincidencia posterior tenga prioridad, se le solicitará # revisión a # @global-owner1 y @global-owner2 cuando alguien abra una solicitud de extracción.
*       @global-owner1 @global-owner2

# El orden es importante; el último patrón en coincidir tiene la mayor
# prioridad. Cuando alguien abre una solicitud de extracción que solo
# modifica archivos JS, solo se le solicitará una revisión a @js-owner y no al/los # propietario(s) general(es).
*.js    @js-owner

# Si prefieres, también puedes usar direcciones de correo electrónico. Serán
# usadas para buscar usuarios como hacemos para los 
# correos electrónicos del autor de la confirmación.
*.go docs@example.com

# En este ejemplo, @doctocat posee cualquier archivo en el 
# directorio build/logs en la raíz del repositorio y cualquiera de sus
# subdirectorios.
/build/logs/ @doctocat

# El patrón `docs/*` coincidirá con archivos como
# `docs/getting-started.md` pero no con otros archivos anidados como
# `docs/build-app/troubleshooting.md`.
docs/*  docs@example.com

# En este ejemplo, @octocat posee cualquier archivo en el directorio de las apps
# en cualquier lugar en tu repositorio.
apps/ @octocat

# En este ejemplo, @doctocat posee cualquier archivo en el 
# directorio `/docs` en la raíz de tu repositorio.
/docs/ @doctocat

Leer más