Skip to main content

Enterprise Server 3.15 actualmente está disponible como versión candidata para lanzamiento.

Acerca de los equipos

Los equipos son grupos de miembros de la organización que reflejan la estructura de la empresa o del grupo con menciones y permisos de acceso en cascada.

Acerca de los equipos

Puede usar equipos para administrar el acceso de las personas de una organización y para enviar notificaciones. Los propietarios de la organización y los mantenedores del equipo pueden conceder a los equipos acceso de administración, lectura o escritura a los repositorios de la organización. Los miembros de la organización pueden enviar una notificación a todo un equipo mencionando el nombre del equipo. Los equipos solo pueden estar compuestos de miembros de su organización, los colaboradores externos no pueden estar en un equipo.

Los propietarios de la organización y los mantenedores de equipos pueden deshabilitar las notificaciones de equipo. Para más información, consulta "Configurar las notificaciones de equipo".

Los miembros de la organización también pueden enviar una notificación a todo un equipo solicitando una revisión por parte de ese equipo. Los miembros de la organización pueden solicitar revisiones a equipos específicos con acceso de lectura al repositorio en el que se ha abierto la solicitud de incorporación de cambios. Los equipos pueden ser designados como propietarios de ciertos tipos o áreas de código en un archivo CODEOWNERS.

Para más información, consulte:

También puedes usar la sincronización de LDAP para sincronizar los roles y miembros del equipo de tu instancia de GitHub Enterprise Server con los grupos de LDAP establecidos. Esto te permite establecer un control de acceso para usuarios basado en roles desde el servidor LDAP, en lugar de hacerlo de forma manual desde tu instancia de GitHub Enterprise Server. Para obtener más información, vea «Usar LDAP».

Visibilidad del equipo

Los equipos pueden ser visibles o secretos:

  • Todos los miembros de la organización pueden ver y @mentioned los equipos visibles.
  • Solo las personas en el equipo y aquellas con permisos de propietario pueden ver los equipos secretos. Son ideales para ocultar equipos con nombres o miembros sensibles, tales como aquellos que se utilizan para trabajar con socios o clientes externos. Los equipos secretos no pueden anidarse bajo equipos padre ni tener equipos hijo.

Las personas que no son miembros de la organización no pueden ver ningún equipo.

Puedes ver todos los equipos a los cuales perteneces en tu tablero personal. Para obtener más información, vea «Acerca de tu tablero personal».

Paginas del equipo

Cada equipo tiene su propia página dentro de una organización. En la página de un equipo, puedes ver los miembros del equipo, los equipos hijo y los repositorios del equipo. Los propietarios de la organización y los mantenedores del equipo pueden acceder a los parámetros del equipo y actualizar la foto de perfil y la descripción del equipo desde la página del equipo.

Nota: ahora los debates en equipo están . Puede obtener más información sobre esto en el blog de GitHub.

Puede usar GitHub Discussions para crear discusiones de nivel de organización. Para más información sobreGitHub Discussions, consulta "documentación GitHub Discussions."

Equipos anidados

Puedes reflejar la jerarquía de tu grupo o empresa dentro de tu organización de GitHub Enterprise Server con varios niveles de equipos anidados. Un equipo principal puede tener varios equipos secundarios, mientras que cada equipo secundario solo tiene uno principal. Los equipos secretos no se pueden anidar.

Los equipos secundarios heredan los permisos de acceso del equipo principal, lo que simplifica la administración de permisos de grupos grandes. Los miembros de los equipos secundarios también reciben notificaciones cuando se hace una @mentioned al equipo primario, lo que simplifica la comunicación con varios grupos de personas.

Por ejemplo, si la estructura de tu equipo es Empleados > Ingeniería > Ingeniería de aplicación > Identidad, otorgar acceso de escritura a un repositorio a Ingeniería significa que Ingeniería de aplicación e Identidad también reciben ese acceso. Si hace @mention al equipo de Identidad o a cualquier equipo de la parte inferior de la jerarquía de la organización, son los únicos que recibirán una notificación.

Para comprender fácilmente quién comparte las menciones y los permisos de un equipo padre, puedes ver todos los miembros de los equipos hijo de un equipo padre en la pestaña Miembros de la página del equipo padre. Los miembros de un equipo hijo no son miembros directos del equipo padre.

Puedes elegir un padre cuando creas el equipo o puedes mover un equipo más tarde en la jerarquía de tu organización. Para más información, consulta "Mover un equipo en la jerarquía de tu organización".

Como parte de su configuración de optimización, LDAP Sync no transferirá la estructura de equipo anidada. Para crear relaciones entre equipos padre e hijo, deberás recrear manualmente la estructura de equipo anidada y sincronizarla con el grupo de LDAP correspondiente. Para más información, consulta "Crear un equipo"

Prepararse para anidar equipos en tu organización

Si tu organización ya tiene equipos existentes, deberías auditar los permisos de acceso a los repositorios de cada equipo antes de anidar equipos por arriba o por debajo del mismo. También deberías considerar la nueva estructura que te gustaría implementar para tu organización.

En la parte superior de la jerarquía del equipo, deberías otorgar permisos de acceso a los repositorios de los equipos padre que son seguros para cada miembro del equipo padre y sus equipos hijo. A medida que te mueves hacia la parte inferior de la jerarquía, puedes otorgar a los equipos hijo un acceso adicional, más pormenorizado para los repositorios más confidenciales.

  1. Eliminar todos los miembros de los equipos existentes.
  2. Auditar y ajustar los permisos de acceso a los repositorios de cada equipo y darle a cada equipo un padre.
  3. Crear todos los equipos nuevos que quieras, elegir un padre para cada equipo nuevo y otorgarles acceso a los repositorios.
  4. Agregar las personas directamente a los equipos.

Información adicional