Git-Befehls-Generator — Hören Sie auf, täglich nach denselben Befehlen zu suchen

Ich hatte früher einen Browser-Tab permanent zur git-Dokumentation geöffnet. Nicht weil ich git nicht kannte, ich hatte es jahrelang genutzt, sondern weil ich die genaue Syntax für Dinge, die ich nur gelegentlich tat, immer wieder vergaß. War es git reset --soft oder git reset --cached, wenn ich die Stagingrücknahme ohne Verlust von Änderungen wollte? Löschte git stash apply den Stash oder beließ es ihn? War das Flag für das Setzen des Upstream -u oder --set-upstream?

Jeder Entwickler, den ich kenne, hat eine Version dieser Erfahrung. Git ist eines jener Tools, bei denen die täglichen Befehle innerhalb weniger Wochen reflexartig werden, aber die mittelhäufigen Befehle, die man alle paar Tage oder einmal pro Woche verwendet, nie wirklich haften bleiben. Man lernt sie, vergisst sie, lernt sie wieder, vergisst sie wieder.

Der Git-Befehls-Generator auf ToolBox Hub existiert genau für diese Momente. Anstatt zu Dokumentation zu wechseln, können Sie nach Kategorie filtern, nach dem suchen, was Sie zu tun versuchen, einen Branch-Namen oder Commit-Hash eingeben und den vollständigen Befehl kopieren. Kein Suchen, kein Debuggen falscher Flags.

Wie das Tool funktioniert

Wenn Sie den Git-Befehls-Generator öffnen, sehen Sie eine Suchleiste und eine Reihe von Kategorie-Schaltflächen: Basic, Branching, Remote, Undo, Stash und Advanced.

Die Befehlskarten zeigen jeweils den Befehl in einem Monospace-Code-Block, eine klare Beschreibung dessen, was er tut, und eine Kopieren-Schaltfläche. Für Befehle, die einen Parameter benötigen, einen Branch-Namen, einen Dateipfad, einen Commit-Hash, gibt es ein Texteingabefeld unterhalb der Karte. Was auch immer Sie eingeben, wird in Echtzeit in die Befehlsvorlage eingefügt, sodass die Kopierschaltfläche immer die sofort ausführbare Version kopiert.

Wenn Sie zum Beispiel auf die Karte "Neuen Branch erstellen und wechseln" klicken und feature/payments in das Branch-Name-Feld eingeben, aktualisiert sich der Befehlsblock sofort auf git checkout -b feature/payments, und das ist es, was in Ihre Zwischenablage kopiert wird.

Die Suchleiste filtert über Befehlsnamen und Beschreibungen, sodass Sie "undo" eingeben und alle relevanten Befehle sehen können, oder "stash" eingeben und den vollständigen Stash-Workflow zusammen sehen.

Die Befehle, die Sie tatsächlich verwenden werden

Anstatt alle 40+ Befehle alphabetisch durchzugehen, werde ich die Kategorien so durchgehen, wie sie an einem echten Arbeitstag auftauchen.

Einrichtung und tägliche Grundlagen

Die Befehle in der Basic-Kategorie sind die, bei denen das Muskelgedächtnis innerhalb Ihres ersten Monats übernimmt. git status ist wahrscheinlich der meistausgeführte git-Befehl, er sagt Ihnen, was staged ist, was nicht und was nicht verfolgt wird. git add . staged alles im aktuellen Verzeichnis. git commit -m "Nachricht" erstellt einen Commit.

Die zwei, die ich in dieser Kategorie bei Entwicklern untergenutzt sehe, sind git diff und git diff --staged. git diff vor dem Hinzufügen von etwas zeigt Ihnen genau, was sich in Ihrem Working Tree seit dem letzten Commit geändert hat. git diff --staged nach dem Hinzufügen zeigt, was tatsächlich in Ihren nächsten Commit eingeht. Die Gewohnheit zu entwickeln, diese vor jedem Commit zu überprüfen, deckt eine überraschende Anzahl von Debug-Logs, auskommentierte Code-Blöcke und versehentliche Dateieinschlüsse auf.

git log --oneline ist ein weiteres unterschätztes tägliches Tool. Die Standard-git log-Ausgabe ist zu ausführlich, um sie zu überfliegen. Die --oneline-Version komprimiert jeden Commit auf eine einzelne Zeile: die ersten 7 Zeichen des Hashes und den Commit-Betreff. Viel schneller, um den Commit zu finden, nach dem Sie suchen.

Branching-Strategie

Die Branching-Kategorie deckt alles von der Erstellung von Branches bis zum Mergen und Taggen ab.

git checkout -b <branch> (oder das neuere git switch -c <branch>) ist der Start der meisten Feature-Arbeit. Sie benennen ihn, wechseln zu ihm, bauen. Wenn die Arbeit erledigt ist, öffnen Sie einen Pull Request oder mergen ihn zurück. Standardflow.

Die Befehle, bei denen die Leute verwirrt werden, sind git merge versus git rebase. Beide integrieren Änderungen von einem Branch in einen anderen, aber auf unterschiedliche Weise.

git merge erstellt einen Merge-Commit. Ihre Branch-Historie und die Ziel-Branch-Historie werden beide beibehalten, und der Merge-Commit zeigt, wo sie sich verbunden haben. In einem git-Graphen erstellen Merge-Commits eine Rautenform. Das ist treu zu dem, was tatsächlich passiert ist, zwei parallele Arbeitsströme haben sich zusammengefunden, und es ist der sichere Standard für Team-Workflows.

git rebase nimmt Ihre Commits, spult den Branch-Zeiger auf die Spitze des Ziel-Branches zurück und spielt Ihre Commits darüber ab. Das Ergebnis ist eine gerade Commit-Linie ohne Merge-Rauten. Der Vorteil ist Lesbarkeit, git log ist einfacher zu folgen. Der Nachteil ist, dass Rebase Commit-Hashes neu schreibt, was Probleme verursacht, wenn jemand anderes diese Commits bereits gezogen hat. Die Regel: Rebase auf persönlichen oder lokalen Branches, Merge auf geteilten.

git branch -d <branch> löscht einen lokalen Branch nach dem Mergen. Git ist hier konservativ und weigert sich, wenn der Branch nicht gemergete Commits hat. Wenn Sie einen nicht gemergeten Branch wirklich verwerfen möchten, verwenden Sie -D (Großbuchstabe). Der Generator enthält speziell -d, weil es die sichere Version ist.

Mit Remotes arbeiten

Die Remote-Kategorie deckt die Befehle ab, die den Server berühren.

git fetch origin unterscheidet sich subtil von git pull. Fetch lädt nur neue Commits und Branches vom Remote herunter, berührt Ihre lokalen Branches überhaupt nicht. Pull ist ein Fetch, gefolgt von einem Merge. Ich ziehe es vor, zuerst zu fetchen und zu sehen, was sich geändert hat, bevor ich merge, besonders auf aktiven geteilten Branches. Es ist eine kleine Gewohnheit, die mich mehr als einmal vor unerwarteten Konflikten gerettet hat.

git push -u origin <branch> ist der erste Push für einen neuen Branch. Das -u-Flag setzt die Upstream-Tracking-Beziehung, sodass danach git push und git pull ohne Argumente automatisch auf diesem Branch funktionieren. Wenn Sie beim ersten Push -u weglassen, werden nachfolgende git push-Aufrufe sich beschweren, dass kein Upstream konfiguriert ist.

git remote -v ist der "Was ist mein Setup"-Befehl. In jedem unbekannten Repository sagt Ihnen dies sofort, wohin Fetches und Pushes gehen. Es ist überraschend, wie oft das einen Remote an einem unerwarteten Ort aufdeckt.

git cherry-pick <hash> verdient eine Erwähnung. Es kopiert einen einzelnen Commit von überall in der Historie auf Ihren aktuellen Branch. Der klassische Anwendungsfall: Ein Hotfix wurde auf main gemergt, aber Sie arbeiten an einem lang laufenden Feature-Branch, der diesen Fix ebenfalls benötigt. Cherry-picken Sie den Commit-Hash und er landet auf Ihrem Branch ohne den Rest der Änderungen von main.

Fehler rückgängig machen

Das ist die Kategorie, nach der die Leute am dringlichsten suchen. Etwas ist schief gelaufen und Sie müssen es rückgängig machen, ohne die Dinge schlimmer zu machen.

git reset --soft HEAD~1 ist das sanfteste Rückgängigmachen. Es bewegt den Branch-Zeiger einen Commit zurück, lässt aber alle Änderungen staged und bereit für einen erneuten Commit. Verwenden Sie es, wenn Sie zu früh committed haben und mehr Änderungen hinzufügen oder die Nachricht umschreiben möchten.

git reset HEAD~1 (Standard-"mixed"-Modus) bewegt den Zeiger zurück und unstaged die Änderungen, lässt sie aber in Ihrem Working Tree. Verwenden Sie es, wenn Sie überprüfen möchten, was Sie geändert haben, bevor Sie es erneut stagen.

git reset --hard HEAD~1 ist die Atom-Option. Es bewegt den Zeiger zurück und verwirft die Änderungen vollständig. Es gibt kein eingebautes Rückgängigmachen dafür, die Änderungen sind aus dem Working Tree verschwunden. Verwenden Sie es nur, wenn Sie sicher sind, dass Sie diese Änderungen nicht benötigen.

git revert <hash> ist das richtige Tool, wenn der Commit, den Sie rückgängig machen möchten, bereits gepusht wurde. Revert erstellt einen neuen Commit, der das Inverse der ursprünglichen Änderungen anwendet. Die Historie wird beibehalten. Ihre Teammitglieder, die gepullt haben, werden nicht gestört.

git restore <datei> verwirft Working-Tree-Änderungen an einer bestimmten Datei. git restore --staged <datei> unstaged eine Datei, ohne den Working Tree zu berühren. Diese Befehle wurden in Git 2.23 als sauberere Alternativen zu dem überladenen git checkout und git reset hinzugefügt.

Laufende Arbeit stashen

Stash ist die Notausgangstür für "Ich muss jetzt den Kontext wechseln, bin aber noch nicht bereit zu committen."

git stash speichert Ihre uncommittierten Änderungen (sowohl staged als auch unstaged) auf einem Stack und setzt Ihren Working Tree auf den letzten Commit zurück. Sie können nun Branches wechseln, Änderungen pullen, einen Bug fixen, was auch immer Sie brauchen. Wenn Sie zurückkommen, stellt git stash pop Ihre Änderungen wieder her.

git stash push -m "beschreibende Nachricht" lohnt sich über dem bloßen git stash zu verwenden, sobald Sie mehr als einen Stash-Eintrag haben. Die Nachricht macht es viel einfacher, Einträge zu identifizieren, wenn Sie später git stash list ausführen. Ein Stash-Eintrag namens WIP: Auth-Middleware refaktorieren ist viel nützlicher als stash@{2}.

git stash apply stash@{1} wendet einen bestimmten Eintrag an, ohne ihn aus der Liste zu entfernen. Nützlich, wenn Sie denselben Stash auf mehrere Branches anwenden möchten.

Erweiterte und seltenere Befehle

Die Advanced-Kategorie deckt Befehle ab, die gelegentlich auftreten, aber schwer zu merken sind.

git log --oneline --graph --all ist ein Favorit, den ich empfehle, dass jeder ihn regelmäßig auf seinen Repositories ausführt. Der ASCII-Branch-Graph gibt Ihnen ein visuelles Bild davon, wie Ihre Branches zusammenhängen, welche divergiert sind, wo Merges stattfanden, wo Tags sind.

git bisect start beginnt eine binäre Suche, um herauszufinden, welcher Commit einen Bug eingeführt hat. Sie markieren einen bekannten-guten Commit mit git bisect good <hash> und einen bekannten-schlechten Commit mit git bisect bad <hash>, und git checkt den Mittelpunkt-Commit zum Testen aus. Für Bugs, die ohne Ausführen des Codes schwer zu reproduzieren sind, ist bisect unschätzbar wertvoll.

git blame <datei> zeigt, wer jede Zeile einer Datei zuletzt geändert hat und in welchem Commit. Der Name klingt anklagend, in der Praxis wird es normalerweise verwendet, um zu verstehen, warum eine Codezeile so ist, wie sie ist, indem man den Commit nachschlägt.

git reflog ist der Rettungsbefehl. Selbst nach einem harten Reset bewahrt git ein internes Protokoll über alle Orte, an denen HEAD war. Wenn Sie versehentlich Commits zerstört haben, die Sie brauchten, zeigt git reflog Ihnen den Hash, den Sie benötigen, um sie mit git reset --hard <wiederhergestellter-hash> wiederherzustellen.

Profi-Tipps für einen reibungsloseren Git-Workflow

Einige Gewohnheiten, die einen wesentlichen Unterschied machen:

Schreiben Sie Commit-Nachrichten im Imperativ. "Authentifizierungs-Middleware hinzufügen" statt "Authentifizierungs-Middleware hinzugefügt." Die Konvention existiert, weil gits eigene generierte Nachrichten (Merge-Commits, Reverts) den Imperativ verwenden, sodass Ihre Nachrichten natürlich integriert werden.

Klein und häufig committen. Atomare Commits, eine logische Änderung pro Commit, machen git log lesbar, machen Code-Reviews einfacher und machen git bisect effektiv. Einmal täglich mit einer riesigen "Fortschritt"-Nachricht zu committen, macht den Großteil des Werts von git zunichte.

.gitignore aggressiv verwenden. Build-Artefakte, IDE-Metadaten, Umgebungsdateien, diese sollten niemals in Ihrem Repository erscheinen. Wenn git status mit Dateien überladen ist, die Sie nie committen werden, korrigieren Sie Ihre .gitignore.

Das --patch-Flag erlernen. git add --patch (oder git add -p) ermöglicht es Ihnen, interaktiv auszuwählen, welche Hunks einer Datei gestaged werden sollen. Wenn eine Datei Änderungen für zwei verschiedene Zwecke hat, können Sie sie in separate Commits aufteilen.

Tools, die man mit diesem kombinieren kann

Cron-Parser — CI/CD-Pipelines haben oft geplante Jobs neben ereignisgesteuerten. Wenn Ihre Deployment-Pipeline einen Cron-Zeitplan enthält und Sie einen Cron-Ausdruck dekodieren oder erstellen müssen, bewältigt dieses Tool das sofort.

URL-Encoder — Git-Remote-URLs enthalten gelegentlich Zeichen, die kodiert werden müssen, besonders wenn Authentifizierungsanmeldeinformationen oder Tokens in der URL eingebettet sind.

FAQ

Was ist der Unterschied zwischen git fetch und git pull? git fetch lädt neue Commits und Branches vom Remote herunter, berührt aber Ihre lokalen Branches nicht. git pull ist ein Fetch, gefolgt von einem Merge. Fetch, wenn Sie zuerst prüfen wollen, pull, wenn Sie bereit zur Integration sind.

Wie mache ich einen bereits gepushten Commit rückgängig? Verwenden Sie git revert <commit-hash>, um einen neuen Commit zu erstellen, der die Änderungen rückgängig macht, ohne die Historie neu zu schreiben. git reset ist nur für Commits sicher, die noch nicht gepusht wurden.

Wofür ist git stash? Stash legt uncommittierte Änderungen temporär beiseite, damit Sie den Kontext wechseln können, ohne halbfertige Arbeit zu committen. git stash pop stellt die Änderungen wieder her, wenn Sie zurückkommen.

Wann sollte ich Rebase statt Merge verwenden? Auf persönlichen Branches, wo Sie eine saubere lineare Historie wollen, bevor Sie in main mergen. Rebasen Sie niemals Commits, die andere bereits gezogen haben, es schreibt Hashes neu und verursacht Konflikte.

Wie stelle ich Commits nach git reset --hard wieder her? Führen Sie git reflog aus, um die Geschichte der HEAD-Positionen zu sehen. Finden Sie den benötigten Commit-Hash und führen Sie git reset --hard <dieser-hash> aus, um ihn wiederherzustellen.

Zusammenfassung

Git ist eines der Tools, das Zeitinvestitionen mehr belohnt als fast alles andere im Toolkit eines Entwicklers. Befehle, die kryptisch erscheinen, werden automatisch, und Workflows, die einst einen Dokumentations-Tab erforderten, werden zur zweiten Natur.

Der Git-Befehls-Generator ist für die Zwischenphase da, wenn Sie wissen, was Sie tun müssen, aber die genaue Syntax nicht ganz abrufen können. Fügen Sie ihn als Lesezeichen hinzu, nutzen Sie ihn, und bis Sie ihn oft genug genutzt haben, haben Sie die Befehle wahrscheinlich sowieso auswendig gelernt.