Sobre permissões para criar forks
Você poderá criar forks de um repositório privado ou interno para sua conta pessoal ou para uma organização em GitHub, no qual você tem permissão para criar repositórios, contanto que as configurações do repositório e as políticas corporativas permitam a criação de forks. Em geral, você pode criar fork em qualquer repositório público para sua conta pessoal ou para uma organização em que tenha permissão para criar repositórios.
Se criar fork de um repositório privado que pertença a um conta pessoal, os colaboradores externos também obterão acesso ao fork. Se você criar fork de um repositório privado ou interno que pertença a uma organização, as equipes da organização obterão acesso ao fork, mas os colaboradores externos não. Você poderá adicionar um colaborador externo a um fork de um repositório privado que pertence a uma organização se você for um proprietário dessa organização ou se sua organização permitir que os administradores do repositório convidem colaboradores externos.
As organizações podem permitir ou impedir a criação de forks de qualquer repositório privado pertencente à organização, e as empresas podem impor políticas para especificar onde os membros podem criar forks de repositórios privados ou internos. As políticas controlam as opções disponíveis para as organizações da empresa.. Para obter mais informações, consulte "Gerenciar a política de bifurcação da sua organização" e "Aplicar as políticas de gerenciamento do repositório na sua empresa".
Sobre a visibilidade dos forks
Um fork é um novo repositório que compartilha configurações de código e de visibilidade com o repositório upstream. Todos os forks de repositórios públicos são públicos. Não é possível alterar a visibilidade de um fork.
Todos os repositórios pertencem a uma rede de repositórios. Uma rede de repositórios contém o repositório upstream, os forks diretos do repositório upstream e todos forks desses forks. Todos os forks da rede de repositórios têm a mesma configuração de visibilidade. Para obter mais informações, consulte "Entender conexões entre repositórios".
Se você excluir um repositório ou alterar as configurações de visibilidade dele, isso afetará os forks do repositório. Para obter mais informações, consulte "O que acontece com as bifurcações quando um repositório é excluído ou muda de visibilidade?"
Se você excluir um fork, todas as contribuições de código desse fork ainda permanecerão acessíveis à rede do repositório.
Sobre as permissões dos forks
As bifurcações privadas herdam a estrutura de permissões do repositório ascendente. Isso ajuda os proprietários de repositórios privados a manter o controle sobre seus códigos. Por exemplo, se o repositório ascendente é privado e fornece acesso de leitura/gravação a uma equipe, essa equipe terá acesso de leitura/gravação para qualquer bifurcação do repositório privado ascendente. Somente as permissões de equipe (não as permissões individuais) são herdadas por forks privados.
Observação: Para obter mais informações, consulte "Definindo permissões base para uma organização".
Os forks públicos não herdam a estrutura de permissões do repositório upstream. Se você bifurcar um repositório público para sua conta pessoa, fazer alterações e abrir uma solicitação de pull para propor suas alterações para o repositório upstream, você pode dar a qualquer pessoa que tenha acesso push ao repositório upstream a permissão para efetuar push de alterações no seu branch de solicitação de pull (incluindo apagar o branch). Isso agiliza a colaboração ao permitir que os mantenedores de repositório façam commits ou executem testes localmente em seu branch de solicitação de pull a partir de uma bifurcação de propriedade do usuário antes de fazer merge. Você não pode dar permissões de push a uma bifurcação de propriedade de uma organização. Para obter mais informações, confira "Permitir alterações em um branch de pull request criado a partir de bifurcação".
Considerações importantes sobre segurança
Se você trabalha com forks ou se é o proprietário de um repositório ou de uma organização que permite a criação de forks, é importante estar ciente das considerações de segurança a seguir.
- Os forks têm permissões próprias, separadas do repositório upstream.
- Os proprietários de um repositório em que foram criados forks têm permissão de leitura sobre todos os forks da rede do repositório.
- Os proprietários da organização de um repositório em que foram criados forks têm permissão de administrador sobre ows forks criados em namespaces de usuário pessoais, incluindo a capacidade de excluir o fork e os respectivos branches dele.
- Os proprietários da organização de um repositório em que foram criados forks têm permissão de leitura sobre os forks criados nas organizações, mas não têm a capacidade de excluir um fork e os respectivos branches dele.
- Forks criados em outra organização não serão excluídos quando o acesso individual for removido do repositório upstream.
- Os commits em qualquer repositório em uma rede podem ser acessados de qualquer repositório na mesma rede, inclusive o repositório upstream, mesmo após o fork ser excluído.
Sobre os forks em uma organização
Os forks da mesma organização copiam os colaboradores e as configurações de equipe dos repositórios upstream deles. Se um repositório pertencer a uma organização:
- Essa organização controla as permissões dos forks dela.
- Todas as equipes da estrutura de permissões upstream que existem e estão visíveis na organização de destino ou no namespace do usuário terão as permissões delas copiadas.
- Permissões de administração permanecem com o proprietário upstream, exceto quando um usuário cria forks em uma organização diferente.
- Se esse repositório for bifurcado para um namespace de usuário, a organização manterá permissões de administrador e todas as equipes com acesso manterão o acesso.