Ich habe ein lokales Git-Repository namens „skeleton“, das ich zum Speichern von Projektskeletten verwende. Es hat einige Zweige für verschiedene Arten von Projekten:
casey@agave [~/Projects/skeleton] git branch
* master
rails
c
c++
Wenn ich den Master-Zweig für ein neues Projekt auschecken möchte, kann ich das tun
casey@agave [~/Projects] git clone skeleton new
Initialized empty Git repository in /Users/casey/Projects/new/.git/
und alles ist so wie ich es will. Insbesondere zeigt der neue Master-Branch auf den Skeleton-Master-Branch, und ich kann pushen und pullen, um Änderungen am grundlegenden Projekt-Setup zu verschieben.
Was jedoch nicht funktioniert, ist, wenn ich einen anderen Zweig klonen möchte. Ich bekomme es nicht hin, dass ich nur den Ast ziehe, den ich will, zum Beispiel den rails Verzweigung, und dann hat das neue Repository eine master -Zweig, der zu den Skeleton-Repositorys pusht und daraus zieht rails Zweig, standardmäßig.
Gibt es einen guten Weg, dies zu tun? Oder vielleicht ist das nicht die Art und Weise, wie Git möchte, dass ich Dinge strukturiere, und dafür bin ich auf jeden Fall offen. Vielleicht sollte ich mehrere Repositories haben, wobei das Skelett-Repository von Ruby on Rails das Master-Skelett-Repository verfolgt? Und jedes einzelne Projekt, das das Skelett-Repository von Ruby on Rails klont.
Ich halte das, was du da vorhast, für eine schlechte Idee. Verwenden Sie unterschiedliche Repositorys für unterschiedliche Projekte. Filialen sind etwas ganz anderes.
– innaM
22. November 2009 um 18:45 Uhr
@ Manni, das habe ich mir irgendwie gedacht, da Git anscheinend nicht mochte, was ich tue. Kannst du erklären warum? Liegt es daran, dass Zweige nicht langlebig sein sollten?
– Casey Rodarmor
22. November 2009 um 21:02 Uhr
@rodarmor Ich denke, was du da zu tun versuchst, ist eine gute Idee, und ich hatte genau diese Frage.
– Paul du Bois
8. Juni 2016 um 12:43 Uhr
VonC
Beachten Sie das git1.7.10 (April 2012) erlaubt es dir eigentlich Klonen Sie nur einen Zweig:
# clone only the remote primary HEAD (default: origin/master)
git clone <url> --single-branch
# as in:
git clone <url> --branch <branch> --single-branch [<folder>]
(<url> ist die URL des entfernten Repositorys und verweist nicht auf sich selbst, den geklonten Zweig)
Dies ist bei einem flachen Klon implizit.
Das macht git clone --depth 1 der einfachste Weg, Bandbreite zu sparen.
Und seit Git 1.9.0 (Februar 2014) unterstützen flache Klone die Datenübertragung (Push/Pull), sodass diese Option jetzt noch nützlicher ist.
Siehe mehr unter “Ist git clone --depth 1 (flacher Klon) nützlicher als es den Anschein macht?”.
Das „Rückgängigmachen“ eines flachen Klons wird detailliert unter „Konvertieren eines flachen Klons in einen vollständigen Klon“ (git 1.8.3+) beschrieben.
# unshallow the current branch
git fetch --unshallow
# for getting back all the branches (see Peter Cordes' comment)
git config remote.origin.fetch refs/heads/*:refs/remotes/origin/*
git fetch --unshallow
Wie Chris kommentiert:
die magische Linie, um fehlende Zweige umzukehren --single-branch ist (git v2.1.4):
clone: Übergeben Sie –single-branch während –recurse-submodules
Unterzeichnet von: Emily Shaffer Bestätigt von: Jeff King
Zuvor trat “git clone --recurse-submodules --single-branch” führte dazu, dass Submodule alle Zweige klonten, obwohl das Superprojekt nur einen Zweig klonte.
Rohr --single-branch durch das Submodul-Hilfsframework, um es zu ‘clone‘ später.
Ja, ich denke, es ist Zeit, die akzeptierte Antwort zu aktualisieren 🙂 Das funktioniert “wie ein Zauber”
– Kumarharsch
14. August 2013 um 7:32 Uhr
Dies ist auch implizit bei einem flachen Klon. Das macht clone --depth 1 der einfachste Weg, Bandbreite zu sparen.
– Tobus
7. September 2013 um 19:13 Uhr
@Tobu und VonC --depth 1 ist für den Benutzer unsicher, da er möglicherweise tatsächlich mit dem neuen Klon pushen/ziehen möchte.
– nmr
4. Juni 2014 um 19:48 Uhr
Nur um die Korrektur von Peter Cordes vollständig auszudrücken, die magische Linie, um fehlende Zweige rückgängig zu machen --single-branch ist git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/* und git fetch --unshallow (git v2.1.4)
– Chris
28. Dezember 2016 um 19:15 Uhr
Alex Nolasco
Eine Möglichkeit besteht darin, Folgendes auszuführen.
Woher branch_name ist der Zweig Ihrer Wahl und “/Ihr/Ordner” ist der Zielordner für diesen Zweig. Es ist wahr, dass dies andere Zweige bringen wird, die Ihnen die Möglichkeit geben, hin und her zu fusionieren.
Das funktioniert, aber es holt alle Geäst. Siehe die Antwort von @frerich=raabe unten.
– cdunn2001
17. März 2012 um 20:33 Uhr
Danke. Fügen Sie in meinem Fall nur “-b branch_name” hinzu. Es hat mir viel Zeit gespart.
– PhatHV
27. August 2012 um 2:51 Uhr
Ja, es funktioniert perfekt …! Ich bin eher eine TFS-Person und habe für meine persönlichen Projekte Git verwendet. Wrto git branching, ich habe es früher falsch gemacht und gut, diese einfache Methode zu kennen und sie scheint perfekt zu sein! Danke noch einmal! Habe bereits +1 gegeben, wenn möglich würde ich +100 geben 🙂
– k25
11. März 2013 um 15:38 Uhr
Sie können auch hinzufügen --single-branch um nur den mit diesem Zweig verknüpften Verlauf abzurufen, anstatt den gesamten Verlauf und die Tags, die das Repository enthält.
– fehlerhaft
18. Juni 2014 um 8:11 Uhr
@AlexNolasco Kannst du bitte die Antwort bearbeiten und sagen, was ist /irgendein/Ordner ? Danke
– Nabin
3. September 2016 um 14:04 Uhr
Friedrich Rabe
Mit Git Version 1.7.3.1 (unter Windows) mache ich Folgendes ($BRANCH ist der Name der Filiale, die ich auschecken möchte und $REMOTE_REPO ist die URL des Remote-Repositorys, aus dem ich klonen möchte):
Der Vorteil dieses Ansatzes ist, dass nachträglich git pull (oder git fetch)-Aufrufe laden auch nur den angeforderten Zweig herunter.
Was ist der Unterschied zwischen Ihrem Skript und dieser Zeile? git clone -b $BRANCH $REMOTE_REPO $BRANCH afik sind sie gleich?
– Ian Vaughan
2. August 2011 um 8:54 Uhr
@Ian: Ein Unterschied ist das git clone -b gibt Ihnen alle Remote-Refs (alle Remote-Zweige und -Tags) als git branch -a zeigt an. Mit meinem Skript erhalten Sie nur eine einzige Referenz.
– Frerich Raabe
23. August 2011 um 10:22 Uhr
Wenn ich das obige versuche (z. B. mit $BRANCH=”nick”), erhalte ich “fatal: Konnte Remote-Ref-Refs/Heads/Nick nicht finden”. Scheint bei mir nicht zu funktionieren…
– Nick
11. November 2011 um 16:10 Uhr
Beachten Sie, dass -t $BRANCH geht auch ohne -f, die sofort abgerufen werden würde. Dann, git fetch origin würde holen, und git checkout $BRANCH würde die örtliche Filiale und Kasse einrichten. Das ist nützlich, wenn Sie die Fernbedienung vor dem Abrufen konfigurieren müssen, z git config remote.origin.uploadpack=/bin/upload-pack.
– cdunn2001
23. Februar 2012 um 22:02 Uhr
Da ich mich auf einem “alten” Unternehmens-Git (1.6.0.2) befinde, bin ich an die obige Lösung gebunden. Ich hatte das gleiche Problem wie @Nick. git ausführen branch -a zeigte origin/$BRANCH. Tun git checkout origin/$BRANCH das behoben.
--single-branch ist Ihr Freund während des Klonens, denken Sie daran, mit zu verwenden --branch <branch name> oder nur entfernter primärer HEAD wird geklont (standardmäßig Master)
Denken Sie immer daran, dies zu tun Strg + F5 um frische Quelle zu lesen, nicht die aus dem Cache 🙂 (Ich wusste lange Zeit nichts von dieser Option.)
git clone –branch –single-branch
– Shridutt Kothari
7. Juli 2015 um 12:22 Uhr
9858000cookie-checkWie klone ich einen einzelnen Zweig in Git?yes
Was macht
git branch -a
Show?– Jakub Narębski
22. November 2009 um 10:57 Uhr
Möchten
git checkout -b newbranch origin/branchiwant
funktioniert besser? (ohne das--track
Möglichkeit)– VonC
22. November 2009 um 11:18 Uhr
Ich halte das, was du da vorhast, für eine schlechte Idee. Verwenden Sie unterschiedliche Repositorys für unterschiedliche Projekte. Filialen sind etwas ganz anderes.
– innaM
22. November 2009 um 18:45 Uhr
@ Manni, das habe ich mir irgendwie gedacht, da Git anscheinend nicht mochte, was ich tue. Kannst du erklären warum? Liegt es daran, dass Zweige nicht langlebig sein sollten?
– Casey Rodarmor
22. November 2009 um 21:02 Uhr
@rodarmor Ich denke, was du da zu tun versuchst, ist eine gute Idee, und ich hatte genau diese Frage.
– Paul du Bois
8. Juni 2016 um 12:43 Uhr