-
1. Erste Schritte
-
2. Git Grundlagen
-
3. Git Branching
- 3.1 Branches auf einen Blick
- 3.2 Einfaches Branching und Merging
- 3.3 Branch-Management
- 3.4 Branching-Workflows
- 3.5 Remote-Branches
- 3.6 Rebasing
- 3.7 Zusammenfassung
-
4. Git auf dem Server
- 4.1 Die Protokolle
- 4.2 Git auf einem Server einrichten
- 4.3 Erstellung eines SSH-Public-Keys
- 4.4 Einrichten des Servers
- 4.5 Git-Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Von Drittanbietern gehostete Optionen
- 4.10 Zusammenfassung
-
5. Verteiltes Git
-
6. GitHub
-
7. Git Tools
- 7.1 Revisions-Auswahl
- 7.2 Interaktives Stagen
- 7.3 Stashen und Bereinigen
- 7.4 Deine Arbeit signieren
- 7.5 Suchen
- 7.6 Den Verlauf umschreiben
- 7.7 Reset entzaubert
- 7.8 Fortgeschrittenes Merging
- 7.9 Rerere
- 7.10 Debuggen mit Git
- 7.11 Submodule
- 7.12 Bundling
- 7.13 Replace (Ersetzen)
- 7.14 Anmeldeinformationen speichern
- 7.15 Zusammenfassung
-
8. Git einrichten
- 8.1 Git Konfiguration
- 8.2 Git-Attribute
- 8.3 Git Hooks
- 8.4 Beispiel für Git-forcierte Regeln
- 8.5 Zusammenfassung
-
9. Git und andere VCS-Systeme
- 9.1 Git als Client
- 9.2 Migration zu Git
- 9.3 Zusammenfassung
-
10. Git Interna
-
A1. Anhang A: Git in anderen Umgebungen
- A1.1 Grafische Schnittstellen
- A1.2 Git in Visual Studio
- A1.3 Git in Visual Studio Code
- A1.4 Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git in Sublime Text
- A1.6 Git in Bash
- A1.7 Git in Zsh
- A1.8 Git in PowerShell
- A1.9 Zusammenfassung
-
A2. Anhang B: Git in Ihre Anwendungen einbetten
- A2.1 Die Git-Kommandozeile
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Anhang C: Git Kommandos
- A3.1 Setup und Konfiguration
- A3.2 Projekte importieren und erstellen
- A3.3 Einfache Snapshot-Funktionen
- A3.4 Branching und Merging
- A3.5 Projekte gemeinsam nutzen und aktualisieren
- A3.6 Kontrollieren und Vergleichen
- A3.7 Debugging
- A3.8 Patchen bzw. Fehlerkorrektur
- A3.9 E-mails
- A3.10 Externe Systeme
- A3.11 Administration
- A3.12 Basisbefehle
3.5 Git Branching - Remote-Branches
Remote-Branches
Remote-Referenzen sind Referenzen (Zeiger) in deinem Remote-Repositorys, einschließlich Branches, Tags usw.
Du kannst eine vollständige, ausführliche Liste von Remote-Referenzen bekommen, wenn du die Anweisungen git ls-remote <remote>
oder git remote show <remote>
für Remote-Branches ausführst, sowie auch für weitere Informationen.
Der gängigerer Ansatz ist jedoch die Nutzung von Remote-Tracking-Branches.
Remote-Tracking-Branches sind Referenzen auf den Zustand von Remote-Branches. Sie sind lokale Referenzen, die du nicht manuell ändern kannst. Sie werden automatisch für dich geändert, sobald du irgendeine Netzwerkkommunikation durchführst. Betrachte sie als Lesezeichen, die daran erinnern, wo die Branches in deinem Remote-Repositorys das letzte Mal standen, als du dich mit ihnen verbunden hast.
Remote-Tracking-Branch-Namen haben die Form <remote>/<branch>
.
Wenn du beispielsweise wissen möchtest, wie der Branch master
in deinem Repository origin
ausgesehen hat, als du zuletzt Kontakt mit ihm hattest, dann würdest du den Branch origin/master
überprüfen.
Wenn du mit einem Mitstreiter an einem Problem gearbeitet hast und dieser bereits einen iss53
Branch hochgeladen (gepusht) hat, besitzt du möglicherweise deinen eigenen lokalen iss53
Branch. Der Branch auf dem Server würde jedoch vom Remote-Tracking-Branch origin/iss53
dargestellt werden.
Das kann ein wenig verwirrend sein, lass uns also ein Beispiel betrachten.
Angenommen, du hast in deinem Netzwerk einen Git-Server mit der Adresse git.ourcompany.com
.
Wenn du von diesem klonst, erhält der Server von der Git-Anweisung clone
automatisch den Namen origin
, lädt all seine Daten herunter, erstellt einen Zeiger auf dem master
Branch zeigt und benennt ihn lokal origin/master
.
Git gibt dir auch deinen eigenen lokalen master
Branch mit der gleichen Ausgangsposition wie der origin/master
Branch, damit du einen Punkt hast, wo du mit deiner Arbeit beginnen kannst.
Anmerkung
|
„origin“ ist nichts Besonderes
Genau wie der Branch-Name „master“ in Git keine besondere Bedeutung hat, hat auch „origin“ keine besondere Bedeutung.
Während „master“ die Standardbezeichnung für den Anfangsbranch ist, wenn du die Anweisung |
Wenn du ein wenig an deinem lokalen master
Branch arbeitest und in der Zwischenzeit jemand anderes etwas zu git.ourcompany.com
hochlädt und damit dessen master
Branch aktualisiert, dann bewegen sich eure Verläufe unterschiedlich vorwärts.
Solange du keinen Kontakt mit deinem origin
Server aufnimmst, bewegt sich dein origin/master
Zeiger nicht.
Um deine Arbeit mit einem bestimmten Remote zu synchronisieren, führst du den Befehl git fetch <remote>
aus (in unserem Fall git fetch origin
).
Der Befehl sucht, welcher Server „origin“ ist (in diesem Fall git.ourcompany.com
), holt alle Daten, die du noch nicht hast, und aktualisierst deine lokale Datenbank, indem er deinen origin/master
Zeiger auf seine neue, aktuellere Position bewegt.
git fetch
aktualisiert deine Remote-Tracking-BranchesUm den Umgang mit mehreren Remote-Servern zu veranschaulichen und um zu sehen, wie Remote-Branches bei diesen Remote-Projekten aussehen, nehmen wir an, dass du einen weiteren internen Git-Server hast, welcher von einem deiner Sprint-Teams nur zur Entwicklung genutzt wird.
Diesen Server erreichen wir unter git.team1.ourcompany.com
.
Du kannst ihn zu dem Projekt, an dem du gegenwärtig arbeitest, als neuen Remote-Server hinzufügen, indem du die Anweisung git remote add
ausführst, wie wir bereits in Kapitel 2 Git Grundlagen behandelt haben.
Wir nennen diesen Remote-Server teamone
, was die Kurzbezeichnung für die gesamte URL sein wird.
Jetzt kannst du mit der Anweisung git fetch teamone
alles vom Server holen, was du noch nicht hast.
Da auf diesem Server nur eine Teilmenge der Daten ist, die sich genau jetzt auf deinem origin
Server befinden, holt Git keine Daten ab, aber es erstellt einen Remote-Branch teamone/master
so, dass er auf den Commit zeigt, den teamone
als seinen master
Branch hat.
teamone/master
Pushing/Hochladen
Wenn du einen Branch mit der Welt teilen möchtest, musst du ihn auf einen Remote-Server hochladen, auf dem du Schreibrechte besitzt. Deine lokalen Branches, auf die du schreibst, werden nicht automatisch mit den Remotes synchronisiert – Du musst die Branches, die du freigeben möchtest, explizit pushen. Auf diese Weise kannst du private Branches, die du nicht veröffentlichen willst, zum Arbeiten benutzen und nur die Feature-Branches pushen, an denen du mitarbeiten willst.
Wenn du einen Branch namens serverfix
besitzt, an dem du mit anderen arbeiten möchtest, dann kannst du diesen auf dieselbe Weise Hochladen wie deinen ersten Branch.
Führe die Anweisung git push <remote> <branch>
aus:
$ git push origin serverfix
Counting objects: 24, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done.
Total 24 (delta 2), reused 0 (delta 0)
To https://github.com/schacon/simplegit
* [new branch] serverfix -> serverfix
Das ist eine Art Abkürzung.
Git erweitert den Branch-Namen serverfix
automatisch zu refs/heads/serverfix:refs/heads/serverfix
, was soviel bedeutet wie „Nimm meinen lokalen Branch serverfix
und aktualisiere damit den serverfix
Branch auf meinem Remote-Server“.
Wir werden den Teil refs/heads/
in Kapitel 10 Git Interna noch näher beleuchten, du kannst ihn aber in der Regel auslassen.
Du kannst auch die Anweisung git push origin serverfix:serverfix
ausführen, was das Gleiche bewirkt – es bedeutet „Nimm meinen serverfix
und mach ihn zum serverfix
des Remote-Servers“.
Du kannst dieses Format auch benutzen, um einen lokalen Branch in einen Remote-Branch mit anderem Namen zu pushen.
Wenn du nicht willst, dass er auf dem Remote als serverfix
bezeichnet wird, kannst du stattdessen git push origin serverfix:awesomebranch
ausführen, um deinen lokalen serverfix
Branch auf den awesomebranch
Branch im Remote-Projekt zu pushen.
Anmerkung
|
Geb dein Passwort nicht jedes Mal neu ein
Wenn du eine HTTPS-URL zum Übertragen verwendest, fragt der Git-Server nach deinem Benutzernamen und Passwort zur Authentifizierung. Standardmäßig wirst du auf dem Terminal nach diesen Informationen gefragt, damit der Server erkennen kann, ob du pushen darfst. Wenn du es nicht jedes Mal eingeben willst, wenn du etwas hochlädst, dann kannst du einen „credential cache“ einstellen.
Am einfachsten ist es, die Informationen nur für einige Minuten im Speicher zu behalten, was du einfach mit der Anweisung Weitere Informationen zu den verschiedenen verfügbaren „credential cache“ Optionen findest du in Kapitel 7 Caching von Anmeldeinformationen. |
Das nächste Mal, wenn einer deiner Mitstreiter Daten vom Server abholt, wird er eine Referenz auf die Server-Version des Branches serverfix
unter dem Remote-Branch origin/serverfix
erhalten:
$ git fetch origin
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://github.com/schacon/simplegit
* [new branch] serverfix -> origin/serverfix
Es ist wichtig zu beachten, dass du bei einem Abruf, der neue Remote-Tracking-Branches abruft, nicht automatisch über lokale, bearbeitbare Kopien davon verfügst.
Mit anderen Worten, in diesem Fall hast du keinen neuen Branch serverfix
– Du hast nur einen Zeiger origin/serverfix
, den du nicht ändern kannst.
Um diese Änderungen in deinem gegenwärtigen Arbeitsbranch einfließen zu lassen, kannst du die Anweisung git merge origin/serverfix
ausführen.
Wenn du deinen eigenen serverfix
Branch haben willst, an dem du arbeiten kannst, kannst du ihn von deinem Remote-Tracking-Branch ableiten (engl. base):
$ git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'
Das erstellt dir einen lokalen Branch, an dem du arbeiten kannst, und der dort beginnt, wo origin/serverfix
derzeit steht.
Tracking-Branches
Das Auschecken eines lokalen Branches von einem Remote-Branch erzeugt automatisch einen sogenannten „Tracking-Branch“ (oder manchmal einen „Upstream-Branch“).
Tracking-Branches sind lokale Branches, die eine direkte Beziehung zu einem Remote-Branch haben.
Wenn du dich auf einem Tracking-Branch befindest und git pull
eingibst, weiß Git automatisch, von welchem Server Daten abzuholen sind und in welchen Branch diese einfließen sollen.
Wenn du ein Repository klonst, wird automatisch ein master
Branch erzeugt, welcher origin/master
trackt.
Du kannst jedoch auch andere Tracking-Branches erzeugen, wenn du wünschst – welche die Branches auf anderen Remotes folgen.
Der einfachste Fall ist das Beispiel, dass du gerade gesehen hast, die Ausführung der Anweisung git checkout -b <branch> <remotename>/<branch>
.
Das ist eine übliche Operation, für die Git die Kurzform --track
bereitstellt:
$ git checkout --track origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'
In der Tat ist dies so weit verbreitet, dass es sogar eine Abkürzung für diese Abkürzung gibt. Wenn der Branch-Name, den du zum Auschecken verwenden möchtest (a), nicht existiert und (b) genau mit einem Namen auf nur einem Remote übereinstimmt, erstellt Git einen Tracking-Branch für dich:
$ git checkout serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'
Um einen lokalen Branch mit einem anderen Namen als den entfernten Branch einzurichten, kannst du die erste Version mit einem anderen lokalen Branch-Namen verwenden:
$ git checkout -b sf origin/serverfix
Branch sf set up to track remote branch serverfix from origin.
Switched to a new branch 'sf'
Nun wird dein lokaler Branch sf
automatisch von origin/serverfix
pullen.
Wenn du bereits über einen lokalen Branch verfügst und ihn auf einen Remote-Branch festlegen möchtest, den du gerade gepullt hast, oder auf den von dir gefolgten Upstream-Branch ändern möchtest, kannst du die Option -u
oder --set-upstream-to
für git branch
verwenden, um es jederzeit festzulegen.
$ git branch -u origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Anmerkung
|
Upstream-Kürzel
Wenn du einen Tracking-Branch eingerichtet hast, kannst du auf seinen Upstream-Branch mit der Kurzform |
Wenn du die Tracking-Branches sehen willst, die du eingerichtet hast, kannst du die Anweisung git branch
zusammen mit der Option -vv
ausführen.
Das listet deine lokalen Branches zusammen mit weiteren Informationen auf, einschließlich was jeder Branch trackt und ob dein lokaler Branch voraus oder zurück liegt, oder auch beides.
$ git branch -vv
iss53 7e424c3 [origin/iss53: ahead 2] Add forgotten brackets
master 1ae2a45 [origin/master] Deploy index fix
* serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] This should do it
testing 5ea463a Try something new
Hier können wir also sehen, dass unser iss53
Branch den Branch origin/iss53
folgt und die Information „ahead 2“ bedeutet, dass wir zwei lokale Commits haben, welche noch nicht auf den Server hochgeladen wurden.
Wir können außerdem sehen, dass unser master
Branch origin/master
folgt und auf den neuesten Stand ist.
Als nächstes sehen wir, dass unser serverfix
Branch den Branch server-fix-good
auf unserem Server teamone
folgt. „ahead 3, behind 1“ bedeutet, dass es einen Commit auf dem Server gibt, den wir noch nicht gemerged haben, und drei lokale Commits existieren, die wir noch nicht gepusht haben.
Zum Schluss können wir sehen, dass unser testing
Branch gar keinen Remote-Branch folgt.
Es ist wichtig zu beachten, dass diese Zahlen den Zustand zu dem Zeitpunkt beschreiben, als du zum letzten Mal Daten vom Server abgeholt hast. Diese Anweisung greift nicht auf die Server zu, sie liefert nur die Informationen, welche beim letzten Server-Kontakt lokal zwischengespeichert wurden. Wenn du gänzlich aktuelle Zahlen von „ahead“ und „behind“ willst, dann musst du, kurz bevor du die Anweisung ausführst, von all deinen Remote-Servern Daten abholen (fetch). Du kannst das so machen:
$ git fetch --all; git branch -vv
Pulling/Herunterladen
Die Anweisung git fetch
holt alle Änderungen auf dem Server ab, die du zurzeit noch nicht hast. In deinem Arbeitsverzeichnis wird sie jedoch überhaupt nichts verändern.
Sie wird einfach die Daten für dich holen und dir das Zusammenführen überlassen.
Es gibt jedoch die Anweisung git pull
, welche im Grunde genommen ein git fetch
ist, dem in den meisten Fällen augenblicklich ein git merge
folgt.
Wenn du einen Tracking-Branch eingerichtet hast, wie im letzten Abschnitt gezeigt, indem du ihn explizit setzt oder indem du ihn mit den Befehlen clone
oder checkout
für dich hast erstellen lassen, dann sucht git pull
nach dem Server und dem getrackten Branch. Git macht ein fetch vom Server und versucht dann diesen remote branch zu mergen.
Generell ist es besser, einfach explizit die Anweisungen git fetch
und git merge
zu benutzen, da die Magie der Anweisung git pull
häufig verwirrend sein kann.
Remote-Branches entfernen
Stellen wir uns vor, du bist mit deinem Remote-Branch fertig. Du und deine Kollegen sind fertig mit einer neuen Funktion und haben sie in den Branch master
des Remote-Servers (oder in welchem Branch auch immer sich dein stabiler Code befindet) einfließen lassen.
Du kannst einen Remote-Branch löschen, indem du die Anweisung git push
zusammen mit der Option --delete
ausführst.
Wenn du deinen serverfix
Branch vom Server löschen willst, führst du folgende Anweisung aus:
$ git push origin --delete serverfix
To https://github.com/schacon/simplegit
- [deleted] serverfix
Im Grunde genommen ist alles, was das bewirkt, dass der Zeiger vom Server entfernt wird. Der Git-Server bewahrt die Daten dort in der Regel eine Weile auf, bis eine Speicherbereinigung läuft. Wenn sie also versehentlich gelöscht wurden, ist es oft einfach, sie wiederherzustellen.