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 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.
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?.
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.
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.
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.
- Über ein beliebiges Repository im selben Netzwerk können Sie auf Commits an einem beliebigen Repository in einem Netzwerk zugreifen (einschließlich des Upstreamrepositorys), auch nachdem ein Fork gelöscht wurde.
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.