Git: Wie checkt man einen Remote-Branch aus?
Ein Kollege hat einen Branch gepusht und du willst daran arbeiten. In aktuellem git ist das ein Befehl — allerdings erst nach einem Fetch, und nur wenn du die eine Form vermeidest, die dich auf gar keinem Branch zurücklässt.
Der Befehl
user@pc:~$ git fetch
user@pc:~$ git switch feature
branch 'feature' set up to track 'origin/feature'.
Switched to a new branch 'feature'
upstream : origin/feature
git switch hat gemerkt, dass es lokal
kein feature gibt, genau einen Remote gefunden der eines hat, daraus einen
lokalen Branch erzeugt und den Upstream gesetzt. git checkout feature tut
dasselbe; switch ist der neuere, engere Befehl und deshalb vorzuziehen — denn
checkout erledigt daneben noch ein halbes Dutzend unverwandter Aufgaben.
Der Fetch ist nicht optional
before fetch, git branch -r : origin/main
after fetch, git branch -r : origin/feature origin/main
Vor dem Fetch hat dein Repository von dem Branch nie gehört, und der Befehl sagt dir nur, dass der Pfad zu nichts passt. Git sieht nicht selbst nach — es weiß, was ihm der letzte Fetch mitgeteilt hat.
Wenn ein Branch, den jemand steif und fest gepusht haben will, nicht auftaucht,
ist git fetch also das Erste was man probiert und kein Zeichen dafür, dass
etwas kaputt ist.
Warum ein frischer Klon nur einen Branch zeigt
local : main
remote : origin/feature origin/main
Das verwirrt regelmäßig. git clone lädt
alles herunter, legt aber genau einen lokalen Branch an. Die übrigen sind
als Remote-Tracking-Refs da — deshalb sieht git branch leer aus und
git branch -r nicht.
Es fehlt nichts. Man muss auch keine “alle Branches klonen” — du hast sie
bereits, und git switch <name> erzeugt den lokalen Branch bei Bedarf.
Die Form, die dich ins Nichts setzt
user@pc:~$ git checkout origin/feature
You are in 'detached HEAD' state...
git branch --show-current : ''
Die leere Ausgabe ist das Symptom: Du bist auf keinem Branch. origin/feature
ist ein Remote-Tracking-Ref, und ihn direkt auszuchecken setzt HEAD auf einen
Commit statt auf einen Branch.
Alles sieht normal aus, bis du committest — und dann gehört der Commit zu keinem
Branch. Wechselst du weg, ist er unreferenziert und nur noch über git reflog
zu finden.
Ein detached HEAD ist absichtlich nützlich, um sich einen alten Commit anzusehen oder einen Tag zu bauen. Er ist nur nicht das, was du wolltest, als du an dem Branch von jemandem arbeiten wolltest.
Wenn git nicht raten kann
Die Ein-Wort-Form setzt voraus, dass der Name eindeutig ist. Bei zwei Remotes,
die beide einen feature-Branch haben, verweigert git die Auswahl. Dann sagst
du es dazu:
user@pc:~$ git switch -c feature --track origin/feature
upstream : origin/feature
-c legt den Branch an, --track setzt den Upstream, damit ein späteres
nacktes git push und git pull wissen wohin. Dieselbe Form nimmst du, wenn du
lokal einen anderen Namen willst als auf dem Remote — deinen Namen hinter -c,
den Remote-Branch hinter --track.
Die alte Schreibweise, die weiterhin funktioniert und in den meisten Antworten steht:
user@pc:~$ git checkout -b feature origin/feature
Hinweis zu Netcup (Werbung)
Der deutsche Hoster Netcup bietet unter anderem günstige und zugleich leistungsstarke Webhosting Pakete, KVM-basierte Root Server und dezidierte Server an. Mit unseren Gutscheincodes kannst du noch mehr Geld sparen (6€ bei deiner ersten Bestellung, 30% Rabatt auf alle KVM-basierten Root Server, ...).