Informationen zu Berechtigungen und Sichtbarkeit von Forks

Die Berechtigungen und die Sichtbarkeit von Forks hängen davon ab, ob das Upstreamrepository öffentlich oder privat ist ob es sich im Besitz einer Organisation befindet, sowie von den Richtlinien deines Unternehmens.

In diesem Artikel

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.com 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, es sei denn, du bist Mitglied eines Unternehmen mit verwalteten Benutzer*innen.

Wenn du ein privates Repository forkst, das zu einem persönliches Konto gehört, erhalten externe Projektmitarbeiterinnen 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 Projektmitarbeiterinnen jedoch nicht. Du kannst dem Fork externe Projektmitarbeiterinnen hinzufügen, aber nur, wenn die externen Projektmitarbeiterinnen auch Zugriff auf das Upstreamrepository haben.

Falls du Mitglied eines Unternehmen mit verwalteten Benutzer*innen bist, gelten weitere Einschränkungen für die Repositorys, die du forken kannst. Verwaltete Benutzerkonten können keine Repositorys von außerhalb des Unternehmens forken. Gemäß der Unternehmensrichtlinie können Verwaltete Benutzerkonten private oder interne Repositorys, die sich im Besitz von Organisationen im Unternehmen befinden, in ihren Benutzerkonto-Namespace oder in andere Organisationen im Besitz des Unternehmens forken. Weitere Informationen findest du unter Informationen zu Enterprise Managed Users.

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 Erzwingen von Repositoryverwaltungsrichtlinien in einem Unternehmen.

Informationen zur Sichtbarkeit von Forks

Ein Fork ist ein neues Repository, das denselben Code und dieselben Sichtbarkeitseinstellungen verwendet wie das Upstreamrepository. Alle Forks öffentlicher Repositorys 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 findest du 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?.

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.

Hinweis: Wenn Sie Basisberechtigungen für eine Organisation ändern, werden Berechtigungen für private Forks nicht automatisch aktualisiert.. Weitere Informationen finden Sie unter „Festlegen von Basisberechtigungen für eine Organisation“.

Öffentliche Forks erben die Berechtigungsstruktur des Upstreamrepositorys nicht. Wenn du ein öffentliches Repository in deinem persönlichen Konto forkst und dann einen Pull Request öffnest, um deine Änderungen am Upstreamrepository vorzuschlagen, kannst du jeder Person mit Pushzugriff auf das Upstreamrepository die Erlaubnis geben, Änderungen an deinen Pull Request-Branch zu pushen (einschließlich Löschung des Branches). Dies beschleunigt die Zusammenarbeit, da Repositoryverwalter*innen die Möglichkeit haben, Commits zu erstellen oder Tests vor dem Zusammenführen lokal für den Pull Request-Branch von einem benutzereigenen Fork aus auszuführen. Du kannst keine Push-Berechtigungen an eine Fork geben, die einer Organisation gehört. Weitere Informationen findest du unter Änderungen an einem Pull-Request-Branch zulassen, der von einem Fork erstellt wurde.

Informationen zu Pushregelsätzen für Fork-Repositorys

Note

Push-Regelsätze befinden sich in der Betaversion. Änderungen sind vorbehalten.

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.

Weitere Informationen findest du unter Informationen zu Regelsätzen.

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 Forknetzwerk 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.
  • Über ein beliebiges Repository im selben Forknetzwerk kannst du auf Commits an einem beliebigen Repository in einem Forknetzwerk zugreifen (einschließlich des Upstreamrepositorys).

Informationen zu Forks innerhalb einer Organisation

Forks innerhalb derselben Organisation kopieren die Projektmitarbeiter*innen und Teameinstellungen ihrer Upstreamrepositorys. Wenn sich ein Repository im Besitz einer Organisation befindet, gilt Folgendes:

  • Diese Organisation steuert 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.