Git-Befehle für Entwicklerinnen — das Wesentliche
Vom Klonen über Rebase bis zur Rettung nach Force-Push — die Git-Befehle, die Sie wirklich brauchen, mit kopierbaren Aufrufen und Einzeiler-Erklärungen.
Weitere Utilities, die gut zu dieser Anleitung passen:
Warum das wichtig ist
Eine neue Kollegin pusht versehentlich git push --force auf main und überschreibt gestrige Commits. Die Rettung dauert 30 Sekunden mit git reflog — wenn man weiß, dass es existiert. Git ist syntaktisch gnadenlos, aber großzügig mit Sicherheitsnetzen — und die meisten nutzen 10 %, weil ihr Vokabular bei clone/commit/push endet. Eine kategorisierte Cheatsheet-Referenz ist einer der wirksamsten Hilfen für ein Team.
Drei echte Szenarien
git rebase -i main — pick/squash. Referenz zeigt die interaktiven Rebase-Verben.
Saubere Main-Historie
git bisect start good bad, jeden Test gut/schlecht markieren — Git isoliert den Übeltäter.
Ursache in ~log₂(N) Schritten
git reflog zeigt jede HEAD-Bewegung; git reset --hard <reflog-id> stellt wieder her.
Katastrophe abgewendet
Schritt für Schritt — die Referenz nutzen
Öffnen Sie die Git-Befehlsreferenz.
Nach Workflow-Stadium browsen
Setup, tägliche Commits, Branch-Verwaltung, Remote-Sync, Historie umschreiben, Debuggen, Recovery.
Nach Verb suchen
„rebase“, „stash“, „cherry-pick“ — passende Befehle mit Erklärung.
Kanonischen Aufruf kopieren
Einzeiler „was Sie wirklich tippen“ plus Varianten mit Optionen.
Gotcha-Hinweis lesen
Viele Einträge warnen vor
--force,pull --rebasevs. Standard-Merge usw.Häufig genutzte Kategorien bookmarken
z. B. „Historie umschreiben“ für stressige Momente.
Ziel
Start a feature, save WIP, sync with main,
finish, push for PR.Befehle
git checkout -b feature/payment-retry
# work, work, work
git add . && git commit -m "WIP retry logic"
git fetch origin
git rebase origin/main
# fix any conflicts, then:
git push -u origin feature/payment-retrySymptom
You ran `git reset --hard HEAD~5`
and now the last 5 commits seem gone.Fix
git reflog # find the SHA before the reset
git reset --hard <SHA> # restore HEAD to it
Profi-Tipps
git switchundgit restorestattcheckoutzu überladen —switchfür Branches,restorefür Dateien. Weniger Verwechslung.--first-parentingit logblendet Merge-Rauschen aus — nur Mainline.pull.rebase = true—git pullrebased standardmäßig — weniger „merge merge merge“ auf Features.git commit --amendfür den letzten Commit;git rebase -ifür ältere — nach Push auf geteiltem Branch nicht amenden.
Typische Stolpersteine
Stolperstein
Force-Push löscht Arbeit der Kollegin
Immer git push --force-with-lease statt --force — bricht ab, wenn Remote seit dem letzten Fetch weiter ist. --force nur für Zweige, die garantiert nur Ihre sind.
Stolperstein
Secrets versehentlich committed
git filter-repo (oder BFG) schreibt Historie ohne die Datei um — Secret sofort rotieren.
Stolperstein
`git rebase main` statt `git rebase origin/main`
Lokales main kann veraltet sein — vorher git fetch oder explizit gegen origin/main rebasen.
Wann dieses Tool nicht passt
- Branch-Graphen visualisieren — Lazygit, GitKraken, VS-Code Git Graph schneller als
git log --graph. - Code Review — GitHub/GitLab/Gerrit für Kommentare und Freigaben.
- Große Binärdateien — Git LFS oder
git annex, nicht Vanilla-Git.
FAQ
Was ist „Fast-forward"?
Fast-forward verschiebt den Branch-Zeiger auf eine gerade Commit-Kette — ohne Merge-Commit. Üblich, wenn Zielbranch seit Branch-Start nicht weiterlief.
Wann `git stash`?
Für wirklich wegwerfbares WIP. Für echte Arbeit lieber wip-Commit auf Temp-Branch — Stashes sind leicht zu vergessen.
Sind Reflog-Einträge für immer?
Nein — Standard ~90 Tage für normale Einträge, 30 für unreachable. Danach hilft nur noch git fsck --lost-found begrenzt weiter.
Nächste Schritte
- Shell-Helfer mit der Linux-Befehlsreferenz kombinieren (grep, find, awk).
- Remote-URLs und Ports mit dem URL-Parser inspizieren.
- HTTP-Codes von
git push(401, 403, 502) in der HTTP-Status-Referenz nachschlagen.