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?
リポジトリの設定と Enterprise のポリシーでフォークが許可されている場合は、個人用アカウント、またはリポジトリを作成するアクセス許可がある GitHub の organization にプライベートまたは内部リポジトリをフォークできます。
一般に、任意のパブリック リポジトリを、自分の個人アカウント、またはリポジトリを作成するアクセス許可を自分が持っている Organization に、フォークできます。
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 Organization のフォークポリシーを管理する and Enterprise でリポジトリ管理ポリシーを適用する.
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 リポジトリ間の接続を理解する.
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
警告
- プライベートリポジトリへの個人のアクセス権を削除すると、そのプライベートリポジトリからその人が作成したフォークはすべて削除されます。 プライベートリポジトリのローカルクローンは残ります。 プライベート リポジトリへのチームのアクセスが取り消されるか、プライベート リポジトリへのアクセス権を持つチームが削除され、チーム メンバーが別のチームを介してリポジトリにアクセスできない場合、リポジトリのプライベート フォークが削除されます。
LDAP Sync が有効になっていると、ある人がリポジトリから削除された場合、その人はアクセス権を失いますが、その人のフォークは削除されません。 ユーザーが 3 か月以内に元の組織リポジトリにアクセスできるチームに追加された場合、フォークへのアクセスは次の同期時に自動的に復元されます。
- リポジトリへのアクセスを失った個人に、機密情報や知的財産を確実に削除してもらうのは、あなたの責任です。
- プライベート または内部 リポジトリに対する管理者アクセス許可を持つユーザーは、そのリポジトリのフォークを禁止することができ、組織の所有者は、組織内のプライベート または内部 リポジトリのフォークを禁止できます。 詳細については、「Organization のフォークポリシーを管理する」および「リポジトリのフォークポリシーを管理する」を参照してください。
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 読み取りアクセスを有効化する.
Permissions of forks
プライベート フォークは、上流リポジトリのアクセス許可構造を継承します。 これは、プライベートリポジトリのオーナーがコードに対するコントロールを管理するための役に立ちます。 たとえば、上流リポジトリがプライベートで読み取り/書き込みアクセスをあるTeamに与えているなら、そのチームはプライベートの上流リポジトリのすべてのフォークに読み取り/書き込みアクセスを持つことになります。 (個人のアクセス許可ではなく) チームのアクセス許可のみが、プライベート フォークによって継承されます。
メモ
組織の基本アクセス許可を変更しても、プライベート フォークのアクセス許可は自動的に更新されません。詳細については、「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.
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.