Einführung

Die meisten Menschen lernen Git auf die harte Tour, durch kleine Katastrophen. Diese Seite sammelt die häufigsten Anfängerfehler und wie man sie vermeidet (oder sich von ihnen erholt). Lesen Sie sie einmal jetzt und nochmal nach einem Monat Nutzung; der zweite Durchgang wird mehr Sinn ergeben.

Mit der falschen Identität committen

Das Vergessen, user.email pro Repository zu setzen, lässt private Adressen in Arbeits-Commits durchsickern. Setzen Sie immer eine Pro-Repo-Identität in Arbeits-Klonen:

git config user.email "[email protected]"
git log -1 --pretty=format:"%an <%ae>"

Geheimnisse committen

API-Schlüssel und .env-Dateien in Commits leben für immer, selbst nach einem nachträglichen "Löschen". Fügen Sie einen .gitignore-Eintrag vor dem ersten Commit hinzu und rotieren Sie jedes geleakte Credential sofort. Tools wie git-secrets und gitleaks können als Pre-Commit-Hooks laufen.

Force-Push über Teamkollegen

git push --force schreibt die Historie auf dem Remote um und löscht damit Commits anderer Personen. Bevorzugen Sie --force-with-lease, das sich weigert zu überschreiben, wenn der Remote sich bewegt hat:

git push --force-with-lease

Pull missverstehen

git pull ist Fetch + Merge (oder Rebase). Es mit uncommitted Änderungen auszuführen, kann überraschende Merge-Commits erzeugen. Committen, stashen oder einen sinnvollen Standard setzen:

git config --global pull.rebase true
git config --global pull.ff only

Im detached HEAD bearbeiten, ohne es zu merken

Das Auschecken eines Tags oder Commit-Hashes versetzt Sie in detached HEAD. Neue Commits dort sind unerreichbar, sobald Sie weg wechseln. Erstellen Sie immer zuerst einen Branch:

git switch -c hotfix v1.2.3

reset, revert und restore verwechseln

• git restore ändert den Working Tree oder den Index; sicher.
• git revert erstellt einen neuen Commit, der einen anderen rückgängig macht; sicher und teilbar.
• git reset --hard verschiebt den Branch und verwirft Arbeit; destruktiv.

Riesige Dateien committen

Ein 500 MB-Video in einem Commit ist permanent. Verwenden Sie Git LFS für Binärdateien über wenige Megabyte hinaus und halten Sie Build-Artefakte vollständig aus dem Repository fern.

Recovery-Werkzeugkasten

git reflog
git fsck --lost-found
git stash list

Das Reflog zeichnet jede Bewegung von HEAD standardmäßig 90 Tage lang auf; nahezu jeder "verlorene" Commit kann daraus wiederhergestellt werden.

Status falsch lesen

Die Ausgabe von git status hat subtile Schichten. "Changes not staged for commit" bedeutet im Working Tree modifizierte verfolgte Dateien. "Changes to be committed" bedeutet gestaged. "Untracked files" bedeutet, Git hat sie nie gesehen. Eine häufige Verwirrung: Eine Datei nach dem Stagen zu bearbeiten zeigt sie unter beiden Listen mit unterschiedlichem Inhalt; nur das, was gestaged ist, geht in den Commit. Führen Sie git diff (Working Tree vs. Index) und git diff --staged (Index vs. HEAD) aus, bis die drei Bereiche klar sind.

git status -sb
git diff --staged --stat

Häufige Fehler

In Panik geraten und rm -rf .git ausführen, wenn etwas falsch aussieht. Stop. Erstellen Sie zuerst ein Backup des Verzeichnisses. Nahezu jeder Git-Fehler ist über das Reflog oder den Stash wiederherstellbar. Die einzige wichtigste Gewohnheit für Anfänger: Führen Sie git status vor und nach jedem zustandsändernden Befehl aus, und führen Sie git log --oneline --all --graph aus, wenn etwas seltsam erscheint.