3.5 Git Branching - Remote-Branches

Wenn Sie einen Branch mit der Welt teilen möchten, müssen Sie ihn auf einen Remote-Server hochladen, auf dem Sie Schreibrechte besitzen. Ihre lokalen Branches, auf die Sie schreiben, werden nicht automatisch mit den Remotes synchronisiert – Sie müssen die Branches, die Sie freigeben möchten, explizit pushen. Auf diese Weise können Sie private Branches, die Sie nicht veröffentlichen wollen, zum Arbeiten benutzen und nur die Feature-Branches pushen, an denen Sie mitarbeiten wollen.

Wenn Sie einen Branch namens serverfix besitzen, an dem Sie mit anderen arbeiten möchten, dann können Sie diesen auf dieselbe Weise Hochladen wie Ihren ersten Branch. Führen Sie die Anweisung git push <remote> <branch> aus:

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, Sie können ihn aber in der Regel auslassen. Sie können 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“. Sie können dieses Format auch benutzen, um einen lokalen Branch in einen Remote-Branch mit anderem Namen zu pushen. Wenn Sie nicht wollten, dass er auf dem Remote als serverfix bezeichnet wird, können Sie stattdessen git push origin serverfix:awesomebranch ausführen, um Ihren lokalen serverfix Branch auf den awesomebranch Branch im Remote-Projekt zu pushen.

Das nächste Mal, wenn einer Ihrer Mitarbeiter Daten vom Server abholt, wird er eine Referenz auf die Server-Version des Branches serverfix unter dem Remote-Branch origin/serverfix erhalten:

Es ist wichtig zu beachten, dass Sie bei einem Abruf, der neue Remote-Tracking-Branches abruft, nicht automatisch über lokale, bearbeitbare Kopien davon verfügen. Mit anderen Worten, in diesem Fall haben Sie keinen neuen Branch serverfix – Sie haben nur einen Zeiger origin/serverfix, den Sie nicht ändern können.

Um diese Änderungen in Ihren gegenwärtigen Arbeitsbranch einfließen zu lassen, können Sie die Anweisung git merge origin/serverfix ausführen. Wenn Sie Ihren eigenen serverfix Branch haben wollen, an dem Sie arbeiten können, können Sie ihn von Ihrem Remote-Tracking-Branch ableiten (engl. base):

Das erstellt Ihnen einen lokalen Branch, an dem Sie arbeiten können, und der dort beginnt, wo origin/serverfix derzeit steht.

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 Sie sich auf einem Tracking-Branch befinden und git pull eingeben, weiß Git automatisch, von welchem Server Daten abzuholen sind und in welchen Branch diese einfließen sollen.

Wenn Sie ein Repository klonen, wird automatisch ein master Branch erzeugt, welcher origin/master trackt. Sie können jedoch auch andere Tracking-Branches erzeugen, wenn Sie wünschen – welche die Branches auf anderen Remotes folgen. Der einfachste Fall ist das Beispiel, dass Sie gerade gesehen haben, die Ausführung der Anweisung git checkout -b <branch> <remotename>/<branch>. Das ist eine übliche Operation, für die Git die Kurzform --track bereitstellt:

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 Sie zum Auschecken verwenden möchten (a), nicht existiert und (b) genau mit einem Namen auf nur einem Remote übereinstimmt, erstellt Git einen Tracking-Branch für Sie:

Um einen lokalen Branch mit einem anderen Namen als den entfernten Branch einzurichten, können Sie die erste Version mit einem anderen lokalen Branch-Namen verwenden:

Nun wird Ihr lokaler Branch sf automatisch von origin/serverfix pullen.

Wenn Sie bereits über einen lokalen Branch verfügen und ihn auf einen Remote-Branch festlegen möchten, den Sie gerade gepullt haben haben, oder den von Ihnen gefolgten Upstream-Branch ändern möchten, können Sie die Option -u oder --set-upstream-to für Git verwenden branch, um es explizit festzulegen.

Wenn Sie die Tracking-Branches sehen wollen, die Sie eingerichtet haben, können Sie die Anweisung git branch zusammen mit der Option -vv ausführen. Das listet Ihre lokalen Branches zusammen mit weiteren Informationen auf, einschließlich was jeder Branch trackt und ob Ihr lokaler Branch voraus oder zurück liegt, oder auch beides.

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 gemergt 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 Sie zum letzten Mal Daten vom Server abgeholt haben. Diese Anweisung greift nicht auf die Server zu, sie liefert nur die Informationen, welche beim letzten Server-Kontakt lokal zwischengespeichert wurden. Wenn Sie gänzlich aktuelle Zahlen von „ahead“ und „behind“ wollen, dann müssen Sie, kurz bevor Sie die Anweisung ausführen, von all Ihren Remote-Servern Daten abholen (fetch). Sie könnten das so machen:

Die Anweisung git fetch holt alle Änderungen auf dem Server ab, die Sie zurzeit noch nicht haben. In Ihrem Arbeitsverzeichnis wird sie jedoch überhaupt nichts verändern. Sie wird einfach die Daten für Sie holen und Ihnen 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 Sie einen Tracking-Branch eingerichtet haben, wie im letzten Abschnitt gezeigt, indem Sie ihn explizit setzen oder indem Sie ihn mit den Befehlen clone oder checkout für sich haben erstellen lassen, dann sucht git pull nach dem Server und dem getrackten Branch. Git macht ein fetch von dem 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.

Stellen wir uns vor, Sie sind mit Ihrem Remote-Branch fertig. Sie und Ihre Kollegen sind fertig mit einer neuen Funktion und haben sie in den Branch master des Remote-Servers (oder in welchem Branch auch immer sich Ihr stabiler Code befindet) einfließen lassen. Sie können einen Remote-Branch löschen, indem die Anweisung git push zusammen mit der Option --delete ausführen. Wenn Sie Ihren serverfix Branch vom Server löschen wollen, führen Sie folgende Anweisung aus:

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.