Git Cheat Sheet, sortiert nach dem, was du tun willst
Git Cheat Sheet
Git Cheat Sheet nach Aufgaben: Befehle, Rückgängig-Rezepte und npm | We.Inc
Ein durchsuchbares Git Cheat Sheet, sortiert nach Aufgaben: starten, speichern, branchen, mergen, synchronisieren und deployen, dazu Rezepte für "Ich hab's verbockt", ein Diagramm, wo Änderungen liegen, und gängige npm-Befehle.
Die meiste tägliche Arbeit mit Git besteht aus sechs Befehlen: git status zeigt Änderungen, git add stagt sie, git commit -m speichert, git switch -c erstellt einen Branch, git pull holt Updates und git push teilt sie. Zum Rückgängigmachen nutzt du git restore für Dateien, git reset für lokale Commits und git revert für bereits gepushte Commits.
Rückgängig machen auf einen Blick
Was rückgängig machen
Befehl
Änderungen an einer Datei
git restore file
Staging
git restore --staged file
Letzter Commit, nicht gepusht
git reset --soft HEAD~1
Ein gepushter Commit
git revert <commit>
Durchsuche die Befehle unten, kopiere jede Zeile mit einem Klick und nutze die Rezepte, wenn etwas schiefgegangen ist. Die Befehle verwenden git switch und git restore, die klareren Nachfolger für die vielen Aufgaben von git checkout.
Gib ein Wort wie undo, branch oder tag in das Suchfeld ein.
Kopiere den Befehl und setze deinen Branch- oder Dateinamen ein.
Sieh im Diagramm nach, zwischen welchen Bereichen ein Befehl Änderungen verschiebt.
Führe git status vor und nach allem aus, was die History umschreibt.
Committe klein und oft; kleine Commits lassen sich leicht reverten und reviewen.
Führe nie reset oder force-push auf einem Branch aus, den andere nutzen. Nutze stattdessen revert.
Nimm lieber --force-with-lease statt --force; es verweigert den Push, wenn jemand anderes gepusht hat.
Formuliere Commit-Messages als das, was die Änderung bewirkt: "Add booking form", nicht "changes".
Bewahre Secrets ab dem allerersten Commit in Umgebungsdateien auf, die in .gitignore stehen.
Häufige Fragen
Was ist der Unterschied zwischen git reset und git revert?
reset setzt deinen Branch zurück und entfernt Commits aus seiner History; für lokale Arbeit ist das in Ordnung. revert fügt einen neuen Commit hinzu, der einen alten rückgängig macht, und lässt die History intakt. Das ist die sichere Wahl, sobald ein Commit gepusht ist.
git switch oder git checkout?
Beides funktioniert. Git 2.23 hat git switch zum Wechseln von Branches und git restore zum Wiederherstellen von Dateien eingeführt und damit die zwei Aufgaben aufgeteilt, die früher git checkout erledigt hat. Sie sind leichter zu lesen und schwerer falsch zu verwenden.
Was macht git fetch, was git pull nicht macht?
fetch lädt neue Commits herunter, ändert aber nichts an deinem Branch. pull führt fetch aus und merged oder rebased diese Commits dann in deinen aktuellen Branch.
Wie bekomme ich einen verlorenen Commit zurück?
Führe git reflog aus. Es listet jede Position auf, an der dein HEAD war, auch Commits, auf die kein Branch zeigt. Such den gewünschten heraus und führe git switch -c rescue <sha> aus.
npm install oder npm ci?
Nutze npm install während der Entwicklung; es kann die Lock-Datei aktualisieren. Nutze npm ci in Builds und in der CI; es löscht node_modules, installiert genau das, was in der Lock-Datei steht, und bricht ab, wenn package.json und die Lock-Datei nicht übereinstimmen.
Wo deine Änderungen liegen
Git unterscheidet vier Orte: deinen Arbeitsordner, die Staging-Area (auch Index genannt), dein lokales Repository und das Remote. add verschiebt Änderungen vom Ordner in die Staging-Area, commit von der Staging-Area ins Repository, push von deinem Repository zum Remote, und pull holt die Commits des Remotes wieder herunter.
Vom Commit zur Live-Website
Viele Hoster deployen, sobald du auf einen Branch pushst. Arbeite auf einem Feature-Branch, pushe ihn, um eine Vorschau zu erhalten, und merge ihn in main, um zu veröffentlichen. Tagge Releases, damit du schnell zu einer bekannten funktionierenden Version zurückkehren kannst.
Lösungen Schritt für Schritt
Auf main statt auf einen Branch committet
Erstelle an der aktuellen Stelle einen Branch (er behält die Commits) und setze main dann auf den Stand des Remotes zurück. Mach das nur, bevor du pushst.
Einen Merge-Konflikt lösen
Git hält an und markiert die kollidierenden Zeilen. Bearbeite jede Datei auf die gewünschte Version, entferne die Markierungen, stage die Dateien und schließ den Vorgang ab.
Versehentlich ein Secret gepusht
Tausche zuerst den Schlüssel aus: Sobald er gepusht ist, geh davon aus, dass er kopiert wurde. Entferne ihn dann aus dem Code und der History und füge die Datei zu .gitignore hinzu.
Schreibst du ein README für das Repository? Nutze das
Markdown Cheat Sheet
Arbeitsordner
Staging-Area
Lokales Repository
Remote (GitHub, GitLab)
Einmal einrichten
Name, der in deinen Commits steht
E-Mail-Adresse, die in deinen Commits steht
Neue Repositorys starten auf main
git pull rebased, statt Merge-Commits zu erstellen
Ein Projekt starten
Den aktuellen Ordner in ein Repository verwandeln
Ein Remote-Repository auf deinen Rechner kopieren
Ein lokales Repository mit einem Remote verbinden
Remotes und ihre URLs auflisten
Arbeit speichern
Was sich geändert hat, was gestagt ist
Eine Datei stagen
Teile von Dateien stagen, Hunk für Hunk
Gestagte Änderungen committen
Noch nicht gestagte Änderungen
Für den nächsten Commit gestagte Änderungen
Kompakte History mit gezeichneten Branches
Branchen und mergen
Einen Branch erstellen und zu ihm wechseln
Zu einem bestehenden Branch wechseln
Lokale Branches auflisten
Diesen Branch in den aktuellen mergen
Den aktuellen Branch auf main neu aufsetzen
Einen gemergten Branch löschen (-D erzwingt es)
Einen einzelnen Commit auf den aktuellen Branch kopieren
Synchronisieren und deployen
Remote-Änderungen herunterladen, ohne deine Dateien anzufassen
Fetchen, dann in den aktuellen Branch mergen oder rebasen
Einen neuen Branch pushen und das Ziel merken
Den aktuellen Branch pushen
Ein Release markieren
Diesen Tag pushen (Tags werden standardmäßig nicht gepusht)
Arbeit für später parken
Nicht committete Änderungen beiseitelegen
Ansehen, was gestasht ist
Den neuesten Stash zurückholen und aus der Liste entfernen
Ich hab's verbockt: Rezepte
Nicht gestagte Änderungen an einer Datei verwerfen (nicht umkehrbar)
Eine Datei unstagen, aber die Änderungen behalten
Die Message des letzten Commits korrigieren (oder gestagte Dateien hinzufügen), bevor du pushst
Den letzten Commit rückgängig machen, seine Änderungen bleiben gestagt
Den letzten Commit samt Änderungen löschen (lokal, nicht gepusht)
Einen gepushten Commit mit einem neuen Commit rückgängig machen; sicher auf geteilten Branches
Einen nach reset oder rebase verlorenen Commit finden, dann git switch -c rescue <sha>
Einen Merge mit Konflikten abbrechen
Einen schiefgelaufenen Rebase abbrechen
Versehentlich auf main committet: die Arbeit auf einen Branch legen, dann main zurücksetzen
Einen Remote-Branch nur überschreiben, wenn seit deinem letzten Fetch niemand gepusht hat
Nicht getrackte Dateien und Ordner erst in der Vorschau ansehen, dann löschen
package.json mit Standardwerten erstellen
Saubere Installation exakt nach der Lock-Datei (für CI)
Eine Abhängigkeit hinzufügen
Eine Abhängigkeit nur für die Entwicklung hinzufügen
Eine Abhängigkeit entfernen
Pakete mit neueren Versionen auflisten
Bekannte Sicherheitslücken melden
Anzeigen, welche Versionen eines Pakets installiert sind und warum
Neueste veröffentlichte Version eines Pakets
Den Befehl eines Pakets ausführen, ohne es zu installieren
Befehl
Was er macht
Kopieren
Wo Änderungen liegen
git pull holt die Commits des Remotes wieder herunter.