# Forks

Understand how forks enable independent collaboration by creating separate repositories connected to the original, with distinct settings and permissions.

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의 조직에 프라이빗 또는 내부 리포지토리를 포크할 수 있습니다.

일반적으로 공개 리포지토리를 개인 계정이나 리포지토리 생성 권한이 있는 조직으로 포크할 수 있습니다.

Repository, organization, and enterprise policies can limit whether repositories can be forked and where forks can be created. For private and internal repositories, access to forks also depends on repository visibility, organization membership, and administrator settings.

See [조직에 대한 포크 정책 관리](/ko/enterprise-server@3.20/organizations/managing-organization-settings/managing-the-forking-policy-for-your-organization) and [엔터프라이즈에서 리포지토리 관리 정책 적용](/ko/enterprise-server@3.20/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise#enforcing-a-policy-for-forking-private-or-internal-repositories).

## 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. Forks of internal repositories 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 [리포지토리 간 연결 이해](/ko/enterprise-server@3.20/repositories/viewing-activity-and-data-for-your-repository/understanding-connections-between-repositories).

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

> \[!WARNING]
>
> * 프라이빗 리포지토리에 대한 사용자의 액세스를 제거하면 해당 프라이빗 리포지토리의 모든 포크가 삭제됩니다. 프라이빗 리포지토리의 로컬 클론은 유지됩니다. 프라이빗 리포지토리에 대한 팀의 액세스가 취소되거나 개인 리포지토리에 대한 액세스 권한이 있는 팀이 삭제되고 팀 구성원이 다른 팀을 통해 리포지토리에 액세스할 수 없는 경우 리포지토리의 프라이빗 포크가 삭제됩니다.
> *

[LDAP 동기화를 사용](/ko/enterprise-server@3.20/admin/managing-iam/using-ldap-for-enterprise-iam/using-ldap#enabling-ldap-sync)하는 경우 리포지토리에서 사용자를 제거하면 액세스 권한을 잃게 되지만 해당 포크는 삭제되지 않습니다. 사용자가 3개월 이내에 원래 조직 리포지토리에 액세스할 수 있는 팀에 추가되면 다음 동기화에서 포크에 대한 액세스가 자동으로 복원됩니다.

> * 리포지토리에 대한 액세스 권한이 손실된 사용자가 기밀 정보 또는 지적 재산을 삭제하도록 할 책임이 있습니다.
> * 프라이빗 또는 내부 리포지토리에 대한 관리자 권한이 있는 사용자는 해당 리포지토리의 포크를 허용하지 않을 수 있으며 조직 소유자는 조직의 개인 또는 내부 리포지토리를 포크할 수 없습니다. 자세한 내용은 [조직에 대한 포크 정책 관리](/ko/enterprise-server@3.20/organizations/managing-organization-settings/managing-the-forking-policy-for-your-organization) 및 [리포지토리에 대한 포크 정책 관리](/ko/enterprise-server@3.20/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-the-forking-policy-for-your-repository)을(를) 참조하세요.

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.  |
|                                           |                                                                            |
| An internal repository changes visibility | Forks owned by organizations or personal accounts remain private.          |
|                                           |                                                                            |

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.

If a public repository has anonymous Git read access enabled and the repository is made private, all of the repository's forks lose anonymous Git read access and return to the default disabled setting. If a forked repository is made public, repository administrators can re-enable anonymous Git read access. See [리포지토리에 대한 익명 Git 읽기 권한 사용](/ko/enterprise-server@3.20/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/enabling-anonymous-git-read-access-for-a-repository).

## Permissions of forks

프라이빗 포크는 업스트림 리포지토리의 사용 권한 구조를 상속합니다. 이를 통해 프라이빗 리포지토리 소유자가 코드에 대한 제어를 유지할 수 있습니다. 예를 들어 업스트림 리포지토리가 프라이빗 리포지토리이고 팀에 대한 읽기/쓰기 액세스 권한을 제공하는 경우 동일한 팀은 프라이빗 업스트림 리포지토리의 모든 포크에 대한 읽기/쓰기 액세스 권한을 갖습니다. 프라이빗 포크에서는 개별 사용 권한이 아닌 팀 권한만 상속됩니다.

> \[!NOTE]
> 조직에 대한 기본 권한을 변경하면 프라이빗 포크에 대한 사용 권한이 자동으로 업데이트되지 않습니다. 자세한 내용은 [조직에 대한 기본 권한 설정](/ko/enterprise-server@3.20/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/setting-base-permissions-for-an-organization#about-base-permissions-for-an-organization) 항목을 참조하세요.

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](/ko/enterprise-server@3.20/pull-requests/how-tos/work-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork).

### Push rulesets for forked repositories

푸시 규칙은 리포지토리의 전체 포크 네트워크에 적용되어 리포지토리에 대한 모든 진입점이 보호되도록 합니다. 예를 들어 푸시 규칙 집합을 사용하도록 설정된 리포지토리를 포크하는 경우 포크된 리포지토리에도 동일한 푸시 규칙 집합이 적용됩니다.

포크된 리포지토리의 경우 푸시 규칙에 대한 바이패스 권한이 있는 사람은 루트 리포지토리에서 바이패스 권한이 있는 사용자뿐입니다.

See [규칙 세트에 대한 정보](/ko/enterprise-server@3.20/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets#push-rulesets).

### 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.