Git refs: An overview

Dies ist besonders hilfreich beim Schreiben benutzerdefinierter Skripte, die eine Commit-Referenz akzeptieren. Statt die Commit-Referenz manuell zu parsen, kann git rev-parse die Eingabe für dich normalisieren.

Eine Referenz bzw. ref ist eine indirekte Methode zur Referenzierung eines Commits. Du kannst sie als einen benutzerfreundlichen Alias für einen Commit-Hash betrachten. Sie sind der interne Mechanismus von Git zur Repräsentierung von Branches und Tags.

Refs werden als normale Textdateien im .git/refs-Verzeichnis gespeichert, in dem .git normalerweise .git heißt. Zum Durchsuchen der Refs in einem deiner Repositorys gehst du zu .git/refs. Dort solltest du die folgende Struktur sehen, wobei natürlich je nach den in deinem Repo vorhandenen Branches, Tags und Remotes andere Dateien enthalten sein werden.

Das Verzeichnis heads definiert alle lokalen Branches in deinem Repository. Jeder Dateiname entspricht dem Namen des jeweiligen Branches. In der Datei selbst gibt es einen Commit-Hash. Dieser Commit-Hash gibt an, wo sich die Branch-Spitze befindet. Das kannst du überprüfen, indem du die folgenden beiden Befehle aus dem Root-Verzeichnis des Git-Repositorys ausführst:

Der Commit-Hash, der vom Befehl cat zurückgegeben wird, sollte mit der Commit-ID übereinstimmen, die mit git log angezeigt werden kann.

Um den Ort des main-Branch zu ändern, muss Git dies lediglich in der refs/heads/main-Datei ändern. Genauso lässt sich ein neuer Branch einfach erstellen, indem ein Commit-Hash in eine neue Datei eingetragen wird. Dies ist einer der Gründe, warum Git-Branches so viel schlanker sind als das SVN-Modell.

Das tags-Verzeichnis funktioniert auf dieselbe Weise, enthält jedoch Tags statt Branches. Das remotes-Verzeichnis listet alle Remote-Repositorys, die du mit git remote erstellt hast, als separate Unterverzeichnisse auf. In jedem einzelnen findest du alle Remote Branches, die du in dein Repository gezogen hast.

Wenn du einem Git-Befehl eine Referenz anfügst, kannst du entweder den vollen Namen der Referenz oder einen Kurznamen verwenden, anhand dessen Git nach einer übereinstimmenden Referenz sucht. Du solltest bereits mit Kurznamen für Referenzen vertraut sein, da du diese jedes Mal verwendest, wenn du einen Branch beim Namen nennst.

Das Argument some-feature im obigen Befehl ist eigentlich ein Kurzname für den Branch. Git wandelt dies vor der Verwendung in refs/heads/some-feature um. Du kannst in der Befehlszeile auch die komplette Ref angeben:

Auf diese Weise werden Unklarheiten bezüglich des Orts der Ref vermieden. Dies ist z. B. dann erforderlich, wenn sowohl ein Branch und ein Tag namens some-feature vorhanden sind. Sofern du dich jedoch an die korrekten Benennungskonventionen hältst, sollten eigentlich keine Zweideutigkeiten aufkommen.

Wir werden im Abschnitt zu den Refspecs noch weitere vollständige Referenznamen sehen.

In großen Repositorys entfernt Git im Rahmen einer Speicherbereinigung in regelmäßigen Abständen überflüssige Objekte und komprimiert Referenzen in eine einzige Datei für eine Verbesserung der Performance. Diese Komprimierung während der Bereinigung kannst du mit dem folgenden Befehl erzwingen:

Hiermit werden alle Branch- und Tag-Dateien im refs-Ordner in eine einzige Datei namens packed-refs verschoben. Diese befindet sich ganz oben im .git-Verzeichnis. Wenn du diese Datei öffnest, wird dir eine Zuordnung von Commit-Hashes zu Referenzen angezeigt.

Äußerlich wirkt sich dies überhaupt nicht auf die normale Git-Funktionalität aus. Aber wenn du dich gewundert hast, warum dein .git/refs-Ordner leer ist, weißt du jetzt, wo deine Referenzen sich nun befinden.

Neben dem refs-Verzeichnis gibt es noch einige spezielle Refs, die sich im .git-Verzeichnis der obersten Ebene befinden. Diese sind im Folgenden aufgelistet:

• HEAD: Der aktuell ausgecheckte Commit/Branch
• FETCH_HEAD: Der letzte von einem Remote-Repo abgerufene Branch
• ORIG_HEAD: Eine Backup-Referenz für den HEAD, bevor drastische Änderungen daran vorgenommen werden
• MERGE_HEAD: Die Commits, die du mit git merge in den aktuellen Branch mergst
• CHERRY_PICK_HEAD: Ein gezielt ausgewählter Commit

Diese Referenzen werden alle bei Bedarf von Git erstellt und aktualisiert. Der Befehl git pull führt z. B. zuerst git fetch aus, wodurch die FETCH_HEAD-Referenz aktualisiert wird. Anschließend wird git merge FETCH_HEAD ausgeführt, um den Pull der abgerufenen Branches in das Repository abzuschließen. Natürlich kannst du diese speziellen Refs wie alle anderen Refs auch verwenden, genauso wie du dies sicherlich auch mit HEAD gemacht hast.

Diese Dateien enthalten je nach Dateityp und Status in deinem Repository unterschiedliche Inhalte. Die HEAD-Ref kann entweder eine symbolische Ref, die einfach eine Referenz zu einer anderen Ref anstatt von einem Commit-Hash ist, oder einen Commit-Hash enthalten. Wirf z. B. einmal einen Blick auf die Inhalte von HEAD, wenn du dich im main-Branch befindest:

This will output ref: refs/heads/main, which means that HEAD points to the refs/heads/main ref. This is how Git knows that the main branch is currently checked out. If you were to switch to another branch, the contents of HEAD would be updated to reflect the new branch. But, if you were to check out a commit instead of a branch, HEAD would contain a commit hash instead of a symbolic ref. This is how Git knows that it’s in a detached HEAD state.

Die meiste Zeit wird HEAD die einzige Referenz sein, die du direkt verwendest. Die anderen sind in der Regel nur dann von Nutzen, wenn du Low-Level-Skripte schreibst, die einen Zugriff auf die tieferliegende Funktionsweise von Git benötigen.

Eine Refspec ordnet einen Branch im lokalen Repository einem Branch in einem Remote-Repository zu. Dies ermöglicht das Management von Remote Branches mit Git-Befehlen und die Konfiguration von erweitertem git push- und git fetch-Verhalten.

Eine Refspec wird mit [+]＜src＞:＜dst＞ angegeben. Der Parameter ＜src＞ steht für den Quell-Branch im lokalen Repository und der Parameter ＜dst＞ steht für den Ziel-Branch im Remote-Repository. Das optionale +-Zeichen zwingt das Remote-Repository zu einem Nicht-Fast-Forward-Update.

Refspecs können zusammen mit git push dazu genutzt werden, dem Remote-Branch einen anderen Namen zu geben. Der folgende Befehl pusht z. B. den main-Branch zum origin-Remote-Repo, genauso wie dies mit einem einfachen git push-Befehl geschehen würde, aber in diesem Fall wird qa-main als Branch-Name für den Branch im origin-Repository verwendet. Dies ist für QS-Teams, die ihre eigenen Branches in ein Remote-Repository pushen müssen, hilfreich.

You can also use refspecs for deleting remote branches. This is a common situation for feature-branch workflows that push the feature branches to a remote repo (e.g., for backup purposes). The remote feature branches still reside in the remote repo after they are deleted from the local repo, so you get a build-up of dead feature branches as your project progresses. You can delete them by pushing a refspec that has an empty parameter, like so:

Das ist äußerst praktisch, da du dich nicht in dein Remote-Repository einloggen und den Remote Branch manuell löschen musst. Hinweis: Ab Git v1.7.0 kannst du die Option --delete statt der oben beschriebenen Methode anwenden. Der folgende Befehl hat denselben Effekt wie der obige:

Du kannst das Verhalten von git fetch mit Refspecs ändern, indem du deiner Git-Konfigurationsdatei ein paar Zeilen hinzufügst. In den Standardeinstellungen ruft git fetch alle Branches im Remote-Repository ab. Dies geschieht aufgrund des folgenden Abschnitts in der .git/config-Datei:

Die fetch-Zeile weist git fetch an, alle Branches vom origin-Repository herunterzuladen. Aber manche Workflows benötigen nicht alle Branches. In vielen Continuous-Integration-Workflows ist beispielsweise nur der main-Branch von Bedeutung. Um nur den main-Branch abzurufen, änderst du die fetch-Zeile folgendermaßen:

Du kannst auch git push auf ähnliche Weise konfigurieren. Wenn du z. B. den main-Branch zum qa-main im origin-Remote pushen möchtest (wie wir dies oben gemacht haben), änderst du die Konfigurationsdatei folgendermaßen:

Mithilfe der Refspecs erhältst du die absolute Kontrolle darüber, wie die verschiedenen Git-Befehle Branches zwischen Repositorys übertragen. Über sie kannst du Branches umbenennen und von deinem lokalen Repository löschen, Branches mit anderen Namen abrufen/pushen und git push sowie git fetch so konfigurieren, dass die Befehle nur auf die gewünschten Branches angewendet werden.

Du kannst auch Commits im Verhältnis zu einem anderen Commit referenzieren. Mit dem Zeichen ~ erreichst du Parent-Commits. Folgendermaßen wird beispielsweise der Grandparent von HEAD angezeigt:

Doch wenn du mit Merge-Commits arbeitest, wird es ein wenig komplizierter. Da Merge-Commits mehr als einen Parent haben, kannst du auch mehrere Pfaden folgen. Bei einem 3-Wege-Merge stammt der erste Parent von dem Branch, in dem du dich befandst, als du den Merge durchgeführt hast, und der zweite Parent stammt von dem Branch, den du in deinem git merge-Befehl angegeben hast.

Das Zeichen ~ folgt immer dem ersten Parent eines Merge-Commits. Wenn du dem Pfad eines anderen Parents folgen möchtest, musst du diesen mit dem Zeichen ^ bestimmen. Ist beispielsweise HEAD ein Merge-Commit, gibt Folgendes den zweiten Parent von HEAD zurück.

Du kannst das Zeichen ^ mehrmals verwenden, wenn du mehr als eine Generation zurückgehen möchtest. Beim folgenden Beispiel wir der Grandparent vom HEAD (angenommen, es handelt sich um einen Merge-Commit), der sich im zweiten Parent befindet, angezeigt.

Um zu verdeutlichen, wie ~ und ^ funktionieren, ist in der folgenden Abbildung dargestellt, wie ein Commit von A aus mit relativen Referenzen erreicht wird. In manchen Fällen gibt es mehrere Wege zum Erreichen eines Commits.

Relative Referenzen können mit demselben Befehl wie eine normale Referenz verwendet werden. Die folgenden Befehle nutzen z. B. alle eine relative Referenz:

Der Reflog ist das Sicherheitsnetz von Git. Er zeichnet fast jede Änderung auf, die du in deinem Repository vornimmst – unabhängig davon, ob du einen Snapshot committet hast oder nicht. Er ist im Prinzip ein chronologischer Verlauf aller Aktionen, die du in deinem lokalen Repository durchgeführt hast. Um den Reflog anzuzeigen, führst du den Befehl git reflog aus. Die Ausgabe sollte in etwa folgendermaßen aussehen:

Dies kann folgendermaßen übersetzt werden:

• Du hast soeben HEAD~2 ausgecheckt.
• Davor hast du eine Commit-Nachricht geändert.
• Davor hast du den feature-Branch in den main-Branch gemergt.
• Davor hast du einen Snapshot committet.

Über die Syntax HEAD{} kannst du im Reflog gespeicherte Commits referenzieren. Dies funktioniert so ähnlich wie mit den HEAD~-Referenzen aus dem vorigen Abschnitt, aber bezieht sich hier auf einen Eintrag im Reflog anstatt auf den Commit-Verlauf.

Du kannst auf diese Weise einen Commit auf einen andernfalls verloren gegangenen Status zurücksetzen. Nehmen wir an, du hast gerade ein neues Feature mit git reset verworfen. Dein Reflog könnte in etwa so aussehen:

Die drei Commits vor dem git reset sind nun defekt, d. h. sie können nicht referenziert werden – außer über das Reflog. Nehmen wir an, du stellst fest, dass du nicht deine ganze Arbeit hättest verwerfen sollen. In diesem Fall musst du lediglich den HEAD@{1}-Commit auschecken, um zurück zu dem Zustand deines Repositorys vor dem Ausführen von git reset zu gelangen.

Dadurch wechselst du in einen Zustand mit losgelöstem HEAD. Von hier aus kannst du einen neuen Branch erstellen und an deinem Feature weiterarbeiten.

Nun solltest du in der Lage sein, problemlos Commits in einem Git-Repository referenzieren. Wir haben gelernt, wie Branches und Tags als Referenzen im .git-Unterverzeichnis gespeichert werden, wie eine packed-refs-Datei gelesen wird, wie HEAD dargestellt wird, wie Refspecs für erweiterte Push- und Fetch-Vorgänge genutzt wird und wie mit den relativen Operatoren ~ und ^ eine Branch-Hierarchie durchkämmt werden kann.

Außerdem haben wir uns das Reflog angesehen, das zur Referenzierung von Commits dient, die durch andere Mittel nicht verfügbar sind. Dies ist eine hervorragende Möglichkeit zur Wiederherstellung in Situationen, in denen wir denken: "Ups, das hätte ich besser nicht machen sollen."

Der Zweck dieser Übung war, zu lernen, wie du in jedem erdenklichen Entwicklungsszenario genau den Commit auswählst, den du benötigst. Diese Kenntnisse kannst du leicht mit deinem bereits vorhandenen Wissen zu Git kombinieren, da die gebräuchlichsten Befehle Refs als Argument akzeptieren. Hierzu zählen git log, git show, git checkout, git reset, git revert, git rebase und noch viele andere Befehle.