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

Sie können ein privates oder internes Repository zu Ihrem persönlichen Konto oder einer Organisation auf GitHub forken, wo Sie über Berechtigungen zur Repositoryerstellung verfügen, wenn die Einstellungen für das Repository und Ihre Unternehmensrichtlinien das Forken zulassen.

Im Allgemeinen kannst du jedes öffentliche Repository in dein persönliches Konto oder in eine Organisation forken, in der du die Berechtigung hast, Repositorys zu erstellen.

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 [Die Forking-Richtlinie für deine Organisation verwalten](/de/enterprise-server@3.21/organizations/managing-organization-settings/managing-the-forking-policy-for-your-organization) and [Richtlinien zur Verwaltung von Repositories in Ihrem Unternehmen erzwingen](/de/enterprise-server@3.21/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 [Zusammenhänge zwischen Repositorys verstehen](/de/enterprise-server@3.21/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]
>
> * Wenn du den Zugriff einer Person auf ein privates Repository entfernst, werden all ihre Forks in diesem privaten Repositorys gelöscht. Lokale Klone des privaten Repositorys werden beibehalten. Wenn der Zugriff eines Teams auf ein privates Repository widerrufen wird oder ein Team mit Zugriff auf ein privates Repository gelöscht wird und Teammitglieder keinen Zugriff auf das Repository über ein anderes Team haben, werden private Forks des Repositorys gelöscht.
> * Wenn die [LDAP-Synchronisierung aktiviert ist](/de/enterprise-server@3.21/admin/managing-iam/using-ldap-for-enterprise-iam/using-ldap#enabling-ldap-sync), verliert eine Person, die du aus einem Repository entfernst, ihren Zugriff, aber ihre Forks werden nicht gelöscht. Wenn die Person innerhalb von drei Monaten zu einem Team mit Zugriff auf das ursprüngliche Organisations-Repository hinzugefügt wird, wird ihr Zugriff auf die Forks bei der nächsten Synchronisierung automatisch wiederhergestellt.
> * Du bist dafür verantwortlich, dass die Personen, denen du den Zugriff auf ein Repository entziehst, vertrauliche Informationen oder geistiges Eigentum von ihren Systemen löschen.
> * Personen mit Administratorberechtigungen für ein privates oder internes Repository können das Forken dieses Repositorys verhindern, und Organisationsbesitzer können das Forken eines privaten oder internen Repositorys in einer Organisation verhindern. Weitere Informationen findest du unter [Die Forking-Richtlinie für deine Organisation verwalten](/de/enterprise-server@3.21/organizations/managing-organization-settings/managing-the-forking-policy-for-your-organization) und [Verwalten der Forking-Richtlinie für dein Repository](/de/enterprise-server@3.21/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 [Anonymen Git-Lesezugriff für ein Repository aktivieren](/de/enterprise-server@3.21/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/enabling-anonymous-git-read-access-for-a-repository).

## Permissions of forks

Private Forks erben die Berechtigungsstruktur des Upstreamrepositorys. Dies hilft den Inhabern privater Repositorys, die Kontrolle über ihren Code zu behalten. Wenn das vorgelagerte Repository beispielsweise privat ist und einem Team Lese-/Schreibzugriff gibt, wird dasselbe Team Lese-/Schreibzugriff auf alle Forks des privaten vorgelagerten Repository haben. Nur Teamberechtigungen (nicht einzelne Berechtigungen) werden von privaten Forks geerbt.

> \[!NOTE]
> Wenn Sie Basisberechtigungen für eine Organisation ändern, werden Berechtigungen für private Forks nicht automatisch aktualisiert. Weitere Informationen findest du unter [Festlegen von Basisberechtigungen für eine Organisation](/de/enterprise-server@3.21/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](/de/enterprise-server@3.21/pull-requests/how-tos/work-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork).

### Push rulesets for forked repositories

Pushregeln gelten für das gesamte Forknetzwerk für ein Repository, um sicherzustellen, dass jeder Einstiegspunkt im Repository geschützt ist. Wenn Sie beispielsweise ein Repository verzweigen, das Push-Regelsätze aktiviert hat, gelten dieselben Push-Regelsätze auch für Ihr Fork-Repository.

Bei einem Fork-Repository sind die einzigen Personen, die über Umgehungsberechtigungen für eine Pushregel verfügen, die Personen, die über Umgehungsberechtigungen im Stamm-Repository verfügen.

See [Informationen zu Regelsätzen](/de/enterprise-server@3.21/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.