Forks are repositories that start as copies of another repository, called the upstream repository. A fork has its own settings and permissions but stays connected to the upstream repository.
When you view a forked repository on GitHub, the upstream repository is indicated below the name of the fork.
What makes forks distinct from branches
A branch is part of one repository. A fork is a separate repository with its own settings and collaboration space.
Each fork can have its own:
- Branches
- Members and discussions
- Issues and pull requests
- Actions and projects
- Tags, labels, and wikis
Which repositories can be forked?
Você pode bifurcar qualquer repositório público:
- Para sua conta pessoal
- Para uma organização em que você tem permissão para criar repositórios
Se você tiver acesso a um repositório privado e o proprietário permitir bifurcação, você poderá bifurcar o repositório:
- Para sua conta pessoal
- Para uma organização no GitHub Team em que você tem permissão para criar repositórios
Não é possível criar forks de um repositório privado em uma organização que usa o GitHub Free. Para obter mais informações sobre GitHub Team e GitHub Free, confira Planos do GitHub.
Repository, organization, and enterprise policies can limit whether repositories can be forked and where forks can be created. For private repositories, access to forks also depends on repository visibility, organization membership, and administrator settings.
If you're a member of an empresa com usuários gerenciados, additional restrictions apply to the repositories you can fork. See Sobre o Enterprise Managed Users in the GitHub Enterprise Cloud documentation.
See Gerenciando a política de bifurcação da sua organização.
Visibility of forks
A fork's visibility is tied to the upstream repository's repository network. Public repository forks are public, and private repository forks are private. You cannot change the visibility of a fork by itself.
All repositories in a repository network share the same visibility setting. A repository network includes the upstream repository, its forks, and forks of those forks. See Entender conexões entre repositórios.
Deleting a repository or changing its visibility can affect the network. If you delete a fork, code contributions from that fork can remain accessible to the repository network.
What happens to forks when a repository is deleted or changes visibility
Aviso
- Se você remover o acesso de uma pessoa a um repositório privado, todas as suas bifurcações desse repositório privado serão excluídas. Os clones locais do repositório privado são mantidos. Se o acesso de uma equipe a um repositório privado for revogado ou uma equipe com acesso a um repositório privado for excluída e os membros da equipe não tiverem acesso ao repositório por meio de outra equipe, as bifurcações privadas do repositório serão excluídas.
- Você é responsável por garantir que as pessoas que perderam o acesso a um repositório excluam qualquer informação confidencial ou de propriedade intelectual.
- Pessoas com permissões de administrador em um repositório privado podem impedir forks desse repositório, e os proprietários da organização podem impedir forks de qualquer repositório privado da organização. Para saber mais, confira Gerenciando a política de bifurcação da sua organização e Gerenciando a política de bifurcação para seu repositório.
Visibility changes can separate forks into new repository networks so that existing fork owners can keep working without unexpected loss of access.
| Action | Effect on forks |
|---|---|
| A private repository is deleted | Its private forks are also deleted. |
| A public repository is deleted | An active public fork becomes the new upstream repository for the network. |
| A public repository is made private | Its public forks stay public in a separate network. |
| A private repository is made public | Private forks stay private but disconnect into separate private networks. |
Changing a public repository to private can also affect stars, watchers, dependency graph, Dependabot alerts, and code scanning availability. Review repository visibility settings carefully before changing them.
Permissions of 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
Quando você altera as permissões base de uma organização, as permissões para bifurcações privadas não são atualizadas automaticamente. Para obter mais informações, confira Definindo permissões base para uma organização.
Public forks do not inherit the permissions structure of the upstream repository. Fork owners control access to their forks, but repository networks still share Git data. Commits pushed to any repository in a network can be accessible from other repositories in that network, including the upstream repository.
When you fork a public repository to your personal account, you can allow maintainers of the upstream repository to push to your pull request branch. This can help maintainers update your branch, run tests, or resolve small issues before merging. You cannot give push permissions to a fork owned by an organization. See Allowing changes to a pull request branch created from a fork.
Push rulesets for forked repositories
As regras de push se aplicam a toda a rede de bifurcação de um repositório, garantindo que cada ponto de entrada do repositório esteja protegido. Por exemplo, se você bifurcar um repositório que tenha conjuntos de regras por push habilitados, os mesmos conjuntos de regras por push também se aplicarão ao repositório bifurcado.
Para um repositório bifurcado, as únicas pessoas que têm permissões de bypass para uma regra de push são as pessoas que têm permissões de bypass no repositório raiz.
See Sobre os conjuntos de regras.
Important security considerations
Forks are powerful collaboration tools, but they can expose code and history in ways that are easy to overlook.
- Forks have their own permissions separate from the upstream repository.
- Owners of an upstream repository can read all forks in the repository network.
- Organization owners may have administrative access to forks created in personal namespaces.
- Removing someone's access to the upstream repository does not always delete forks in other organizations.
- Commits can remain accessible in the repository network even after a fork is deleted.
Before allowing forks for sensitive work, review the permissions and visibility model for your repository or organization.
Forks within an organization
Forks within the same organization copy collaborator and team settings from the upstream repository. The organization controls permissions for these forks, and existing visible teams may keep access.
Forks within an enterprise
Internal repositories support a single level of forking. You cannot fork a private fork of an internal repository. This keeps access and management simpler for repositories that are visible across an enterprise.