Git-Listen-Zweige: Ein praktischer Leitfaden

Wenn du schon mal an mehreren Features gleichzeitig gearbeitet hast, kommt dir diese Situation vielleicht bekannt vor: Du machst einen Git-Befehl und jetzt nicht mehr sicher bist, wo deine Arbeit von letzter Woche eigentlich gespeichert ist.

Dieses Problem wird mit zunehmender Größe der Projekte immer häufiger. Am Anfang hat ein Repository vielleicht nur einen „ main “-Zweig. Mit der Zeit machen Teams aber auch Zweige für neue Features, Bugfixes, Experimente, Releases und Notfall-Hotfixes. 

Hier wird es wichtig, die Branches in Git aufzulisten. Es hilft bei der Beantwortung praktischer Fragen:

• An welchem Projekt arbeite ich gerade?
• Welche anderen Zweige gibt es auf meinem Rechner?
• Welche Branches gibt's im Remote-Repository?

In dieser Anleitung schauen wir uns die Grundlagen zum Auflisten von Branches in Git an, wie du das machst und wie du häufig auftretende Probleme beheben kannst.

Wenn Git für dich komplett neu ist, empfehle ich dir, unseren Kurs „Einführung in Git“ zu machen, um dich sicherer zu machen, bevor du dich mit detaillierteren Themen zum Branch-Management beschäftigst.

Git-Branches verstehen

Bevor wir anfangen, sie aufzulisten, schauen wir uns mal an, was Git-Branches überhaupt sind. 

Ein häufiges Missverständnis ist, dass Git-Branches separate Ordner oder vollständige Kopien einer Codebasis sind, aber eigentlich ist ein Git-Branch nur ein kleiner Zeiger auf einen bestimmten Commit.

Du kannst dir das wie eine parallele Zeitlinie vorstellen, wo du Funktionen entwickeln oder isoliert experimentieren kannst, ohne deinen stabilen Hauptcode zu beeinträchtigen. Mit dieser Architektur geht das Erstellen und Zusammenführen von Branches echt schnell und effizient.

Quelle: Git

Git verfolgt deine aktuelle Position in diesen Zeitachsen mithilfe einer speziellen Referenz namens HEAD, die immer auf den Zweig zeigt, an dem du gerade arbeitest. Weil Verzweigungen nur Zeiger sind, geht das Wechseln von Kontexten sofort und man muss keine großen Dateien verschieben.

Mehr Infos findest du in unserem Tutorial zu Git-Branches oder in unserem Git-Spickzettel.

Wie man lokale Branches in Git auflistet

Nachdem wir das konzeptionelle Fundament gelegt haben, schauen wir uns an, wie du lokale Branches in deinem Repository auflisten kannst.

Ein lokaler Zweig ist ein Zweig, der auf deinem Computer gespeichert ist. Es ist im Ordner „ .git “ deines Repositorys und ist wie ein beweglicher Zeiger auf eine Reihe von Commits. Du kannst zu einem lokalen Branch wechseln, Änderungen vornehmen und neue Commits darauf erstellen.

Es hilft, sich lokale Zweigstellen so vorzustellen:

• Sie gehören zu deiner Kopie des Repositorys.
• Sie machen weiter, wenn du neue Änderungen machst.
• Sie werden nicht automatisch aktualisiert, wenn andere Leute Code pushen.

Mit Git-Branch arbeiten

Der häufigste und grundlegendste Befehl zum Auflisten lokaler Branches ist ziemlich einfach:

git branch

Wenn du diesen Befehl ohne zusätzliche Optionen ausführst, zeigt Git dir alle lokalen Branches an.

Wichtige Sachen, die du über „ git branch “ wissen solltest:

• Es werden nur lokale Zweige angezeigt, keine entfernten.
• Es verbindet sich nicht mit dem Internet.
• Es ändert weder Dateien noch Commits oder den Branch-Verlauf.

Weil es sicher und schnell ist, machen viele Entwickler „ git branch “ einfach aus Gewohnheit, bevor sie mit einer neuen Aufgabe anfangen oder den Kontext wechseln.

Die Ausgabe verstehen

Hier ist ein Beispiel dafür, was „ git branch “ anzeigen könnte:

 bugfix/login-timeout
  feature/payment-refactor
* main

Auch wenn diese Ausgabe einfach aussieht, gibt's ein paar wichtige Details, die man nicht übersehen sollte.

Zuerst zeigt das Sternchen (*) den gerade ausgecheckten Zweig an. Das ist der Zweig, mit dem dein Arbeitsverzeichnis gerade verbunden ist. Alle neuen Commits, die du machst, landen in diesem Branch.

Zweitens markiert Git den aktuellen Branch normalerweise grün. Das ist nur eine visuelle Hilfe vom Terminal und ändert nichts am Verhalten von Git.

Drittens, schau mal, was nicht gezeigt wird:

• Keine Commit-Daten
• Keine Autorennamen
• Keine Ferninformationen

Das ist so gewollt. Git hält die Standardausgabe kurz, sodass sie leicht zu überfliegen und mit anderen Befehlen zu kombinieren ist.

Tipp für Anfänger: Wenn dein Terminal nach dem Ausführen eines Git-Befehls mal „hängen“ bleibt, drück einfach q. Git nutzt oft einen Pager, um lange Ausgaben anzuzeigen, und das ist die normale Art, ihn zu beenden.

Nur den aktuellen Zweig holen

Manchmal ist es nicht nötig, alle Zweige aufzulisten. Vielleicht willst du nur wissen, in welchem Zweig du gerade bist. Git hat dafür einen eigenen Befehl:

git branch --show-current

Die Ausgabe ist einfach der Name des Zweigs:

main

Häufige Situationen, in denen das nützlich ist, sind zum Beispiel:

• Überprüfe deinen Branch, bevor du Code pushst.
• Den Namen des Zweigs in Skripten protokollieren
• Verwendung des Zweignamens in Automatisierungs- oder CI-Pipelines

Wenn Git im Zustand „detached HEAD” ist, gibt dieser Befehl nichts zurück. Auch wenn das auf den ersten Blick komisch klingt, ist es echt praktisch, wenn man Skripte schreibt, die erkennen müssen, ob ein Zweig ausgecheckt ist.

Häufiger Fehler: Einige Leute denken, Git sei „kaputt“, wenn kein Branch-Name angezeigt wird. Meistens heißt das einfach, dass du gerade nicht auf einem Branch bist, sondern auf einem bestimmten Commit.

So listest du Remote- und alle Branches in Git auf

Das Auflisten von Remote- oder sogar allen Branches in Git funktioniert ziemlich ähnlich wie das Auflisten von lokalen Branches.

Auflisten von Remote-Branches in Git

Remote-Repositorys, wie die auf GitHub oder GitLab, haben ihre eigenen Branches. Um sie anzuzeigen, füge das Flag „ -r “ hinzu:

git branch -r

  origin/HEAD -> origin/main
  origin/bugfix/login-timeout
  origin/feature/payment-refactor
  origin/main

Diese Beispielausgabe kann anfangs verwirrend sein, also schauen wir sie uns mal genauer an.

Was du hier siehst, sind Remote-Tracking-Zweige. Das sind lokale Referenzen, die Git benutzt, um sich den letzten bekannten Zustand des Remote-Repositorys zu merken.

Wichtige Punkte zum Verstehen:

• Diese Zweige werden lokal gespeichert.
• Sie werden nur aktualisiert, wenn du sie abrufst.
• Die bewegen sich nicht von selbst.

Tipp für Anfänger: Stell dir Remote-Tracking-Branches wie ein Notizbuch von Git vor. Git speichert, wie der Remote beim letzten Mal aussah, aber es aktualisiert das Notizbuch nur, wenn du es explizit abrufst.

Alle Branches in Git auflisten

Um sowohl lokale Zweige als auch Remote-Tracking-Zweige zusammen anzuzeigen, benutze das Flag „ -a “:

git branch -a

* main
  feature/payment-refactor
  remotes/origin/bugfix/login-timeout
  remotes/origin/main

Diese kombinierte Ansicht hilft dir zu verstehen, wie deine lokalen Zweigstellen mit den entfernten Zweigstellen zusammenhängen.

Zu beachtende Namensmuster:

• Lokale Zweige werden als einfache Namen angezeigt, wie z. B. main

• Remote-Tracking-Zweige werden unter remotes/origin/

Diese Ansicht ist besonders nützlich, wenn du dich fragst, ob du einen neuen lokalen Branch erstellen sollst, der einen bestehenden Remote-Branch verfolgt.

Immer zuerst holen

Wenn ein Teamkollege einen neuen Branch pusht und du ihn nicht sehen kannst, liegt das meistens daran, dass dein lokaler Cache veraltet ist. 

Die Lösung ist, Folgendes zu holen:

git fetch

Was „ git fetch “ macht:

• Lädt die neuesten Branch-Infos vom Remote-Server runter.
• Aktualisiert deine Remote-Tracking-Zweige
• Lässt deine Arbeitsdateien so, wie sie sind

Du kannst diesen Befehl jederzeit ohne Bedenken ausführen. Es wird kein Code zusammengeführt und deine Arbeit wird nicht überschrieben. Viele Teams machen „ git fetch “ zu einem Routineschritt, bevor sie die Zweige checken.

Häufiger Fehler: Anfänger verwechseln oft „ git fetch “ mit „ git pull “. Mit „Fetch“ holst du nur die aktualisierten Branch-Infos, während „Pull“ auch die Änderungen in deinen aktuellen Branch einbaut.

Wie du mehr Infos zu deiner Git-Branch-Liste bekommst

Manchmal reichen die Namen der Zweige nicht aus. Wenn du weitere Details sehen möchtest, gibt es ein paar hilfreiche Flags, die dir dabei helfen können.

Die letzten Commits anschauen

Um zu sehen, was jeder Zweig tatsächlich enthält, benutze:

git branch -v

Die Ausgabe könnte so aussehen:

* main   a1b2c3d Fix typo in README
  feature/payment-refactor e4f5g6h Refactor payment service

Wie du siehst, gibt das Flag „ -v “ einen wichtigen Kontext:

• Der kurze Commit-Hash zeigt, wo der Branch gerade hinzeigt.
• Die Commit-Nachricht gibt einen Hinweis auf den Zweck des Branches.

Das ist eine der einfachsten Möglichkeiten, um zu verstehen, wozu ein Branch dient, ohne ihn auszuprobieren.

Tipp für Anfänger: Wenn du dir nicht sicher bist, ob du einen Branch löschen kannst, schau dir einfach die letzte Commit-Meldung an.

Überprüfung der Upstream-Verbindungen

Lokale Branches verfolgen oft einen entsprechenden Remote-Branch. Um diesen Zusammenhang zu sehen, mach Folgendes:

git branch -vv

* main   a1b2c3d [origin/main] Fix typo in README
  feature/payment-refactor e4f5g6h [origin/feature/payment-refactor] Refactor payment service

Diese Ausgabe sagt dir Folgendes:

• Mit welchem Remote-Zweig ist dein lokaler Zweig verbunden?

• Woher „ git pull “ seine Daten bezieht

• Wo „ git push “ sich einsetzen wird

Wenn ein Zweig keinen Upstream hat, wird in den Klammern nichts angezeigt. Das erklärt oft Push- oder Pull-Fehler.

Häufiger Fehler: Der Versuch, „ git pull “ auf einem Branch ohne Upstream auszuführen, schlägt normalerweise fehl. In diesem Fall musst du zuerst einen Upstream-Zweig festlegen oder den Zweig zum ersten Mal pushen.

Zweige nach Datum oder Version sortieren

Um die zuletzt aktiven Branches zu finden, kannst du nach dem Commit-Datum sortieren:

git branch --sort=-committerdate

Dadurch werden die zuletzt aktualisierten Zweige oben und die älteren Zweige unten angezeigt.

Für Repositorys mit versionierten Branches ist die semantische Sortierung nützlicher:

git branch --sort=v:refname

Das hält sich an die Versionsnummern und vermeidet verwirrende alphabetische Reihenfolgen.

Wie filtert man die Branchenliste in Git?

Wenn du nach einer bestimmten Filiale suchst, kann das Filtern echt hilfreich sein. Ich zeig dir, wie das geht, mit ein paar wichtigen Flags.

Suche nach Namensmuster

Besonders in großen Repositorys kann das Filtern nach Namen echt viel Zeit sparen, wenn du den richtigen Branch suchst. Du kannst nach Namen filtern, indem du das Flag „ --list “ zusammen mit deinem Suchbegriff verwendest:

git branch --list 'feature/*'

Schau mal, wie „ * ” als Platzhalter benutzt wird: Das Ergebnis hier zeigt nur die Zweige, die dem Muster passen, also die, die mit feature anfangen. Teams benutzen oft Präfixe wie „ feature/ “, „ bugfix/ “ oder „ hotfix/ “, um alles ordentlich zu halten. Stell dir diese als Ordner für deine Zweige vor.

Zusammengeführte vs. nicht zusammengeführte Zweige finden

Zwei echt wichtige Filter sind:

git branch --merged
git branch --no-merged

Diese Befehle vergleichen andere Branches mit deinem aktuellen Branch.

• --merged zeigt Zweige, deren Arbeit schon dabei ist

• --no-merged zeigt Zweige, die noch einzigartige Commits haben

Sicherheitshinweis: Überprüfe immer nochmal, ob du auf dem richtigen Basis-Zweig bist (oft main oder develop), bevor du --merged benutzt. Die Ergebnisse hängen von deinem aktuellen Zweig ab.

Herausfinden, welcher Zweig einen Commit enthält

Wenn du einen Commit-Hash kennst und wissen willst, wo er sich befindet, benutze diesen Befehl:

git branch --contains <commit-hash>

Das ist praktisch, wenn du Fehler verfolgst oder checkst, ob ein Fix übernommen wurde.

Wenn dir zum Beispiel ein Kollege Folgendes sagt: Ich hab einen Fehler in diesem Commit-Hash gefunden; welche Branches sind davon betroffen? Mit diesem Befehl kannst du den genauen Ort des Fehlers finden.

Filter kombinieren für fortgeschrittene Arbeitsabläufe

Die Filter, die ich dir gezeigt habe, kannst du kombinieren, um die Ergebnisse weiter einzugrenzen. Schauen wir uns mal ein Beispiel an:

git branch --list 'feature/*' --no-merged

Mit diesem Befehl kannst du schnell alle nicht zusammengeführten „ feature/ “-Zweige sehen und das Team bleibt gut organisiert.

Fehlerbehebung bei häufigen Problemen

Mach dir keine Sorgen, wenn du auf Probleme stößt; die häufigsten Probleme lassen sich ganz einfach beheben.

Fehlende Remote-Zweige

Wenn du einen Branch nicht sehen kannst, den jemand anderes gepusht hat, hast du wahrscheinlich einfach vergessen, ihn zu fetchen. So behebst du das Problem:

1. Run git fetch

2. Dann die Zweige nochmal auflisten

Wenn das Problem durch das fehlende Abrufen verursacht wurde, wird deine lokale Ansicht mit dieser schnellen Lösung sofort aktualisiert.

Der losgelöste HEAD-Zustand

Manchmal sieht die Ausgabe von „ git branch “ so aus:

* (HEAD detached at a1b2c3d)

Das heißt, du bist nicht auf einem Zweig. Du schaust dir gerade einen bestimmten Commit direkt an.

In einem getrennten HEAD-Zustand zu sein, ist an sich nicht gefährlich, aber alle neuen Commits, die du machst, können später schwer zu finden sein, wenn du keinen Branch erstellst.

Um wieder normal weiterzuarbeiten, machst du mit „ checkout “ einen neuen Branch:

git checkout <branch-name>

Du kannst auch einen neuen Zweig von deiner aktuellen Position aus erstellen, indem du das Flag „ -b “ verwendest:

git checkout -b <new-branch-name>

Die Zweige sind nach dem Löschen immer noch da.

Wenn Remote-Branches nach dem Löschen auf dem Server immer noch da sind, kannst du ihre lokalen Verweise mit dem folgenden Befehl bereinigen:

git remote prune origin

Das räumt veraltete Verweise auf und hält dein Repository ordentlich.

Profi-Tipp: Alternativ kannst du auch bei jedem Abruf „ git fetch --prune “ verwenden, damit das Repo in einem einzigen Schritt aktualisiert und bereinigt wird.

Fazit

Das Auflisten von Branches in Git ist eine wichtige Fähigkeit, die dir hilft, dein Repository zu verstehen. Die Befehle und Flags, die in diesem Tutorial behandelt werden, helfen dir, Fehler zu vermeiden und sicher mit anderen zusammenzuarbeiten. 

Wenn du ein neues Projekt startest, lohnt es sich meistens, darüber nachzudenken, welche Art von Verzweigungsstruktur du brauchst. Ein paar Tipps findest du in diesem Leitfaden zur Git-Verzweigungsstrategie.

Bist du bereit, über die Grundlagen hinauszugehen? Der Lernpfad „ : Git Fundamentals“ bringt dir die Konzepte und praktischen Erfahrungen bei, die du brauchst, um vom Anfänger zum Profi zu werden.