Wie man Git Repository aus seiner zip klonen kann

Wenn Sie das Repository heruntergeladen haben (einschließlich des .git-Verzeichnisses), ist das ganz einfach.

• entpacken Sie das Repository

  $ unzip repo.Zip
  

• konfigurieren Sie eine remote in Ihrem Repository, die auf den Klon-URI verweist

  $ cd repo
  $ git init
  $ git remote add Origin https://github.com/user/repo.git
  

• synchronisieren Sie die Repositorys erneut

  $ git pull
  

In der Praxis scheint es, dass der "Zip" -Download von github nicht das .git-Verzeichnis enthält, so dass dies nicht hilft :-(

Die beste Wette, die Sie haben, ist wahrscheinlich, einen Klon auf einem Computer zu erstellen, der über einen stabilen Zugriff verfügt, und dann das .git-Verzeichnis zu komprimieren und das Verzeichnis irgendwie abzurufen ....

Während die akzeptierte Antwort den Trick tut, scheint dies etwas geradliniger.

unzip <repo>.Zip
cd <repo>
git init
git add .
git remote add Origin https://github.com/<user>/<repo>.git
git remote update
git checkout master

Stellen Sie sicher, dass Sie <user> & <repo> durch Ihren github-Benutzernamen und Ihren Repo-Namen ersetzen.

Die einzige Zip-ähnliche Alternative zum Klonen ist das Austauschen von "Bundles" , aber ich befürchte, dass github keine Erstellung/Download von Bundles anbietet.

Ein von github herunterladbares Zip-Archiv ist nur eine Momentaufnahme eines bestimmten Commits Ihres Repository-Verlaufs (normalerweise die Spitze eines Zweigs), und es enthält keinen Verlauf. Diese Funktion soll die Benutzer Ihrer Codebasis automatisch bereitstellen ( Nicht Entwickler!) mit einer Möglichkeit, eine Momentaufnahme des Quellcodes des Projekts bequem herunterzuladen. Beachten Sie, dass bloße Benutzer und beispielsweise nachgelagerte Betreuer, die Ihre Software für Betriebssysteme verpacken, normalerweise keine kompletten Historien klonen, sondern eher mit Tarballs arbeiten.

Mit anderen Worten: Das Herunterladen eines Zip-Archivs funktioniert wie das Ausführen von git archive auf der Remote-Seite und das Weitergeben der resultierenden Datei.

Beachten Sie auch, dass auf github (und anderen Git-Hosting-Providern) gehostete Repositorys "bloß" sind, dh das Unterverzeichnis ".git" nicht enthalten.

In jedem Fall scheint Ihre einzige Möglichkeit, dieses Problem zu lösen, die Suche nach einem schnellen und zuverlässigen Link und dem ersten Download.

Beachten Sie jedoch, dass Dinge sich ändern, wenn Sie damit einverstanden sind, nicht die vollständige Historie zu haben. Sie können dann das sogenannte "shallow cloning" verwenden, indem Sie den Befehlszeilenparameter "--depth" an git clone übergeben.

Je nach Anwendungsfall ist die Initialisierung möglicherweise nicht der richtige Weg. Es ist besonders langwierig, wenn es ein sehr großes Repository gibt (meine waren 16 GB und Ineeded, um dies zu tun), und in der Tat wird lokaler refs+objects weggeblasen, was nicht gut ist, wenn Ihr Archiv ein Archiv darstellt, für das keine Fernbedienung mehr existiert.

Das Repository muss in zwei Schritten kopiert werden:

1. "Datendateien" (HEAD-Revision möglicherweise nicht gespeichert)
2. Indizes und Objekte dh. history + refs + objects: Hier werden Ihre Basislinien, Deltas, Zweigzeiger und Tags aufgezeichnet.

Ziel ist es, zu reduzieren, wie viele Objekte von einer entfernten Station geklont werden müssen oder welche nicht von einer nicht mehr existierenden entfernten Umgebung erstellt werden können . Darüber hinaus möchten Sie, dass Ihre Konfiguration keinen Konflikt mit den lokalen Konfigurationsdateien desjenigen verursacht, der das Repository ursprünglich erstellt hat  

Sie möchten das Repository-Layout für Objekte und Referenzen beibehalten, die in der Remote-Umgebung nicht mehr vorhanden sind oder die Sie nicht kopieren möchten (z. B. große Bildressourcen). Aus diesem Grund möchten Sie nicht initiieren und ziehen, besonders wenn Sie keine Fernbedienung mehr haben.

Stattdessen befindet sich das Repository bereits in einem akzeptablen Zustand mit intakten Referenzen und Objekten. Das einzige Problem kann sein, wenn die Fernbedienungen nicht mehr richtig eingerichtet sind und Ihre Konfiguration möglicherweise nicht richtig eingestellt ist.

Führen Sie git config --local -l aus, um sicherzustellen, dass die Festschreibungsidentität nicht lokal im Repository festgelegt ist, und ändern Sie alle Schlüssel, die Ihre globalen Einstellungen auf eine Weise überschreiben, die Sie nicht möchten.

Nun, da es so konfiguriert ist, dass das Repository jetzt wie Ihr eigenes behandelt wird (weil es so ist), ist git so konzipiert, dass es verteilt funktioniert. Sobald Sie eine lokale Konfiguration geändert haben, ist es praktisch nicht anders, als wäre es geklont worden. Jetzt müssen Sie nur noch sicherstellen, dass Ihre Fernbedienungen richtig eingestellt sind.

Wenn Sie kein Remote haben, aber einen erstellen möchten, erstellen Sie ihn mit git init --bare auf dem Remote-Server. Fügen Sie dann wie gewohnt einen Remote hinzu und drücken Sie alle Refs git Push --all. Wenn ein Repository leer gemacht wird, bedeutet dies, dass es den ersten Push akzeptiert, ohne sich über eine unterschiedliche Geschichte zu beklagen.

Wenn Sie über ein Remote-Repository verfügen, fügen Sie es als Remote hinzu und ziehen Sie es ab. Die Archivzweige verweisen möglicherweise auf die falsche URL, je nachdem, wie lange das Archiv erstellt wurde. Wenn dies der Fall ist, verwenden Sie git remote, um sie neuen Standorten zuzuweisen, oder tote URLs entfernen.

Sobald die Fernbedienungen eingerichtet wurden, rufen Sie mit und holen Sie, um auf den neuesten Stand zu kommen. Wenn es einen getrennten KOPF gibt, checken Sie den gewünschten Zweig aus. Wenn der Verlauf des archivierten Repositorys vom Remote abweicht, führt git zu einem Zusammenführungskonflikt. Er wird wie üblich aufgelöst, und Änderungen werden ggf. gespeichert.