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?
퍼블릭 리포지토리는 다음 위치로 포크할 수 있습니다.
- 개인 계정
- 리포지토리 생성 권한이 있는 조직
프라이빗 리포지토리에 액세스할 수 있고, 소유자가 포크를 허용한 경우 해당 리포지토리를 포크할 수 있습니다.
- 개인 계정
- GitHub Team 내에서 리포지토리 생성 권한이 있는 조직
GitHub Free을 사용하여 개인 리포지토리를 조직에 포크할 수 없습니다. GitHub Team 및 GitHub Free에 대한 자세한 내용은 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 관리형 사용자가 있는 엔터프라이즈, additional restrictions apply to the repositories you can fork. See Enterprise Managed Users 정보 in the GitHub Enterprise Cloud documentation.
See 조직에 대한 포크 정책 관리.
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 리포지토리 간 연결 이해.
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
경고
- 프라이빗 리포지토리에 대한 사용자의 액세스를 제거하면 해당 프라이빗 리포지토리의 모든 포크가 삭제됩니다. 프라이빗 리포지토리의 로컬 클론은 유지됩니다. 프라이빗 리포지토리에 대한 팀의 액세스가 취소되거나 개인 리포지토리에 대한 액세스 권한이 있는 팀이 삭제되고 팀 구성원이 다른 팀을 통해 리포지토리에 액세스할 수 없는 경우 리포지토리의 프라이빗 포크가 삭제됩니다.
- 리포지토리에 대한 액세스 권한이 손실된 사용자가 기밀 정보 또는 지적 재산을 삭제하도록 할 책임이 있습니다.
- 프라이빗 리포지토리에 대한 관리자 권한이 있는 사용자는 해당 리포지토리의 포크를 허용하지 않을 수 있으며 조직 소유자는 조직의 개인 리포지토리를 포크할 수 없습니다. 자세한 내용은 조직에 대한 포크 정책 관리 및 리포지토리에 대한 포크 정책 관리을(를) 참조하세요.
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
프라이빗 포크는 업스트림 리포지토리의 사용 권한 구조를 상속합니다. 이를 통해 프라이빗 리포지토리 소유자가 코드에 대한 제어를 유지할 수 있습니다. 예를 들어 업스트림 리포지토리가 프라이빗 리포지토리이고 팀에 대한 읽기/쓰기 액세스 권한을 제공하는 경우 동일한 팀은 프라이빗 업스트림 리포지토리의 모든 포크에 대한 읽기/쓰기 액세스 권한을 갖습니다. 프라이빗 포크에서는 개별 사용 권한이 아닌 팀 권한만 상속됩니다.
참고
조직에 대한 기본 권한을 변경하면 프라이빗 포크에 대한 사용 권한이 자동으로 업데이트되지 않습니다. 자세한 내용은 조직에 대한 기본 권한 설정 항목을 참조하세요.
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
푸시 규칙은 리포지토리의 전체 포크 네트워크에 적용되어 리포지토리에 대한 모든 진입점이 보호되도록 합니다. 예를 들어 푸시 규칙 집합을 사용하도록 설정된 리포지토리를 포크하는 경우 포크된 리포지토리에도 동일한 푸시 규칙 집합이 적용됩니다.
포크된 리포지토리의 경우 푸시 규칙에 대한 바이패스 권한이 있는 사람은 루트 리포지토리에서 바이패스 권한이 있는 사용자뿐입니다.
See 규칙 세트에 대한 정보.
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.
