10 Stufen von Git-Aliasen: Konzepte für Anfänger bis Fortgeschrittene

Wusstet ihr, dass sich Git auf vielfältige Weise an eure Bedürfnisse anpassen lässt?

Die Hauptmotivation für das Erstellen von Git-Aliasen kann eine oder mehrere der folgenden sein:

• Optimieren: Erstellt Kurzbefehle für häufig verwendete Git-Befehle.

• Anpassen: Lasst Git so arbeiten, wie ihr es möchtet, oder unterstützt im Team vereinbarte Arbeitsweisen.

• Merken: Leicht zu merkende Kurzbefehle für komplexe Vorgänge.

Im ersten Teil meiner Blogserie nehme ich euch mit auf eine Reise von den grundlegenden Basics über Git-Aliase, die euch lediglich längere Befehle abtippen ersparen, bis hin zu fortgeschrittenen Funktionen, die selbst viele erfahrene Git-Veteranen noch nie genutzt haben.

Teil zwei knüpft daran an, stellt noch fortgeschrittenere Konzepte vor und wagt sich an wirklich „abgefahrene“ Einsatzmöglichkeiten für Git-Aliase – einschließlich einiger völlig verrückter Beispiele –, bevor Alternativen für dieselben Anforderungen besprochen werden.

Wenn ihr diese Techniken lernt und versteht – unabhängig davon, ob ihr Aliase von anderen übernehmt oder selbst die Grenzen auslotet –, werdet ihr Git effizienter und souveräner nutzen und hoffentlich mehr Freude an der täglichen Arbeit mit Git haben. Nebenbei lernt ihr wahrscheinlich auch einige Tipps und Tricks kennen und entdeckt Bereiche von Git, von deren Existenz ihr nicht einmal wusstet.

Was sind Git-Aliase, und wie richten wir sie ein?

Git-Aliase ersetzen Git-Unterbefehle – ähnlich wie beispielsweise Bash-Aliase andere Bash-Befehle oder Skripte ersetzen. Git ermöglicht euch einfach, eigene Git-Befehle zu definieren, die genau das tun, was ihr möchtet, und sich nahtlos zusammen mit den integrierten Befehlen verwenden lassen.

Aliase werden in der Git-Konfigurationshierarchie definiert. Da sie jedoch in der Regel überall auf unserem Rechner funktionieren sollen, ist die globale Konfiguration der natürliche Ort dafür.

Ihr könnt Aliase entweder direkt in eurer globalen Konfigurationsdatei bearbeiten oder den Befehl git config verwenden.

Um euren ersten einfachen Alias zu erstellen, probiert einfach Folgendes aus:

Dadurch wird im Abschnitt [alias] eurer globalen Konfigurationsdatei eine neue Zeile hinzugefügt und der Abschnitt erstellt, falls er noch nicht vorhanden ist. Schauen wir es uns an:

Für komplexere Aliase empfehle ich euch im weiteren Verlauf einfach, ~/.gitconfig in eurem bevorzugten Editor zu öffnen und eure Aliase dort direkt hinzuzufügen oder zu ändern.

Level 1: Die Tippfaulen

Okay, beginnen wir mit dem ersten Level. Ich bin faul und möchte einfach die Eingabe von Befehlen optimieren, die ich hunderte Male am Tag nutze, oder häufige Tippfehler abfangen.

Den Vorschlag st haben wir oben bereits gesehen, aber hier sind noch einige weitere gängige Beispiele für einfache Kurzbefehle:

Aliase für „häufige Tippfehler“ sind eine persönliche Präferenz. Erstellt Aliase für die Befehle, die eure Finger einfach nicht tippen können. Mein persönlicher Erzfeind ist switch, aber ich habe beschlossen, immer das oben vorgeschlagene kurze „sw“ zu verwenden, statt Aliase für all die möglichen Tippfehler zu erstellen, die ich bei diesem einen Wort machen kann. Hier sind aber ein paar Beispiele zur Inspiration:

Vielleicht überlegt ihr jetzt schon, welche Git-Befehle sich besonders gut für Aliase eignen. Vor Jahren habe ich darauf eine interessante Antwort gefunden. Wie Git unterstützt auch meine Shell (Bash, Zsh) Aliase. Deshalb habe ich in meinen Konfigurationsdateien .bashrc und .zshrc den folgenden Shell-Alias erstellt:

Einige davon sind möglicherweise bereits vorhandene Aliase (hier slog, st und glog), die anderen könnten für euch aber durchaus gute Kandidaten sein, um sie mit bereits erstellten Aliasen zu „verkürzen“ oder euch an ihre Verwendung zu erinnern. Der einzige Grund, warum ich git status trotz meines Alias git st so häufig nutze, ist, dass ich viele Git-Schulungen gebe und mich dort dazu verpflichte, die tatsächlichen Befehle zu verwenden.

Level 2: Einfache Optionen, damit ihr nicht täglich Options-Flags eingeben müsst

Es ist also Zeit, die Lautstärke bei Git-Aliasen eine Stufe höher zu drehen. Mit Aliasen können wir den Git-Befehlen, für die wir Aliase erstellen, auch „Optionen“ hinzufügen. Schauen wir uns also an, wie wir das nutzen können.

Der häufigste Anwendungsfall besteht darin, einfache Aliase für gängige Varianten der Git-log-Ausgabe zu erstellen.

Zum Beispiel:

Ein weiterer guter Ansatz ist, mit dieser Funktion die lästigen „fehlenden“ Git-Befehle zu erstellen, die es eurer Meinung nach eigentlich geben sollte und bei denen ihr euch vielleicht nur schwer merken könnt, welchen Befehl und welche Option ihr genau für diese sehr häufige Aufgabe braucht.

Zugegeben: Viele Git-Nutzer haben möglicherweise noch nie von diesen Git-Befehlen und -Optionen gehört, geschweige denn sie verwendet. Das macht diese Aliase entweder nutzlos oder zu einer großartigen Lernmöglichkeit.

Level 3: Komplexe Argumente helfen uns, selten verwendete Befehle im Gedächtnis zu behalten

Auf der nächsten Stufe unserer Reise untersuchen wir, wie sich Aliase für Befehle mit komplexen Argumenten nutzen lassen.

Bisher haben wir uns vor allem auf Aliase für häufig oder regelmäßig verwendete Befehle konzentriert. Da wir jetzt aber deutlich komplexere Befehle abkürzen können, kann es auch hilfreich sein, den umgekehrten Weg zu gehen und Aliase zu verwenden für:

• Selten verwendete schwer zu merkende Git-Aufgaben.

• Schwer einzugebende Befehle einfacher handhabbar machen.

So könnt ihr praktische Git-Funktionen nutzen, die ihr sonst vielleicht gar nicht verwenden würdet.

Wie ihr seht, habe ich die Aliase in den obigen Beispielen „inline“ beschrieben, indem ich die Möglichkeit genutzt habe, # Kommentare in eurer Konfigurationsdatei hinzuzufügen. Das soll nicht nur das Beispiel verständlicher machen, sondern euch ausdrücklich dazu ermuntern, dies auch in eurer tatsächlichen Konfiguration zu tun. Ich habe viel zu viele Jahre gebraucht, um auf die harte Tour zu lernen, dass das sinnvoll ist. Inzwischen habe ich zahlreiche seltsame Aliase und andere Einstellungen angesammelt, deren Zweck ich nicht mehr genau kenne.

Sehen wir uns ein paar weitere konkrete und häufig verwendete Beispiele aus meiner Sammlung an. Dieses Mal zeige ich euch auch die Ergebnisse. Ich zeige euch einen nützlichen Diff-Alias, aber zuerst die „Vorher“-Ansicht beim Ausführen von git diff für eine Markdown-Datei.

Fügen wir nun einen Alias hinzu:

Und verwenden stattdessen diesen:

Das ist natürlich viel übersichtlicher und leichter zu erfassen. Nicht der Alias selbst bewirkt diesen Zauber – es sind integrierte Funktionen von Git. Der Alias macht sie jedoch in meinem Alltag nützlich, weil ich mir nicht jedes Mal die Eingabe git diff -w --word-diff=color --ignore-space-at-eol merken möchte.

Definieren wir:

Der gezeigte Ausschnitt deckt einen Bereich von über 3.000 Commits im Tensorflow-Repository ab, indem nur die „markierten“ Commits angezeigt werden (Tags oder Branch-Köpfe).

Zum Abschluss dieses Levels und als gute Überleitung zum nächsten sehen wir uns an, was vermutlich der größte Vorteil von Aliasen mit komplexen Argumenten ist: die Möglichkeit, noch stärker angepasste git log-Befehle zu erstellen, die mithilfe benutzerdefinierter Formate euren Vorlieben entsprechen. Ich möchte daraus kein Tutorial zu den eigentlichen Formatierungsoptionen machen. Legen wir also direkt los – ihr werdet schnell verstehen, worum es geht. All das ist im Abschnitt Pretty formats von git help log ausführlich dokumentiert.

Ich präsentiere euch meinen täglichen Standardbegleiter:

Level 4: Pretty formats – Aliase durch Wiederverwendbarkeit aufräumen

Für dieses Level verlassen wir den unmittelbaren Bereich der Git-Aliase. Ich zeige euch, wie ihr die wenig bekannte Funktion benutzerdefinierter Pretty-Formate nutzen könnt, um eure Aliase aufzuräumen und ihre Wiederverwendbarkeit deutlich zu verbessern.

(Die tatsächlichen Aliase waren viel länger, verwendeten aber alle denselben Format-String.)

Und viele ähnliche. Das machte es jedes Mal wirklich lästig, wenn ich das Format, die Farbgebung usw. anpassen wollte.

In neueren Git-Versionen können Aliase inzwischen auf andere Aliase verweisen. Dadurch lässt sich das Obige deutlich verbessern, zum Beispiel:

Es stellt sich jedoch heraus, dass es eine bessere Möglichkeit gibt.

(Weitere Informationen findet ihr in der oben verlinkten Dokumentation.)

Viel zu spät auf meiner Reise entdeckte ich, dass Git mir erlaubte, eigene benutzerdefinierte „Pretty“-Formate in der Git-Konfiguration zu definieren. Als ich diese Funktion fand, war sie einfach großartig!

Diese Formate können im Abschnitt [pretty] eurer Konfiguration (oder mit git config –global pretty.myformat …..) wie folgt definiert werden:

Sobald ich diese definiert habe, kann ich sie jederzeit verwenden, wenn ich einen Git-log-Befehl ausführe:

Das bedeutet auch, dass ich all meine merkwürdigen Log-Aliase so umschreiben kann, dass sie mein eigenes Pretty-Format verwenden. Dann habe ich nur noch eine Stelle, die ich bearbeiten muss, wenn sich mein Geschmack ändert.

Ein weiterer Vorteil dieser definierten Pretty-Formate ist, dass ich sie auch bei spontanen Log-Befehlen bei Bedarf verwenden kann.

Stufe 5: Präfixe – Git-Verhalten für bestimmte Git-Unterbefehle überschreiben

Um diesen ersten Teil des Blogbeitrags abzurunden, schauen wir uns in Stufe 5 ein wenig bekanntes Feature von Git-Aliasen an, das ein ebenfalls eher unbekanntes Feature nutzt.

Wie sich herausstellt, können Git-Aliase Optionen nicht nur an den Git-Unterbefehl, sondern auch an den Befehl git selbst übergeben. Und wenn ihr jetzt denkt: „Ich wusste nicht, dass der Git-Befehl Optionen hat“, seid ihr wahrscheinlich nicht allein.

Ein nützliches und leicht verständliches Beispiel ist die Option zur Steuerung der Seitennummerierung. Standardmäßig leitet Git jede Ausgabe, die länger als ein Bildschirm ist, an less (oder einen anderen konfigurierten Pager) weiter. Kürzere Ausgaben werden direkt angezeigt. Bei Bedarf können wir dieses Verhalten jedoch überschreiben, zum Beispiel:

Sehen wir uns an, wie sich das in einem Alias nutzen lässt. Zum Beispiel:

Eine weitere gute Anwendung dieses Features ist die Kombination mit Gits Möglichkeit, Konfigurationseinstellungen temporär zu überschreiben.

In Git könnt ihr mit der Option -c einen Konfigurationswert nur für diesen einzelnen Befehl überschreiben, i.e., git -c <config override> <subcommand>.

Das lässt sich auch als Alias verwenden:

Hinweis: Dies unterscheidet sich von der Verwendung von git commit --author=, da dabei sowohl die Identität des Autors als auch die des Committers festgelegt wird, wie im folgenden Beispiel zu sehen:

Wie geht es in der Git-Blogserie weiter?

Ich habe euch etwas mehr als nur die Grundlagen von Git-Aliasen gezeigt. Wir haben gesehen, wie hilfreich sie im Arbeitsalltag sein können – bei Befehlen, die wir häufig nutzen, oder bei Befehlen, die wir so selten verwenden, dass wir sie uns nicht merken können. Außerdem haben wir den Rahmen normaler Git-Aliase etwas gesprengt und mit Optionen für Git selbst experimentiert – ein Feature, das die meisten Nutzer ebenfalls nicht kennen.

Das ist ein guter Zeitpunkt, euch in Erwartung von Teil zwei zurückzulassen, in dem wir weitermachen mit:

1. !Nicht-Git-Befehle: Mehr „Bang“ fürs Geld.

2. Aliase wiederverwenden.

3. Die Aktion in eine Pipeline bringen: Unix-Tools für mehr Power oder Verrücktheit verketten.

4. Bash-Funktionen für den Erfolg.

5. Übertreiben, denn Grenzen findet man nur, indem man sie überschreitet.

6. Bonusrunde: Alternativen zu Git-Aliasen erkunden.

Weiter zu Teil zwei!