Löschen Sie die Gabelabhängigkeit eines GitHub-Repositorys

206

Wie kann ich GitHub vergessen lassen oder trennen, dass mein Repo ursprünglich eine Abzweigung eines anderen Projekts war?

Ich habe ein Projekt in GitHub gegabelt. Ich kann jetzt sehen, "von was auch immer / was auch immer gegabelt". Das übergeordnete Repository "was auch immer / was auch immer" wird nicht mehr verwaltet. Ich durfte weiterhin die Codebasis des ursprünglichen Repositorys verwenden, um ein unabhängiges Repository zu erstellen.

Gibt es eine Möglichkeit, mein Projekt vom ursprünglichen Repository zu trennen?

github

— Mick
quelle

175

Sie können sich an den Github-Support wenden und ihn bitten, Ihr Repository in den "normalen Modus" zu schalten.

Auf dieser Seite , Abschnitt "Commit wurde in einer Gabelung gemacht", wird erklärt, dass man die Unterstützung durchlaufen muss, um zu wechseln. Daher ist es wahrscheinlich, dass es keine Möglichkeit gibt, dies selbst zu tun (es sei denn, Sie zerstören Ihr zuvor erklärtes Repo und erstellen es neu ... Wenn Sie dies tun, seien Sie vorsichtig, wenn Sie Tickets oder ein Wiki an Ihr Projekt angehängt haben, wie es sein wird gelöscht werden!).

— Thomas Moulard
quelle

30

Ich kann bestätigen, dass die Kontaktaufnahme mit dem Support einwandfrei funktioniert, und sie antworten oft innerhalb weniger Stunden :-)

— BenC

1

Die verlinkte Seite enthält nicht mehr die angegebenen Informationen.

— Kara Brightwell

3

@MattBrennan Die Seite wurde geändert, aber der letzte Abschnitt enthält noch Folgendes: "Um die Gabel zu entfernen und sie in ein eigenständiges Repository auf GitHub.com oder GitHub Enterprise umzuwandeln, wenden Sie sich an den GitHub-Support bzw. Ihren Site-Administrator."

— Thomas Moulard

1

Super schnell .. sie antworteten mir in 1 Stunde. Danke

— myDoggyWritesCode

2

In Github Enterprise finden Sie es jetzt unter admin-> Collaboration-> Network. Abhängig von Ihrem Anwendungsfall sollten Sie 'Make Root', 'Detach' oder 'Extract' verwenden.

— Kutzi

45

Sie können das gegabelte Repository von der Github-Benutzeroberfläche in ein neues Repository (ohne die Gabelabhängigkeit) duplizieren und dann das ursprüngliche gegabelte Repository entfernen:

Melden Sie sich bei Github an
Wählen Sie das + -Zeichen in der oberen rechten Ecke und dann Repository importieren .
Importieren Sie Ihr gegabeltes Repository. Das neue Repository hat keine Fork-Abhängigkeit.
Löschen Sie das ursprüngliche, gegabelte Repository in den Repository-Einstellungen.

— Juuso Ohtonen
quelle

1

Dies war das einfachste und was es für mich funktioniert :). Sehr schlau.

— Moxi

1

Hat jemand anderes ein Problem mit der Importfunktion "hängen"? Meins beschäftigt sich seit ungefähr 5 Stunden mit "Erkennen des Versionskontrollsystems Ihres Projekts ...". Ich bin mir nicht sicher, ob ich in der Warteschlange stehe oder ob es sich tatsächlich um einen Hang handelt. Das Repo ist klein. Ich bin versucht, es über Nacht zu lassen, nur für den Fall, dass ich in einer Schlange stehe.

— Benjamin West

Ich wurde endlich neugierig und klickte einfach auf "Abbrechen". Durch Klicken auf Abbrechen konnte die VCS-Erkennung übersprungen und nur der Code / Commits / Zweige usw. importiert werden. Dies war beim Importieren von Github -> Github der Fall. Der Import könnte nicht hängen geblieben sein, wenn ich von einem anderen VCS gekommen wäre? Nicht sicher. Bitte beachten Sie auch, dass ich dies mit einem zweiten Repo tun musste. Ich musste zweimal abbrechen, damit es funktioniert. Wenn CLI dieselben Daten kopiert, ist dies möglicherweise eine bessere Methode. Wir hoffen jedoch, dass dies anderen hilft, die diese Route gewählt haben.

— Benjamin West

9

Um ganz klar zu sein, dieser Ansatz wird keine Probleme bewahren und Anfragen abrufen.

— Golopot

Funktioniert wie Charme! Danke, du bist ein Lebensretter! :)

— Omnimind

44

Stellen Sie sicher, dass Sie alle wichtigen Zweige und Tags in Ihrem lokalen Repo haben, löschen Sie das Github-Repo, erstellen Sie das Repository mit den üblichen Mitteln neu (ohne Verzweigung) und schieben Sie das lokale Repository mit zurück git push --all. Beachten Sie, dass es sich möglicherweise lohnt, einen temporären sauberen lokalen Klon für den Vorgang zu erstellen, wenn Sie lokale Zweige haben, die Sie nicht veröffentlichen möchten.

Dadurch werden jedoch auch Wiki und Probleme beseitigt. Da das Wiki tatsächlich ein eigenes Repository ist, kann es auf ähnliche Weise behandelt werden, indem es geklont und anschließend neu erstellt und gepusht wird. Die Repo-Adresse befindet sich auf der Git Access-Seite des Wikis ( git@github.com:user/repo.wiki.git).

Dies lässt Probleme. Sie können über die API exportiert werden , aber soweit ich weiß, können Sie nur Probleme und Kommentare mit Ihrer Person erstellen, sodass ein perfekter Import unmöglich ist.

Wenn Sie also Probleme haben möchten, die erhalten bleiben sollen, sollten Sie die Github-Unterstützung in Anspruch nehmen, wie Thomas Moulard vorschlägt.

— Tapio
quelle

Je nachdem, wie viele Probleme es gibt, können diese möglicherweise einzeln in das neue Repository übertragen werden, bevor das alte aus dem Web gelöscht wird ( help.github.com/de/github/managing-your-work-on-). Github /… ). Ich denke, eine entschlossene Person könnte mehr als 100 Ausgaben pro Stunde übertragen - kein Spaß, aber für viele Repositories eine machbare Sache.

— Suma

22

Ich habe das ähnliche Problem und habe diese Github-Hilfeseite verwendet , um es zu lösen. Ich hatte nichts gegen das Wiki und den Issues Tracker, da es für mein Blog ein Thema war, das freundlicherweise von einem anderen Benutzer entwickelt wurde.

So lösen Sie ein gegabeltes Repo und verwenden es nach mehreren Commits als Ihr eigenes, ohne den gesamten Verlauf zu verlieren:

git clone --bare git@github.com:user/forked_repo.git

Erstellen Sie eine neue leere Reposity new-repositoryauf der Github-Website. Und schieben Sie eine gespiegelte Version:

cd user.github.com.git/

git push --mirror git@github.com:user/new-repository.git

Man kann auf github umbenennen, das forked_repositorymit einem anderen Namen, um es als Backup zu behalten und Updates bei Bedarf zu überprüfen. Oder einfach löschen.

Das Umbenennen des new-repositoryin den ursprünglichen Namen erledigt den Job. Als Nebeneffekt werden Ihre Commits jetzt in Ihrem Verlauf angezeigt.

— Aurelien
quelle

11

Dies gilt nur für GitHub Enterprise, nicht für github.com

Angemeldet bei einem Konto mit Administratorrechten:

Wechseln Sie zu dem Repository, das Sie trennen müssen: https://<ghe url>/<org>/<repo>
Klicken Sie oben rechts auf die Rakete "Site Admin"
Klicken Sie in der oberen Menüleiste auf "Zusammenarbeit"
Klicken Sie im linken Bereich auf "Netzwerk"
Klicken Sie im Bereich "Netzwerkstruktur" auf "Root erstellen"
Akzeptieren

Dies wurde auf GitHub Enterprise 2.9 getestet

— Antonio O.
quelle

Abhängig von Ihrem Anwendungsfall ist "Trennen" oder "Extrahieren" möglicherweise besser geeignet. Ich finde 'Make Root' etwas seltsam, da es im Grunde die aktuelle root-> child-Richtung invertiert. (Github Enterprise 2.17)

— Kutzi

10

Mit den Informationen von Aurelien und Clayton konnte ich dies folgendermaßen tun:

$ git clone --bare https://github.com/my/forked_repo.git
<delete forked_repo on GitHub>
<recreate repo on GitHub using same name>
$ cd forked_repo.git
$ git push --mirror

Hier ist die Dokumentation fürgit clone --bare :

Erstellen Sie ein nacktes Git-Repository. Das heißt, anstatt <directory>die Verwaltungsdateien zu erstellen und zu platzieren <directory>/.git, machen Sie das <directory>selbst zum $GIT_DIR. Dies impliziert offensichtlich das -n, da es keinen Ort gibt, an dem der Arbeitsbaum überprüft werden kann. Auch die Verzweigungsköpfe auf der Fernbedienung werden direkt in entsprechende lokale Verzweigungsköpfe kopiert, ohne sie zuzuordnen refs/remotes/origin/. Wenn diese Option verwendet wird, werden weder Fernverfolgungszweige noch die zugehörigen Konfigurationsvariablen erstellt.

Hier ist die Dokumentation fürgit push --mirror :

Anstatt jede ref auf Stoß zu nennen, an , dass alle unter Lit. refs/(das schließt jedoch nicht darauf beschränkt ist refs/heads/, refs/remotes/und refs/tags/) an den entfernten Repository gespiegelt werden. Neu erstellte lokale Refs werden an das Remote-Ende verschoben, lokal aktualisierte Refs werden auf dem Remote-Ende zwangsweise aktualisiert und gelöschte Refs werden vom Remote-Ende entfernt. Dies ist die Standardeinstellung, wenn die Konfigurationsoption festgelegt remote.<remote>.mirrorist.

Hinweis: Wie bei den anderen gitAntworten werden auch hier keine Probleme kopiert, die nicht Teil des gitRepos sind, z. B. das Wiki und Probleme. Per Tapio:

Das Wiki ist ein separates Git-Repo und kann auf ähnliche Weise per Tapio gehandhabt werden. Die Adresse lautet : git@github.com:user/repo.wiki.git.
Probleme können über die GitHub-API exportiert werden, es gibt jedoch Probleme beim Neuerstellen, da sie nur von Ihrem Benutzer erstellt werden können, sodass beim Import Informationen verloren gehen.

— Grokify
quelle