Das Erstellen von Aliassen in Git ist eine leistungsstarke Funktion, mit der ihr „Kurzbefehle“ für längere Git-Befehle (und mehr) definieren könnt. Für manche ist sie nur ein Mittel, um die Nutzung von Git über die Kommandozeile erträglich zu machen. Ich zeige euch jedoch, dass Git-Aliasse so leistungsstark sind, dass sie dazu beitragen können, die Kommandozeile zur bevorzugten und effizientesten Methode für die Nutzung von Git zu machen.
Jan Krag
Jan has been with us since 2014 as a Continuous Improvement Agent. He is an accredited trainer for Docker and Github and is also a certified life coach. Jan has a truly diverse range of interests. He breeds oriental cats, builds and flies his own kites, collects Rubik’s cubes, and enjoys snowboarding. Wow!
Wusstet ihr, dass sich Git auf vielfältige Weise an eure Bedürfnisse anpassen lässt?
Die wichtigsten Gründe für das Erstellen von Git-Aliasen können einer oder mehrere der folgenden sein:
Optimieren: Erstellt Shortcuts für häufig verwendete Git-Befehle.
Anpassen: Lasst Git so arbeiten, wie ihr es möchtet, oder unterstützt im Team vereinbarte Vorgehensweisen.
Merken: Leicht zu merkende Shortcuts für komplexe Vorgänge.
Im ersten Teil meiner Blogserie nehme ich euch mit auf eine Reise von den ganz grundlegenden Basics – mit Git-Aliasen, die euch lediglich das Tippen längerer Befehle 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 widmet sich wirklich ausgefallenen Einsatzmöglichkeiten von Git-Aliasen – einschließlich einiger geradezu verrückter Beispiele –, bevor er Alternativen zur Lösung derselben Anforderungen behandelt.
Wenn ihr diese Techniken lernt und versteht – egal, ob ihr Aliasen anderer übernehmt oder selbst die Grenzen auslotet –, werdet ihr Git effizienter und souveräner nutzen und hoffentlich mehr Freude an eurem Arbeitsalltag mit Git haben. Nebenbei lernt ihr wahrscheinlich auch einige Tipps und Tricks kennen und entdeckt Bereiche von Git, deren Existenz euch bisher vielleicht gar nicht bewusst war.
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 es euch ganz einfach, eigene Git-Befehle zu definieren, die genau das tun, was ihr möchtet, und sich nahtlos neben den integrierten Befehlen verwenden lassen.
Aliase werden in der Git-Konfigurationshierarchie definiert. Da sie in der Regel überall auf eurem 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 uns das an:
Für komplexere Aliase später auf eurer Reise empfehle ich euch, ~/.gitconfig einfach in eurem bevorzugten Editor zu öffnen und eure Aliase dort direkt hinzuzufügen oder zu ändern.
Level 1: Der faule Tipper
Okay, beginnen wir mit dem ersten Level. Ich bin faul und möchte einfach das Tippen von Befehlen optimieren, die ich hunderte Male am Tag verwende, oder häufige Tippfehler abfangen, die mir oft passieren.
Den Vorschlag st haben wir oben bereits gesehen, aber hier sind noch ein paar weitere häufige Beispiele für einfache Shortcuts:
Aliase im Stil von „häufigen Tippfehlern“ sind eine persönliche Vorliebe. Erstellt Aliase für die Befehle, die eure Finger einfach nicht richtig tippen können. Mein persönlicher Erzfeind ist switch, aber ich habe mich entschieden, immer das oben vorgeschlagene kurze „sw“ zu verwenden, anstatt Aliase für alle möglichen Tippfehler zu erstellen, die ich bei diesem einen Wort machen kann. Hier sind dennoch ein paar Beispiele zur Inspiration:
Vielleicht überlegt ihr an diesem Punkt bereits, welche Git-Befehle sich am besten für Aliase eignen. Vor Jahren bin ich auf eine interessante Antwort gekommen. Genau 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 gute Kandidaten sein, um sie mit bereits erstellten Aliasen zu „verkürzen“ oder euch besser zu merken. Der einzige Grund, warum ich trotz meines Alias git st so häufig „git status“ verwende, ist, dass ich viele Git-Schulungen durchführe und mich dabei verpflichte, die tatsächlichen Befehle zu verwenden.
Level 2: Einfache Optionen, um tägliches Tippen von Options-Flags zu vermeiden
Jetzt ist es an der Zeit, die Lautstärke der Git-Aliase eine Stufe höher zu drehen. Mit Aliasen können wir den Git-Befehlen, für die wir Aliase erstellen, auch „Optionen“ hinzufügen. Sehen 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 Vorschlag ist, diese Funktion zu nutzen, um jene lästigen „fehlenden“ Git-Befehle zu erstellen, die deiner Meinung nach hätten existieren sollen und bei denen du dir möglicherweise nur schwer merken kannst, welchen genauen Befehl und welche Option du für diese sehr häufige Aufgabe verwenden musst.
Zugegeben: Viele Git-Nutzer haben vielleicht 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 genutzte Befehle zu behalten
Die nächste Etappe unserer Reise besteht darin, Aliase für Befehle zu untersuchen, die auch komplexe Argumente annehmen.
Bisher haben wir uns hauptsächlich 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 sinnvoll sein, den umgekehrten Weg zu gehen und Aliase zu verwenden für:
Selten verwendete schwer zu merkende Git-Aufgaben.
Schwer zu tippende Befehle einfacher handhabbar machen.
So kannst du praktische Git-Funktionen nutzen, um die du dich sonst vielleicht gar nicht bemühen würdest.
Wie du sehen kannst, habe ich die Aliase in den obigen Beispielen „inline“ beschrieben, indem ich die Möglichkeit genutzt habe, # Kommentare in deiner Konfigurationsdatei hinzuzufügen. Das dient nicht nur dazu, das Beispiel verständlicher zu machen, sondern soll dir ausdrücklich nahelegen, dies auch in deiner tatsächlichen Konfiguration zu tun. Es hat viel zu viele Jahre gedauert, bis ich das auf die harte Tour gelernt habe. Heute habe ich zahlreiche seltsame Aliase und andere Einstellungen gesammelt, deren Zweck ich nicht mehr genau kenne.
Schauen wir uns ein paar weitere konkrete und häufig verwendete Beispiele aus meiner Sammlung an. Dieses Mal zeige ich dir auch tatsächlich die Ergebnisse. Ich zeige dir einen nützlichen Diff-Alias, aber zuerst die „Vorher“-Ansicht mit git diff für eine Markdown-Datei.
Fügen wir nun einen Alias hinzu:
Und verwenden stattdessen diesen:
Das ist offensichtlich viel übersichtlicher und leichter zu erfassen. Nicht der Alias selbst bewirkt die Magie – es handelt sich um integrierte Git-Funktionen. Aber der Alias macht sie für meinen Alltag nützlich, weil ich mir nicht jedes Mal die Mühe machen möchte, Folgendes einzutippen: git diff -w --word-diff=color --ignore-space-at-eol.
Definieren wir:
Der gezeigte Ausschnitt umfasst einen Bereich von mehr als 3.000 Commits im Tensorflow-Repository, indem er nur die „markierten“ Commits anzeigt (Tags oder Branch-Heads).
Zum Abschluss dieses Levels und als gute Überleitung zum nächsten schauen wir uns wohl die vorteilhafteste Verwendung von Aliasen mit komplexen Argumenten an: die Möglichkeit, noch stärker angepasste git log-Befehle zu erstellen, die durch benutzerdefinierte Formate deinen Vorlieben entsprechen. Ich möchte daraus kein Tutorial zu den eigentlichen Formatierungsoptionen machen, also legen wir einfach direkt los – du wirst schnell verstehen, worum es geht. All das ist im Abschnitt Pretty formats von git help log ausführlich dokumentiert.
Ich präsentiere: meinen täglichen Begleiter:
Level 4: Pretty formats – Aliase durch Wiederverwendbarkeit aufräumen
Für dieses Level verlassen wir den unmittelbaren Bereich der Git-Aliase. Ich zeige dir, wie du die wenig bekannte Funktion benutzerdefinierter Pretty-Formate nutzen kannst, um deine Aliase aufzuräumen und die Wiederverwendbarkeit deutlich zu verbessern.
(Die tatsächlichen Aliase waren viel länger, verwendeten aber alle denselben Format-String.)
Und viele ähnliche. Das machte es wirklich lästig, jedes Mal das Format, die Farbgebung usw. anzupassen.
In neueren Git-Versionen können sich Aliase mittlerweile auf andere Aliase beziehen. Dadurch lässt sich das Obige erheblich verbessern, zum Beispiel:
Es stellt sich jedoch heraus, dass es eine bessere Möglichkeit gibt.
(Weitere Informationen findest du 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 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 beim Ausführen eines Git-Log-Befehls verwenden:
Das bedeutet auch, dass ich all meine seltsamen Log-Aliase so umschreiben kann, dass sie mein eigenes Pretty-Format verwenden. Dann habe ich eine zentrale Stelle, an der ich Änderungen vornehmen kann, 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.
Level 5: Präfixe – Git-Verhalten für bestimmte Git-Subcommands überschreiben
Zum Abschluss dieses ersten Blogbeitrags werfen wir in Level 5 einen Blick auf eine wenig bekannte Funktion in Git-Aliases, die eine ebenfalls eher unbekannte Funktion nutzt.
Wie sich herausstellt, können Git-Aliase Optionen nicht nur an das Git-Subcommand, sondern auch an den git-Befehl selbst übergeben. Und wenn ihr jetzt denkt: „Ich wusste nicht, dass der Git-Befehl Optionen hat“, seid ihr damit wahrscheinlich nicht allein.
Ein nützliches und leicht erklärbares Beispiel ist die Option zur Steuerung der Seitennummerierung. Standardmäßig leitet Git jede Ausgabe, die mehr als einen Bildschirm füllt, an less (oder einen anderen konfigurierten Pager) weiter. Eine Ausgabe, die weniger als einen Bildschirm füllt, wird direkt angezeigt. Git erlaubt uns jedoch, dieses Verhalten bei Bedarf zu überschreiben, zum Beispiel:
Schauen wir uns an, wie sich das in einem Alias nutzen lässt. Zum Beispiel:
Eine weitere sinnvolle Verwendung dieser Funktion ist die Kombination mit Gits Möglichkeit, Konfigurationseinstellungen vorübergehend zu überschreiben.
In Git könnt ihr die Option -c verwenden, um einen Konfigurationswert nur für diesen einzelnen Befehl zu überschreiben, d. h. 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 ist:
Wie geht es in der Git-Blogserie weiter?
Ich habe euch mehr als nur die Grundlagen von Git-Aliases gezeigt. Wir haben gesehen, wie hilfreich sie im Arbeitsalltag sein können – bei Befehlen, die wir häufig verwenden, oder bei solchen, die wir so selten nutzen, dass wir uns nicht daran erinnern können. Außerdem haben wir mit Optionen für Git selbst ein wenig über normale Git-Aliase hinaus experimentiert – eine Funktion, die die meisten Nutzer bereits nicht kennen.
Das ist ein guter Zeitpunkt, euch bis zum zweiten Teil neugierig zu machen, in dem es weitergeht mit:
!Nicht-Git-Befehlen: Mehr „Bang“ fürs Geld.
Aliase wiederverwenden.
Die Aktion in eine Pipeline bringen: Unix-Tools verketten für mehr Action oder Verrücktheit.
Bash-Funktionen für den Erfolg.
Über die Stränge schlagen, denn Grenzen findet man nur, indem man sie überschreitet.
Bonusrunde: Alternativen zu Git-Aliases erkunden.
Weiter zu Teil zwei!
- DevOps
- CI/CD
Subscribe to our newsletter
Related blogs
