Sobre equipes
Você pode usar as equipes para gerenciar o acesso de pessoas em uma organização e enviar notificações. Os proprietários da organização e os mantenedores da equipe podem conceder às equipes acesso de administrador, de leitura ou de gravação aos repositórios da organização. Os membros da organização podem enviar uma notificação para uma equipe inteira mencionando o nome da equipe. As equipes só podem ser compostas por membros da sua organização. Colaboradores externos não podem estar em uma equipe.
Os proprietários da organização e os mantenedores da equipe podem desabilitar as notificações da equipe. Para obter mais informações, confira "Configurando notificações da equipe".
Os membros da organização também podem enviar uma notificação para uma equipe inteira solicitando uma análise dessa equipe. Os membros da organização podem solicitar análises de equipes específicas com acesso de leitura ao repositório no qual a solicitação de pull foi 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 em um repositório da organização"
- "Sintaxe básica de gravação e formatação no GitHub"
- "Sobre os proprietários de código"
Use também a Sincronização LDAP para sincronizar membros da equipe e funções de equipe do sua instância do GitHub Enterprise Server com os grupos LDAP estabelecidos. Isso permite que você estabeleça o controle de acesso baseado em função para usuários do servidor LDAP em vez de manualmente no sua instância do GitHub Enterprise Server. Para obter mais informações, confira "Usando o LDAP".
Visibilidade da equipe
As equipes podem ser visíveis ou secretas:
- As equipes visíveis podem ser vistas e @mentioned 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.
Pessoas que não são membros da organização não podem exibir nenhuma equipe.
Você pode ver todas as equipes às quais você pertence no seu painel pessoal. Para obter mais informações, confira "Sobre seu painel pessoal".
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.
Observação: as Discussões em Equipe foram preteridas e esse ponto de extremidade da API REST será removido no GitHub Enterprise Server 3.12. Você pode ler mais sobre essa substituição no Blog do GitHub.
Você pode usar GitHub Discussions para criar discussões no nível da organização. Para mais informações sobreGitHub Discussions, confira "Documentação do GitHub Discussions".
Equipes aninhadas
Você pode refletir seu grupo ou a hierarquia da empresa na sua organização do GitHub Enterprise Server com vários níveis de equipes aninhadas. Uma equipe pai pode ter várias equipes filhas, enquanto cada equipe filha tem apenas uma equipe pai. Você não pode aninhar equipes secretas.
As equipes filhas herdam as permissões de acesso do pai, simplificando o gerenciamento de permissões para grandes grupos. Os membros das equipes filho também recebem notificações quando a equipe pai é @mentioned, 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 aplicativo e a Identidade também obterão esse acesso. Se você @mention a Equipe de 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, confira "Mover uma equipe na hierarquia da organização".
Como parte da configuração de otimização, a Sincronização LDAP não vai 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, confira "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