How to Git Good?

Als Software-Entwickler kommt man heutzutage nur schwer an Git vorbei und auch als IT-Berater, Designer etc. hat man es öfter mit Git zu tun. Git ist ein geniales und vielseitiges Tool, aber schwierig zu bedienen. Dieser Artikel ist der erste in hoffentlich einer ganzen Reihe, in der ich meine Tipps für die “korrekte” Nutzung von Git gebe.
Aus der Dokumentation erfährt man:
Git is a fast, scalable, distributed revision control system with an
unusually rich command set that provides both high-level operations
and full access to internals.
Git ist ein schnelles, skalierbares, verteiltes Versionskontrollsystem mit einem
ungewöhnlich reichhaltigen Befehlssatz, der sowohl High-Level-Operationen als
auch vollen Zugriff auf die Interna bietet.
Von einfacher Bedienung steht dort leider nichts. Git ist berüchtigt dafür sehr kompliziert zu sein. Zumindest, wenn man ins Detail gehen möchte!
Konsole vs. GUI
Wie in vielen anderen Lebensbereichen lernt man am meisten, wenn man die Stützräder abschraubt. Ähnlich ist es auch bei Git. Wenn man ambitionierter Software-Entwickler ist und tiefer in Git und das Thema Version Control eintauchen möchte ist es meiner Meinung nach unumgänglich, dass man Git in der Konsole verwendet. Ob es nun bash, zsh oder die PowerShell ist, ist dabei nicht so wichtig. Hauptsache ist, dass man die Befehle selbst eintippen muss!
Die meisten Code-Editoren, darunter auch IntelliJ, VSCodium und Eclipse, bringen mittlerweile integrierte Git-GUIs mit sich mit denen man gängige Vorgänge ganz leicht per Knopfdruck durchführen kann. Darunter meistens:
- Den aktuellen Zustand betrachten
- Änderungen zum Commit vormerken
- Einen Commit erstellen oder bearbeiten
- Änderungen zum Remote Repository pushen
- Änderungen von außen synchronisieren
Die bequeme Bedienung hat aber schlechte Nebeneffekte, die dafür sorgen, dass man sich nie zu 100 Prozent mit Git anfreunden kann.
1. Man ist auf eine bestimmte GUI angewiesen
Sowohl eigenständige Git-GUIs wie GitHub Desktop, SourceTree, TortoiseGit als auch integrierte GUIs bieten komfortable User-Interfaces. Das Problem ist nur, dass sie das nicht alle auf die selbe Art und Weise tun. Hat man sich an eine GUI gewöhnt und kann gut mit ihr arbeiten, dann kommt man noch längst nicht mit allen weiteren klar.
Das kann einem dann zum Verhängnis werden, wenn man in ein Team kommt, dass einen anderen Code-Editor verwendet oder nicht bestimmte GUIs erlaubt. Ich selbst arbeite aktuell in VSCode und leider ein Managed-Device auf dem ich nicht nach Belieben GUIs installieren kann. Zum Glück habe ich mich schon lange mit der Konsole angefreundet und die ist auf wirklich jedem Gerät (und jedem Code-Editor) vorhanden.
2. Man ist langsamer
Diesen Punkt mag der ein oder andere in Frage stellen. Besonders wenn man gerade von einer GUI auf die Konsole gewechselt hat, dann kommt es einem vielleicht vor, als sei man im Schneckentempo unterwegs. Allerdings ist das nur von kurzer Dauer. Wenn man Aliase nutzt und die anfängliche Lernphase übersteht, dann kann man komplexe Vorgänge wie Rebase oder eine Suche mit git blame und git grep in Sekundenbruchteilen durchführen ohne seine Hand zur Maus bewegt haben zu müssen.
3. Man bleibt auf der Oberfläche gefangen
Für Software-Entwickler meiner Meinung nach der wichtigste Punkt. Eine selbstbewusste Nutzung von Git ist unglaublich hilfreich bei der Umsetzung vieler Ideale der Softwareentwicklung. Continuous Integration und Test Driven Development zum Beispiel.
Ein interaktiver Rebase ist ein super Tool, um seine Commits aufzuräumen, umzubenennen, umzusortieren und sicherzustellen, dass die einzelnen Commits bauen. Ist aber mit den meisten GUIs nur sehr umständlich machbar.
Ein tiefgründigeres Verständnis für die Interna von Git gibt einem die Sicherheit, die man braucht, um auch schwierigere Befehle wie git bisect zu nutzen ohne Angst zu haben, dass man verloren ist, wenn zwischendurch etwas schief geht oder Konflikte auftauchen. Wenn man einen Branch aber immer nur per Klick auscheckt oder sich den Log immer nur in der GUI anzeigen lässt bleiben einem viele Details verborgen, die die Tools git branch, git log und alle weiteren für einen bereit halten.
Git Befehle
Die meisten Git-Befehle in der folgenden Liste benutze ich regelmäßig.
Basic
git init;
git clone;
git version;
git status;
git diff;
git log;
git add;
git commit;
git tag;
git push;
git pull;
git fetch;
git merge;
git rebase;
git checkout;
git branch;
git stash;
git config;
git reset;
git restore;
git remote;
git revert;
Diese Liste ist etwas exotischer, enthält aber wahre Juwelen!
Exotisch
git blame;
git submodule;
git cherry-pick;
git reflog;
git rerere;
git bisect;
git grep;
Ich hoffe, dass ich auf die meisten dieser Befehle noch eingehen kann. Bonuspunkte, falls man git rerere kannte!
In der Konsole loslegen
Auf den vielen Systemen ist Git bereits installiert. Zum Test öffnet man eine Konsole und tippt
git version
der Output sollte in etwa so aussehen: git version 2.xy.z
Wenn das nicht geklappt hat, dann einmal hier abbiegen: Git Installation
Wenn nun eine Version angezeigt wird, dann sind wir bereit, um mit Git zu starten. Wir müssen noch drei Einträge in unserer Konfiguration hinzufügen, um wirklich startklar zu sein. Unseren Namen, unsere Email-Adresse und unseren Lieblings-Texteditor.
Name und Email sind verpflichtend und werden genutzt, um den Autor den Commits festzulegen. Die Option --global sagt, dass dies in jedem Repository gelten soll, wenn nichts anderes angegeben ist.
git config --global user.name "Dein Name"
git config --global user.email "mail@adresse.de"
Git braucht oft, zum Beispiel bei der Benennung von Commits, Input vom Nutzer. Standardmäßig wird nano , manchmal aber auch vim verwendet.
Ich würde Leuten, die in der Konsole noch unsicher sind von vim abraten (auch wenn Vim ein sehr cooler Editor ist), sondern lieber nano explizit einzutragen. Wer lieber einen graphischen Text Editor möchte nimmt unter Linux gedit und unter Windows notepad .
git config --global core.editor "nano"
Das war’s!