Os proprietários da organização e os mantenedores de equipe podem dar às equipes acesso de administrador, leitura ou gravação aos repositórios da organização. Os integrantes da organização podem enviar uma notificação a uma equipe inteira mencionando o nome da equipe. Os integrantes da organização também podem enviar uma notificação a uma equipe inteira solicitando uma revisão dessa equipe. Os integrantes da organização podem solicitar revisões de equipes específicas com acesso de leitura ao repositório onde a pull request está aberta. As equipes podem ser designadas como proprietários de determinados tipos de área de código em um arquivo CODEOWNERS.
Para obter mais informações, consulte:
- "Gerenciar o acesso da equipe a um repositório da organização"
- "Mencionar pessoas e equipes"
- "Sobre proprietários do código"
Você também pode usar a sincronização LDAP para sincronizar os integrantes da equipe da sua instância do GitHub Enterprise Server e funções de equipe com os grupos LDAP estabelecidos. Isso permite estabelecer o controle de acesso baseado em função para usuários do servidor LDAP em vez de manualmente na sua instância do GitHub Enterprise Server. Para obter mais informações, consulte "Habilitar a sincronização LDAP".
Visibilidade da equipe
As equipes podem ser visíveis ou secretas:
- Equipes visíveis podem ser viewed and @mentioned (visualizadas e @mencionadas) por todos os membros da organização.
- As equipes secretas são visíveis apenas para as pessoas da equipe e pessoas com permissões de proprietário. Elas são ótimas para esconder equipes com nomes ou membros sensíveis, como os usados para trabalhar com parceiros externos ou clientes. As equipes secretas não podem ser aninhadas sob equipes principais ou ter equipes secundárias.
Páginas da equipe
Cada equipe tem sua própria página em uma organização. Na página de uma equipe, é possível exibir integrantes da equipe, equipes secundárias e os repositórios da equipe. Os proprietários da organização e os mantenedores de equipe podem acessar as configurações da equipe, bem como atualizar a descrição e a foto de perfil da equipe na página da equipe.
Os integrantes da organização podem criar e participar de discussões com a equipe. Para obter mais informações, consulte "Sobre discussões de equipe".
Equipes aninhadas
Você pode refletir seu grupo ou a hierarquia da empresa na sua organização do GitHub Enterprise com vários níveis de equipes aninhadas. Uma equipe principal pode ter várias equipes secundárias, enquanto cada equipe secundária tem apenas uma equipe principal. Não é possível aninhar equipes secretas.
As equipes secundárias herdam as permissões de acesso da principal, simplificando o gerenciamento de permissões para grandes grupos. Os integrantes das equipes secundárias também recebem notificações quando a equipe principal é @mencionada, simplificando a comunicação com vários grupos de pessoas.
Por exemplo, se a estrutura da sua equipe for Funcionários > Engenharia > Engenharia de aplicativos > Identidade, conceder à Engenharia acesso de gravação a um repositório significa que a Engenharia de aplicativos e a Identidade também obterão esse acesso. Se você @mencionar a Equipe Identidade ou qualquer equipe na parte inferior da hierarquia da organização, elas serão as únicas que receberão uma notificação.
Para entender facilmente quem compartilha permissões da equipe principal e faz menção, você pode ver todos os integrantes das equipes secundárias de uma equipe principal na guia Members (Integrantes) da página da equipe principal. Os integrantes de uma equipe secundária não são integrantes diretos da equipe principal.
Você pode escolher uma principal quando criar a equipe ou pode mover uma equipe na hierarquia da organização posteriormente. Para obter mais informações, consulte "Mover uma equipe na hierarquia da sua organização".
Como parte de sua configuração de otimização, LDAP Sync não irá transferir sua estrutura de equipe aninhada. Para criar relacionamentos de equipe filhos e pais, você deve recriar manualmente a estrutura de equipe aninhada e sincronizá-la com o grupo LDAP correspondente. Para obter mais informações, consulte "Creating teams" (Criar equipes)
Preparar para aninhar equipes em sua organização
Se a sua organização já tiver equipes, você deverá auditar as permissões de acesso ao repositório de cada equipe antes de aninhar equipes acima ou abaixo dela. Também é preciso considerar a nova estrutura que deseja implementar para a organização.
No topo da hierarquia da equipe, você deve fornecer às equipes principais permissões de acesso ao repositório que sejam seguras para cada integrante da equipe principal e suas equipes secundárias. À medida que desce pela hierarquia, você pode conceder às equipes secundárias adicionais, acesso mais granular a repositórios mais confidenciais.
- Remova todos os integrantes das equipes existentes
- Audite e ajuste as permissões de acesso ao repositório de cada equipe e forneça a cada equipe uma equipe principal
- Crie qualquer equipe nova que desejar, escolha uma principal para cada equipe nova e forneça a ela acesso ao repositório
- Adicione pessoas diretamente às equipes