Informationen zu Berechtigungen und Sichtbarkeit von Forks

Informationen zu Berechtigungen zum Erstellen von Forks

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.

• Wenn du ein privates Repository forkst, das zu einem persönliches Konto gehört, erhalten externe Projektmitarbeiter*innen auch Zugriff auf den Fork.
• Wenn du ein privates oder internes Repository forkst, das zu einer Organisation gehört, erhalten Teams innerhalb der Organisation Zugriff auf den Fork, externe Projektmitarbeiter*innen jedoch nicht.
• Du kannst einen externen Projektmitarbeiter zu einem Fork eines privaten Repositorys hinzufügen, das zu einer Organisation gehört, wenn du Eigentümer dieser Organisation bist oder wenn deine Organisation es Repository-Administratoren erlaubt, externe Projektmitarbeiter einzuladen. * Du kannst einen externen Projektmitarbeiter zu einem Fork eines internen Repositorys einer Organisation hinzufügen, wenn der externe Projektmitarbeiter auch Zugriff auf das Upstream-Repository hat.

Organisationen können das Forken von privaten Repositorys im Besitz der Organisation zulassen oder verhindern, und Unternehmen können Richtlinien erzwingen, um anzugeben, wo Mitglieder Forks privater oder interner Repositorys erstellen können. Richtlinien steuern die Optionen, die für die Organisationen des Unternehmens verfügbar sind. Weitere Informationen findest du unter Die Forking-Richtlinie für deine Organisation verwalten und Richtlinien zur Verwaltung von Repositories in Ihrem Unternehmen erzwingen.

Informationen zur Sichtbarkeit von Forks

Ein Fork ist ein neues Repository, das denselben Code und dieselben Sichtbarkeitseinstellungen verwendet wie das Upstreamrepository. Alle Forks von öffentlichen Repositories sind öffentlich. Sie können die Sichtbarkeit eines Forks nicht ändern.

Alle Repositorys gehören zu einem Repositorynetzwerk. Ein Repositorynetzwerk umfasst das Upstreamrepository, die direkten Forks des Upstreamrepositorys und alle Forks dieser Forks. Alle Forks im Repositorynetzwerk weisen die gleiche Sichtbarkeitseinstellung auf. Weitere Informationen finden Sie unter Zusammenhänge zwischen Repositorys verstehen.

Wenn du ein Repository löschst oder dessen Sichtbarkeitseinstellungen änderst, wirkt sich dies auf die Forks des Repositorys aus. Weitere Informationen findest du unter Was geschieht mit Forks, wenn ein Repository gelöscht wird oder sich dessen Sichtbarkeit ändert?.

Wenn Sie einen Fork löschen, sind alle Codebeiträge dieses Forks weiterhin für das Repository-Netzwerk zugänglich.

Informationen zu Berechtigungen von 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.

Öffentliche Forks erben die Berechtigungsstruktur des Upstreamrepositorys nicht.

Wenn Sie ein öffentliches Repository in Ihr persönliches Konto forken, können Sie Repository-Maintainern gestatten, in Ihren Pull-Request-Branch zu pushen. Dies schließt die Berechtigung ein, Commits durchzuführen oder den Zweig zu löschen.

Dies beschleunigt die Zusammenarbeit, indem es den Wartungspersonen ermöglicht, Folgendes zu tun:

• Direkte Commits an Ihrem Zweig vornehmen
• Führe Tests lokal aus, bevor du einen Merge durchführst. Du kannst einem Fork, der einer Organisation gehört, keine Push-Berechtigungen geben.

Weitere Informationen finden Sie unter Änderungen an einem Pull-Request-Branch zulassen, der von einem Fork erstellt wurde.

Wichtige Sicherheitsüberlegungen

Wenn du mit Forks arbeitest oder Besitzer*in eines Repositorys oder einer Organisation bist, das bzw. die das Forken ermöglicht, ist es wichtig, die folgenden Sicherheitsüberlegungen zu berücksichtigen.

• Forks verfügen unabhängig vom Upstreamrepository über eigene Berechtigungen.
• Die Besitzer*innen eines Repositorys, das geforkt wurde, verfügen über Leseberechtigungen für alle Forks im Netzwerk des Repositorys.
• Organisationsbesitzer*innen eines Repositorys, das geforkt wurde, verfügen über Administratorberechtigungen für Forks, die in persönlichen Benutzernamespaces erstellt wurden (einschließlich der Möglichkeit, den Fork und seine Branches zu löschen).
• Organisationsbesitzer*innen eines Repositorys, das geforkt wurde, verfügen zwar über Leseberechtigungen für die in Organisationen erstellten Forks, können den Fork oder seine Branches jedoch nicht löschen.
• Forks, die in einer anderen Organisation erstellt wurden, werden nicht gelöscht, wenn der individuelle Zugriff über das Upstreamrepository entfernt wird.
• Sie können über ein beliebiges Repository im selben Netzwerk auf Commits in einem anderen Repository zugreifen, einschließlich des Upstream-Repositorys, selbst nachdem ein Fork gelöscht wurde.

Informationen zu Forks innerhalb einer Organisation

Forks innerhalb derselben Organisation kopieren die Einstellungen für Mitarbeiter*innen und Teams ihrer Upstream-Repositories. Wenn sich ein Repository im Besitz einer Organisation befindet, gilt Folgendes:

• Diese Organisation kontrolliert die Berechtigungen ihrer Forks.
• Die Berechtigungen aller Teams aus der Upstreamberechtigungsstruktur werden kopiert, die in der Zielorganisation oder dem Benutzernamespace vorhanden und sichtbar sind.
• Die Administratorberechtigungen bleiben bei den Upstreambesitzerinnen, es sei denn, eine Benutzer*in forkt in eine andere Organisation.
• Wenn dieses Repository in einen Benutzernamespace geforkt wird, verfügt die Organisation weiterhin über Administratorberechtigungen, und alle Teams mit Zugriffsberechtigungen haben Zugriff.

Informationen zu Forks innerhalb eines Unternehmens

Interne Repositories unterstützen nur eine einzige Ebene des Forkens; es ist nicht möglich, einen privaten Fork eines internen Repositories zu forken. Dies ist beabsichtigt, um den Zugriff und die Verwaltung für interne Repositorys zu vereinfachen, die unternehmensweiten Zugriff haben. Dies unterscheidet sich vom Verhalten öffentlicher und privater Repositories, die geschachteltes Forking ermöglichen.