Nota: Solo las organizaciones que usan GitHub Enterprise Cloud pueden crear roles de repositorio personalizados.Para más información sobre cómo probar GitHub Enterprise Cloud de forma gratuita, vea "Configuración de una versión de prueba de GitHub Enterprise Cloud".
Acerca de los roles de repositorio personalizados
Para llevar a cabo cualquier acción en GitHub Enterprise Cloud, tal como crear una solicitud de cambios en un repositorio o cambiar los ajustes de facturación de una organización, los individuos deben tener acceso suficiente a la cuenta o recurso relevante. Los permisos son los que controlan este tipo de acceso. Un permiso es la capacidad de llevar a cabo una acción específica. Por ejemplo, la capacidad de borrar una propuesta constituye un permiso. Un rol es un conjunto de permisos que puedes asignar a los individuos o equipos.
Dentro de una organización, puedes asignar roles a nivel de repositorio, equipo u organización. Para más información sobre los diferentes niveles de roles, consulta "Roles en una organización".
Puedes tener un control más pormenorizado sobre los permisos que concedes en el nivel de repositorio mediante la creación de hasta cinco . Un rol de repositorio personalizado es un conjunto de permisos configurables con un nombre personalizado de tu elección. Para más información, consulta "Administrar roles de repositorio personalizados en una organización".
Después de que creas un rol personalizado, cualquiera con acceso administrativo a un repositorio puede asignar el rol a un individuo o equipo. Para obtener más información, vea «Administrar el acceso de una persona a un repositorio de una organización» y «Administrar el acceso de equipo a un repositorio de la organización».
También puedes usar la API de REST para crear y administrar roles de repositorio personalizados. Para obtener más información, vea «Puntos de conexión de API REST para roles de repositorio personalizados».
Los roles de repositorio personalizados administran el acceso a repositorios específicos de la organización. Para conceder acceso a todos los repositorios y controlar el acceso a la configuración de administración de la organización, puede usar roles de organización personalizados. Consulte "Acerca de los roles personalizados de organización".
Los roles de organización personalizados difieren de los roles de repositorio al conceder permisos en todos los repositorios actuales y futuros de la organización. Pero los roles de repositorio personalizados le permiten conceder permisos a repositorios específicos dentro de la organización.
Acerca del rol heredado
Cuando creas un rol de repositorio personalizado, comenzarás eligiendo un rol heredado de un conjunto de opciones predefinidas. El rol heredado determinará el conjunto inicial de permisos que se incluyen en el rol personalizado. Entonces, podrás seguir personalizando el rol si eliges permisos adicionales para asignarle a este. Para obtener la lista completa de permisos disponibles, vea "Permisos adicionales para roles personalizados".
Tus opciones para escoger el rol heredado se estandarizan para tipos diferentes de contribuyentes en tu repositorio.
| Rol heredado | Diseñada para |
|---|---|
| Lectura | Contribuyentes sin código que quieren ver o debatir en tu proyecto |
| Evaluación de errores | Contribuyentes que necesitan administrar propuestas y solicitudes de cambio proactivamente sin acceso de escritura |
| Escritura | Miembros de la organización y colaboradores que suben información a tu proyecto activamente |
| Mantenimiento | Administradores de proyectos que necesitan administrar el repositorio sin acceso a las acciones destructivas o sensibles |
Roles personalizados de ejemplo
Aquí te mostramos ejemplos de los roles de repositorio personalizados que puedes configurar.
| Rol de repositorio personalizado | Resumen | Rol heredado | Permisos adicionales |
|---|---|---|---|
| Ingeniero de seguridad | Puede contribuir con código y mantener el mapa de seguridad | Mantenimiento | Borrar los resultados del escaneo de código |
| Contractor | Puede desarrollar integraciones de webhooks | Escritura | Administrar webhooks |
| Adminsitrador de comunidad | Puede manejar todas las interacciones de la comunidad sin poder contribuir con código | Lectura | - Marcar una incidencia como duplicada - Administrar la configuración de la página de GitHub - Administrar la configuración de la wiki - Establecer la versión preliminar social - Editar metadatos del repositorio - Discusiones de evaluación de prioridades |
Permisos adicionales para los roles personalizados
Después de haber elegido un rol heredado, puedes seleccionar los permisos adicionales para tu rol personalizado.
Solo puedes elegir un permiso adicional si no se ha incluido ya en el rol heredado. Por ejemplo, si el rol heredado ofrece acceso de Escritura en un repositorio, el permiso de "Cerrar una solicitud de incorporación de cambios" ya se habrá incluido en el rol heredado.
Discussions
- Create a discussion category
- Edit a discussion category
- Delete a discussion category
- Mark or unmark discussion answers
- Hide or unhide discussion comments
- Convert issues to discussions
For more information, see "documentación GitHub Discussions."
Issue and Pull Requests
- Assign or remove a user
- Add or remove a label
Issue
- Close an issue
- Reopen a closed issue
- Delete an issue
- Mark an issue as a duplicate
Pull Request
- Close a pull request
- Reopen a closed pull request
- Request a pull request review
Repository
- Set milestones
- Manage wiki settings
- Manage project settings
- Manage pull request merging settings
- Manage GitHub Pages settings (see "Configurar una fuente de publicación para tu sitio de Páginas de GitHub")
- Manage webhooks
- Manage deploy keys
- Edit repository metadata
- Set interaction limits
- Set the social preview
- Push commits to protected branches
- Base role must be
write - Branch protection rules will still apply
- Base role must be
- Create protected tags
- Delete protected tags
- Bypass branch protections
- Edit repository rules
Security
- View code scanning results
- Dismiss or reopen code scanning results
- Delete code scanning results
- View Dependabot alerts
- Dismiss or reopen Dependabot alerts
- View secret scanning results
- Dismiss or reopen secret scanning results
Precedencia de los distintos niveles de acceso
Roles and permissions are additive. If a person is given different levels of access through different avenues, such as team membership and the base permissions for an organization, the user has the sum of all access grants. For example, if an organization owner gives an organization member a custom role that uses the "Read" inherited role, and then an organization owner sets the organization's base permission to "Write", then members with the custom role will have write access, along with any additional permissions included in the custom role.
Si una persona obtuvo un acceso que ocasione conflictos, se mostrará una advertencia en la página de acceso del repositorio. La advertencia se mostrará como " Roles mixtos" junto a la persona que tenga el acceso que ocasiona los conflictos. Para ver la fuente del acceso que ocasiona el conflicto, pase el puntero del mouse sobre el icono de advertencia o haga clic en Roles mixtos.
To resolve conflicting access, you can adjust your organization's base permissions or the team's access, or edit the custom role. For more information, see: