Ein durchsuchbarer Git-Spickzettel mit Einrichtung, dem täglichen Commit-Kreislauf, Branching, Remotes, Verlauf und Wiederherstellung, mit Ein-Klick-Kopieren für jeden Befehl.
Neunundvierzig Git-Befehle, die sich zu merken lohnen. Filtern Sie nach Befehlsnamen und Beschreibungen und kopieren Sie dann den gewünschten. Gruppiert nach Einrichtung, täglichem Workflow, Branching, Remotes, Verlauf und dem Rückgängigmachen von Fehlern.
Kein Befehl entspricht diesem Filter.
Git hat gut über hundert Porzellan-Befehle, aber die meisten Entwickler verwenden jeden Tag dieselben zwanzig oder dreißig und greifen den Rest nur ein paar Mal im Jahr. Ein Spickzettel ersetzt kein Verständnis des Modells; er sorgt dafür, dass die Befehle, die Sie bereits verstehen, nur einen Tastendruck entfernt bleiben – statt einem Browser-Tab und drei Stack-Overflow-Antworten.
Die Referenz auf dieser Seite ist so gruppiert, wie die Arbeit tatsächlich abläuft: Einrichten eines Repositorys, der Commit-Kreislauf, den Sie dutzende Male am Tag ausführen, Branching, die Kommunikation mit einem Remote, das Lesen des Verlaufs und das Wiederherstellen nach Fehlern. Geben Sie etwas in das Filterfeld ein und die Liste verengt sich über Befehlstext und Beschreibung, sodass die Suche nach "stash", "force" oder "undo" sofort die passenden Zeilen zeigt. Jede Zeile hat einen Kopier-Button, denn einen Befehl wie --force-with-lease neu zu tippen ist genau der Weg, wie Tippfehler entstehen.
Fast jeder Git-Befehl ergibt Sinn, sobald Sie drei Orte im Kopf haben. Der Working Tree sind die Dateien auf der Festplatte, wie Sie sie im Editor sehen. Der Index – auch Staging-Bereich genannt – ist der Snapshot, den Sie für den nächsten Commit zusammenstellen. Das Repository ist die unveränderliche Kette bereits aufgezeichneter Commits. git add verschiebt Inhalte aus dem Working Tree in den Index, git commit verwandelt den Index in einen neuen Commit, und git restore schiebt Inhalte auf dem Rückweg zurück.
Branches sind die zweite Idee, und sie sind einfacher, als sie wirken: Ein Branch ist nur ein beweglicher Zeiger auf einen Commit, und HEAD ist ein Zeiger auf den Branch, auf dem Sie sich befinden. Einen Branch zu erstellen kostet nichts, da er eine einzelne Datei mit einem vierzig Zeichen langen Hash schreibt. Deshalb ist git switch -c günstig genug für ein Fünf-Minuten-Experiment.
Mergen und Rebasen kombinieren beide Arbeit aus zwei Branches; sie unterscheiden sich darin, was sie aufzeichnen. Ein Merge behält beide Historien und fügt einen Commit hinzu, der sie verbindet – das ist ehrlich, erzeugt aber einen geflochtenen Graphen. Ein Rebase schreibt Ihre Commits um, sodass sie so erscheinen, als wären sie auf dem anderen Branch geschrieben worden, was eine saubere gerade Linie ergibt, aber die Commit-Hashes ändert – weshalb Sie niemals Commits rebasen, die andere bereits gepullt haben.
Das nützlichste, was man über Git wissen sollte, ist, dass es committete Arbeit sehr selten verliert. Solange eine Änderung irgendwann committet wurde, zeigt git reflog den Hash, und git switch -c rescue <hash> holt sie zurück. Dieses Sicherheitsnetz deckt misslungene Rebases, versehentliches reset --hard nach einem Commit und zu eifrig gelöschte Branches ab.
Die gefährlichen Operationen sind diejenigen, die uncommittete Arbeit berühren: git reset --hard, git checkout -- auf einer geänderten Datei und git clean -fd. Keine dieser Änderungen wurde jemals aufgezeichnet, also gibt es nichts, worauf der Reflog zeigen könnte. Der sich lohnende Habit ist, früh und oft auf einem Scratch-Branch zu committen, oder git stash push vor jedem Experiment auszuführen. Ein Commit, den Sie später wegsquashen, kostet nichts; ein Nachmittag uncommitteter Arbeit kommt nicht zurück.
Bei gemeinsamen Branches bevorzugen Sie git revert vor dem Umschreiben der Historie. Es zeichnet einen neuen Commit auf, der den alten umkehrt, sodass der Klon von jedem anderen gültig bleibt. Reservieren Sie --force-with-lease für Ihre eigenen Feature-Branches und beachten Sie, dass es spürbar sicherer ist als einfaches --force: Es verweigert die Ausführung, wenn sich das Remote seit dem letzten Fetch bewegt hat – genau der Fall, in dem ein einfacher Force-Push stillschweigend die Commits eines Kollegen zerstören würde.