Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Servicios de Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
Administre quién puede acceder a los repositorios de Git y qué acciones pueden realizar. Establezca permisos en el nivel Todos los repositorios para aplicarlos a todos los repositorios de Git de un proyecto o establezca permisos para un repositorio individual. Los repositorios individuales heredan los permisos de la entrada de repositorios git de nivel de proyecto.
Nota
Las ramas heredan un subconjunto de permisos de las asignaciones realizadas en el nivel de repositorio. Para obtener información sobre los permisos y directivas de rama, consulte Establecimiento de permisos de rama y Mejora de la calidad del código con directivas de rama.
Para obtener una guía de seguridad completa que abarque los permisos de repositorio, las directivas de rama, la firma de confirmaciones y los escenarios de implementación del mundo real, consulte Protección de repositorios y solicitudes de incorporación de cambios.
Para obtener instrucciones sobre quién proporcionar mayores niveles de permisos, consulte Administración del acceso mediante permisos.
Requisitos previos
| Categoría | Requisitos |
|---|---|
| Acceso al proyecto | Pertenencia a un proyecto de Azure DevOps. |
| Permisos | Administrar permisos para la entrada de repositorios git de nivel de proyecto para administrar todos los repositorios del proyecto o Administrar permisos para que un repositorio individual administre ese repositorio. Los miembros del grupo administradores de Project tienen este permiso de forma predeterminada. Para obtener más información, consulte Referencia de permisos y grupos. |
| Servicios | Azure Repos habilitado. |
Revisión de los permisos de repositorio predeterminados
De forma predeterminada, los miembros del grupo Colaboradores del proyecto tienen permisos para contribuir a un repositorio. Este nivel de permisos incluye la capacidad de crear ramas, crear etiquetas y administrar notas. Para obtener una descripción de cada grupo de seguridad y nivel de permiso, consulte Referencia de permisos y grupos.
Permiso
Lectores
Colaboradores
Administradores de compilación
Administradores de proyectos
Leer (clonar, extraer y explorar el contenido de un repositorio); también puede crear, comentar, votar y Contribuir a las solicitudes de extracción
✔️
✔️
✔️
✔️
Contribuir, Crear rama, Crear etiqueta y Administrar notas
✔️
✔️
✔️
Crear repositorio, Eliminar repositorio y Cambiar nombre de repositorio
✔️
Editar directivas, Administrar permisos, Quitar bloqueos de otros
✔️
Omitir las directivas cuando finalicen las solicitudes de incorporación de cambios, Omitir las directivas al insertar, Forzar envío de cambios (reescribir el historial y eliminar ramas y etiquetas)
(no configurado para ningún grupo de seguridad)
A partir de Azure DevOps sprint 224, los creadores de ramas no obtienen automáticamente el permiso Editar directivas. Este permiso no se concede aunque la configuración administración de permisos esté activada para el repositorio. Conceda directivas de edición explícitamente a través de la herencia, la pertenencia a grupos o una asignación directa.
En Azure DevOps Server 2022.1 y versiones posteriores, los creadores de ramas no obtienen automáticamente el permiso Editar directivas. Este permiso no se concede aunque la configuración administración de permisos esté activada para el repositorio. Conceda directivas de edición explícitamente a través de la herencia, la pertenencia a grupos o una asignación directa. Para obtener más información, consulte Azure DevOps Server notas de la versión de Update 1 de Azure DevOps Server 2022.
Descripción de los estados de permisos
Antes de cambiar un permiso, revise cómo Azure DevOps evalúa los estados de permisos:
- No se establece no concede ni deniega el permiso. Los permisos asignados a través de otro grupo o heredados de un ámbito primario todavía se pueden aplicar.
- Permitir concede el permiso a menos que una denegación más específica o aplicable lo invalide.
- La denegación generalmente invalida Permitir, incluidos los permisos heredados o concedidos a través de otro grupo. Cuando se deniega un permiso para un grupo, la denegación afecta a todos los miembros de ese grupo.
Revise la pertenencia a grupos y los permisos heredados antes de asignar Deny. Para obtener más información, consulte Acerca de los permisos y grupos.
Seguridad del repositorio abierto
Establezca los permisos de repositorio de Git desde Project configuración>Repositorios.
Abra el portal web y seleccione el proyecto donde desea agregar usuarios o grupos. Para seleccionar otro proyecto, consulte Cambiar proyecto, repositorio, equipo.
Seleccione Configuración del proyecto>Repositorios.
Para establecer permisos para cada repositorio de Git del proyecto, seleccione Seguridad de todos los repositorios>.
Para establecer permisos para un repositorio específico, seleccione el repositorio y, a continuación, seleccione Seguridad.
Establezca los permisos de repositorio de Git desde Project configuración>Repositorios.
Abra el portal web y seleccione el proyecto en el que desea administrar los permisos. Para seleccionar otro proyecto, consulte Cambiar proyecto, repositorio, equipo.
Seleccione Configuración del proyecto>Repositorios.
Para establecer permisos para cada repositorio de Git del proyecto, seleccione Repositorios de Git y, a continuación, seleccione el usuario o grupo de seguridad cuyos permisos desea administrar.
Puede hacer clic en la imagen para expandirla y verla completa. Seleccione el
para cerrar.
De lo contrario, seleccione un repositorio específico y, a continuación, seleccione el usuario o grupo de seguridad cuyos permisos desea administrar.
Cambie los permisos y, a continuación, seleccione Guardar cambios.
Confirme que cada permiso modificado conserva su nuevo estado.
Cambiar los permisos de un grupo
Para establecer permisos para un grupo de seguridad personalizado, defina primero el grupo. Para más información, consulte Cambio de permisos de nivel de proyecto.
Seleccione el grupo para establecer permisos. Por ejemplo, seleccione Colaboradores.
Cambie uno o varios permisos. Para conceder un permiso, seleccione Permitir. Para quitar una asignación explícita y usar permisos heredados o de grupo, seleccione No establecido. Seleccione Denegar solo cuando necesite invalidar un permiso aplicable.
Los cambios de permisos se guardan automáticamente. Confirme que cada permiso modificado muestra el estado previsto.
Cambiar los permisos de un usuario
Escriba el nombre del usuario en el filtro de búsqueda y seleccione entre las identidades que parecen establecer permisos para un usuario específico.
Cambie uno o varios permisos para el usuario seleccionado.
Nota
Es posible que no pueda encontrar un usuario desde una página de permisos o un campo de identidad si el usuario no se agregó al proyecto agregandolo a un grupo de seguridad o a un equipo de proyecto. Además, cuando se agrega un usuario a Microsoft Entra ID o Active Directory, puede haber un retraso entre el momento en que se agregan al proyecto y cuándo se pueden buscar desde un campo de identidad. El retraso puede oscilar entre cinco minutos y siete días.
Los cambios de permisos se guardan automáticamente para el usuario seleccionado. Confirme que cada permiso modificado muestra el estado previsto.
Puede agregar un usuario o grupo y no cambiar ningún permiso para ese usuario o grupo. Una vez que se actualice la página de permisos, el usuario o grupo ya no aparece.
Configuración de la herencia para un repositorio
Antes de cambiar la herencia, registre la configuración actual y revise los permisos explícitos y heredados del repositorio. Al desactivar la herencia, los permisos de la entrada de repositorios git de nivel de proyecto ya no fluyen al repositorio. Compruebe que las asignaciones restantes proporcionan el acceso previsto antes de continuar.
Para habilitar o deshabilitar la herencia para un repositorio específico, seleccione el repositorio y, a continuación, establezca Herencia en Activado o Desactivado.
Después de cambiar la herencia, compruebe las asignaciones de permisos del repositorio con un usuario afectado representativo. Si el resultado es incorrecto, restaure la configuración anterior y los estados de permisos. Para obtener información sobre la herencia, consulte Acerca de los permisos y grupos.
Configuración de permisos de omisión de directivas
Hay muchos escenarios en los que ocasionalmente tendrá la necesidad de omitir una política de rama. Algunos ejemplos son cuando se revierte un cambio que provocó una interrupción de compilación o se aplica una corrección urgente en medio de la noche.
Anteriormente, el permiso Exento del cumplimiento de políticas ayudaba a los equipos a administrar a qué usuarios se les concedía la capacidad de omitir las políticas de rama al completar un pull request. Sin embargo, ese permiso también concedía a los usuarios la capacidad de realizar envíos directamente a la rama y eludir por completo el proceso de solicitud de incorporación de cambios (PR).
Los dos permisos siguientes reemplazan a Exento de la aplicación de directivas y proporcionan un control más pormenorizado:
- Omitir directivas al completar solicitudes de extracción: los usuarios con este permiso pueden utilizar la experiencia de anulación para las solicitudes de extracción.
- Omitir directivas al realizar envíos: los usuarios con este permiso pueden enviar directamente a ramas con directivas obligatorias configuradas.
Para permitir que un usuario omita las directivas solo al completar las solicitudes de incorporación de cambios, establezca Directivas de omisión al completar las solicitudes de incorporación de cambios en Permitir. Deje Omitir directivas al insertar como No establecido si el usuario no recibe Permitir a través de otra asignación. Establézcalo en Denegar solo cuando necesite invalidar un permiso aplicable.
Nota
Los usuarios que anteriormente tenían exentos del cumplimiento de directivas establecido en Permitir permiso recibido para ambos permisos de reemplazo. Revise estas asignaciones y establezca Directivas de omisión al insertar en No establecido cuando los usuarios no necesiten insertar directamente en ramas protegidas y ninguna otra asignación conceda el permiso.
Solución de problemas de cambios de permisos
Use las instrucciones siguientes cuando un cambio de permiso no tenga el resultado esperado:
| Issue | Resolution |
|---|---|
| No se puede cambiar un permiso | Compruebe que tiene permisos de administración en la entrada de repositorios git de nivel de proyecto o en el repositorio seleccionado. |
| Un usuario o grupo no aparece en la búsqueda | Agregue la identidad al proyecto a través de un equipo o grupo de seguridad. Los cambios de identidad pueden tardar tiempo en aparecer en la búsqueda. |
| Un permiso no concede acceso | Compruebe las pertenencias a grupos del usuario y ámbitos más específicos para una denegación aplicable. |
| Un permiso afecta a los repositorios incorrectos | Confirme si ha cambiado Todos los repositorios o un repositorio individual. |
| Un permiso devuelve después de seleccionar No establecer. | Compruebe si el permiso se hereda o se concede a través de otro grupo. |
| Deshabilitar la herencia quita el acceso | Restaure la configuración de herencia anterior o asignaciones de permisos explícitas que registró antes del cambio. |
Después de resolver el problema, haga que un usuario afectado representativo compruebe la acción del repositorio prevista.
Sugerencia
Puede usar la inteligencia artificial para ayudar con las tareas de Azure DevOps. Consulte Habilitar la asistencia de IA con Azure DevOps MCP Server para comenzar.