Skip to main content

Was geschieht mit Forks, wenn ein Repository gelöscht wird oder sich dessen Sichtbarkeit ändert?

Wenn du dein Repository löschst oder dessen Sichtbarkeit änderst, wirkt sich dies auf die Forks dieses Repositorys aus.

Warnung:

  • 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 die Teammitglieder nicht über ein anderes Team auf das Repository zugreifen können, werden die privaten Forks des Repositorys gelöscht.

  • Wenn die LDAP-Synchronisierung aktiviert ist, 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 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 unterbinden, und Organisationsbesitzer können das Forken jedes privaten oder internen Repositorys in einer Organisation unterbinden. Weitere Informationen findest du unter Die Forking-Richtlinie für deine Organisation verwalten und unter Verwalten der Forking-Richtlinie für dein Repository.

Privates Repository löschen

Wenn du ein privates Repository löschst, werden alle zugehörigen privaten Forks ebenfalls gelöscht.

Öffentliches Repository löschen

Wenn ein öffentliches Repository gelöscht wird, wird der älteste aktive öffentlichen Forks als neues Upstream-Repository ausgewählt. Alle anderen Repositorys werden von diesem neuen Upstream-Repository geforkt und nachfolgende Pull Requests gehen an dieses neue Upstream-Repository.

Private Forks und Berechtigungen

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“.

Öffentliches Repository in ein privates Repository ändern

Wenn ein öffentliches Repository auf privat festgelegt wird, werden die zugehörigen öffentlichen Forks in ein neues Netzwerk abgespalten. Wie beim Löschen eines öffentlichen Repositorys wird einer der vorhandenen öffentlichen Forks als neues Upstream-Repository ausgewählt und alle anderen Repositorys werden von diesem neuen Upstream-Repository geforkt. Nachfolgende Pull Requests werden an dieses neue Upstream-Repository übermittelt.

Anders ausgedrückt: Die Forks eines öffentlichen Repositorys bleiben in ihrem eigenen separaten Repositorynetzwerk öffentlich, auch wenn das Upstream-Repository als privat festgelegt wird. Dadurch können Fork-Inhaber ohne Unterbrechung weiterhin arbeiten und zusammenarbeiten. Wenn öffentliche Forks nicht auf diese Weise in ein separates Netzwerk verschoben wurden, benötigen die Inhaber dieser Forks die entsprechenden Zugriffsberechtigungen, um Änderungen vom (inzwischen privaten) Upstream-Repository abzurufen – auch wenn sie diese Berechtigungen zuvor nicht benötigt wurden.

Wenn für ein öffentliches Repository der anonyme Git-Lesezugriff aktiviert ist und das Repository auf privat festgelegt wird, verlieren alle Forks des Repositorys den anonymen Git-Lesezugriff und verwenden wieder die standardmäßig deaktivierte Einstellung. Wenn ein geforktes Repository als öffentlich festgelegt wird, kann der anonyme Git-Lesezugriff durch die Repository-Administratoren wieder aktiviert werden. Weitere Informationen findest du unter Anonymen Git-Lesezugriff für ein Repository aktivieren.

Privates Repository löschen

Wenn ein öffentliches Repository auf privat festgelegt und anschließend gelöscht wird, bleiben die zugehörigen öffentlichen Forks in einem separaten Netzwerk erhalten.

Privates Repository in ein öffentliches Repository ändern

Wenn ein privates Repository öffentlich gemacht wird, werden alle Commits in diesem Repository, einschließlich aller Commits, die zuvor an private Forks dieses Repositorys übertragen wurden, zu einem neuen öffentlichen Repository-Netzwerk migriert und für alle sichtbar. Alle zuvor erstellten privaten Forks bleiben privat, werden jedoch vom ursprünglichen Repository getrennt, das öffentlich gemacht wurde. Jeder private Fork wird zu einem separaten privaten Repository, und es wird ein eigenes unabhängiges Repositorynetzwerk erstellt. Auf neue Änderungen, die an diesen Netzwerken vorgenommen werden, kann nicht über das ursprüngliche Repository zugegriffen werden, das öffentlich gemacht wurde.

Öffentliches Repository löschen

Wenn ein privates Repository auf öffentlich festgelegt und anschließend gelöscht wird, bleiben die zugehörigen privaten Forks in separaten Netzwerken als eigenständige private Repositorys erhalten.

Ändern der Sichtbarkeit eines internen Repositorys

Wenn die Richtlinie deines Unternehmens Forking erlaubt, sind alle Forks von internen Repositorys privat. Wenn du die Sichtbarkeit eines internen Repositorys änderst, bleibt jeder Fork, der von einer Organisation oder einem persönlichen Konto gehört, privat bleiben.

Löschen des internen Repositorys

Wenn du die Sichtbarkeit eines internen Repositorys änderst und dann das Repository löschst, wird die Forks weiterhin in einem separaten Netzwerk vorhanden sein.

Weiterführende Themen