Was ist der Unterschied zwischen git merge und git rebase?

Git merge erstellt einen neuen Merge-Commit, der zwei Branches kombiniert und dabei die vollstaendige Historie bewahrt. Git rebase spielt Ihre Commits auf einem anderen Branch erneut ab und erzeugt eine lineare Historie. Rebase ist sauberer fuer Feature-Branches, waehrend Merge sicherer fuer gemeinsam genutzte Branches ist.

Wie findet git bisect den Commit, der einen Bug eingefuehrt hat?

Git bisect fuehrt eine binaere Suche durch Ihre Commit-Historie durch. Sie markieren einen bekannten guten Commit und einen bekannten schlechten Commit, dann checkt bisect den Mittelpunkt aus, damit Sie ihn testen koennen. Dies halbiert den Suchraum bei jedem Schritt und findet den fehlerhaften Commit in O(log n) Schritten.

Kann ich einen Commit nach git reset --hard wiederherstellen?

Ja. Git reflog zeichnet jede Aenderung an HEAD fuer mindestens 30 Tage auf. Fuehren Sie git reflog aus, um den SHA des verlorenen Commits zu finden, und verwenden Sie dann git checkout oder git cherry-pick zur Wiederherstellung. Nichts, was in Git committet wurde, ist wirklich verloren, bis die Garbage Collection ausgefuehrt wird.

Was sind Git-Hooks und wo werden sie gespeichert?

Git-Hooks sind Skripte, die automatisch an bestimmten Punkten im Git-Workflow ausgefuehrt werden (pre-commit, commit-msg, pre-push usw.). Sie werden im Verzeichnis .git/hooks/ gespeichert. Fuer teamuebergreifende Hooks verwenden Sie ein Tool wie Husky oder speichern die Hooks in einem verfolgten Verzeichnis und erstellen symbolische Links.

Fortgeschrittene Git-Workflows: Rebase, Bisect, Hooks und Wiederherstellung

Die meisten Entwickler lernen git add, git commit und git push — und hoeren dann auf. Aber Git ist ein ausserordentlich maechiges Werkzeug mit Befehlen, die Ihnen Stunden an Arbeit sparen koennen, Ihnen helfen Bugs in Sekunden aufzuspueren, Code-Qualitaetspruefungen zu automatisieren und Fehler zu beheben, die andernfalls katastrophal waeren. Dieser Leitfaden behandelt die fortgeschrittenen Git-Workflows, die alltaegliche Benutzer von Power-Usern unterscheiden: interaktives Rebase, Bisect, Hooks, Reflog-Wiederherstellung, Cherry-Pick, Worktrees und mehr.

Fuer wen dieser Artikel ist: Dieser Artikel setzt voraus, dass Sie mit grundlegenden Git-Operationen vertraut sind (commit, push, pull, branch, merge). Falls Sie diese Grundlagen noch erlernen, beginnen Sie dort und kommen Sie zurueck, wenn Sie bereit sind, den naechsten Schritt zu machen.

Voraussetzungen

Bevor Sie in fortgeschrittene Workflows eintauchen, stellen Sie sicher, dass Sie Folgendes haben:

Git 2.23 oder neuer installiert (fuehren Sie git --version aus, um zu pruefen)
Ein Repository mit mindestens 20-30 Commits zum Ueben
Vertrautheit mit grundlegendem Branching und Merging
Ein Terminal, mit dem Sie vertraut sind (Bash, Zsh, PowerShell)

# Git-Version pruefen
git --version

# Git auf Ubuntu/Debian aktualisieren
sudo apt update && sudo apt install git

# Git auf macOS aktualisieren
brew upgrade git

Tipp: Erstellen Sie ein Wegwerf-Repository zum Ueben dieser Befehle. Viele davon schreiben die Historie um, und Sie moechten Sicherheit gewinnen, bevor Sie sie auf Produktionscode anwenden.

Interaktives Rebase

Interaktives Rebase ist wohl das maechtigste Commit-Bearbeitungswerkzeug in Git. Es ermoeglicht Ihnen, Commits umzuschreiben, zusammenzufassen, umzuordnen und zu loeschen, bevor Sie sie auf einen gemeinsamen Branch pushen.

Ein Interaktives Rebase starten

Um die letzten 5 Commits zu bearbeiten:

git rebase -i HEAD~5

Dies oeffnet Ihren Editor mit einer Liste von Commits, der aelteste zuerst:

pick a1b2c3d Add user authentication
pick e4f5g6h Fix typo in login form
pick i7j8k9l Add password reset feature
pick m0n1o2p Fix lint errors
pick q3r4s5t Update README

Rebase-Befehle

Jede Commit-Zeile beginnt mit einem Befehl. Die nuetzlichsten sind:

pick — Den Commit unveraendert beibehalten
reword — Den Commit beibehalten, aber die Commit-Nachricht aendern
squash — Diesen Commit mit dem vorherigen zusammenfuegen (behaelt beide Nachrichten)
fixup — Mit dem vorherigen Commit zusammenfuegen (verwirft die Nachricht dieses Commits)
edit — Das Rebase an diesem Commit anhalten, damit Sie ihn aendern koennen
drop — Diesen Commit vollstaendig entfernen

Commits zusammenfassen (Squash)

Die haeufigste Verwendung von interaktivem Rebase ist das Zusammenfassen mehrerer kleiner Commits zu einem aussagekraeftigen Commit:

pick a1b2c3d Add user authentication
fixup e4f5g6h Fix typo in login form
pick i7j8k9l Add password reset feature
fixup m0n1o2p Fix lint errors
drop q3r4s5t Update README

Das ergibt zwei saubere Commits statt fuenf unuebersichtlicher.

Commits umordnen

Ordnen Sie einfach die Zeilen in Ihrem Editor um, um die Commit-Reihenfolge zu aendern:

pick i7j8k9l Add password reset feature
pick a1b2c3d Add user authentication

Warnung: Fuehren Sie niemals ein Rebase auf Commits durch, die bereits auf einen gemeinsamen Branch gepusht wurden. Das Umschreiben gemeinsamer Historie verursacht Konflikte fuer jeden in Ihrem Team. Fuehren Sie Rebase nur auf Ihren lokalen, nicht gepushten Commits durch.

Autosquash mit Fixup-Commits

Wenn Sie wissen, dass ein Commit eine Korrektur fuer einen frueheren ist, markieren Sie ihn beim Committen:

# Einen Fixup-Commit erstellen, der automatisch mit dem Ziel-Commit zusammengefuegt wird
git commit --fixup=a1b2c3d

# Spaeter, Autosquash waehrend des Rebase
git rebase -i --autosquash HEAD~10

Git ordnet Fixup-Commits automatisch neben ihren Zielen an und markiert sie mit fixup.

Git Bisect: Binaere Suche nach Bugs

Wenn ein Bug auftaucht und Sie nicht wissen, welcher Commit ihn eingefuehrt hat, ist das Testen jedes einzelnen Commits unpraktisch. git bisect fuehrt eine binaere Suche durch und findet den exakten Commit in O(log n) Schritten.

Manuelles Bisect

# Bisect starten
git bisect start

# Den aktuellen Commit als schlecht markieren (hat den Bug)
git bisect bad

# Einen bekannten guten Commit markieren (bevor der Bug existierte)
git bisect good v2.0.0

# Git checkt den Mittelpunkt aus -- testen Sie ihn
# Wenn dieser Commit den Bug hat:
git bisect bad

# Wenn dieser Commit den Bug nicht hat:
git bisect good

# Wiederholen, bis Git den ersten schlechten Commit identifiziert
# Wenn fertig:
git bisect reset

Fuer einen Bereich von 1.024 Commits findet Bisect den Verursacher in etwa 10 Schritten.

Automatisiertes Bisect mit einem Skript

Wenn Sie ein Testskript haben, das den Exit-Code 0 fuer gut und einen Wert ungleich Null fuer schlecht zurueckgibt:

git bisect start
git bisect bad HEAD
git bisect good v2.0.0

# Den Test automatisch bei jedem Schritt ausfuehren
git bisect run ./test-script.sh

# Oder einen bestimmten Testbefehl verwenden
git bisect run npm test -- --grep "login feature"

Git fuehrt das Skript an jedem Mittelpunkt aus und identifiziert den fehlerhaften Commit ohne manuelles Eingreifen.

Bisect mit komplexen Kriterien

# Commits ueberspringen, die nicht getestet werden koennen (z.B. fehlerhafter Build)
git bisect skip

# Das Bisect-Protokoll anzeigen
git bisect log

# Eine Bisect-Sitzung aus einer Protokolldatei wiedergeben
git bisect replay bisect-log.txt

Cherry-Pick-Strategien

Cherry-Pick wendet einen bestimmten Commit von einem Branch auf einen anderen an, ohne den gesamten Branch zu mergen. Es ist nuetzlich fuer Hotfixes, Backporting und selektive Feature-Integration.

Einfacher Cherry-Pick

# Einen einzelnen Commit auf Ihren aktuellen Branch anwenden
git cherry-pick abc1234

# Mehrere Commits anwenden
git cherry-pick abc1234 def5678 ghi9012

# Einen Bereich von Commits anwenden (exklusiv des ersten)
git cherry-pick abc1234..ghi9012

Cherry-Pick ohne Commit

# Aenderungen stagen, aber nicht committen (nuetzlich zum Kombinieren mehrerer Picks)
git cherry-pick --no-commit abc1234
git cherry-pick --no-commit def5678

# Die kombinierten Aenderungen pruefen, dann committen
git commit -m "Backport: authentication fixes from develop"

Cherry-Pick-Konflikte behandeln

# Wenn ein Konflikt waehrend des Cherry-Pick auftritt:
# 1. Die Konflikte in den betroffenen Dateien loesen
# 2. Die geloesten Dateien stagen
git add resolved-file.js

# 3. Den Cherry-Pick fortsetzen
git cherry-pick --continue

# Oder den gesamten Cherry-Pick abbrechen
git cherry-pick --abort

Cherry-Pick fuer Hotfixes

Ein gaengiges Muster fuer Produktions-Hotfixes:

# Auf dem main-Branch den Bug beheben
git checkout main
git checkout -b hotfix/login-crash

# Die Korrektur vornehmen und committen
git commit -am "Fix: prevent null pointer in login handler"

# In main mergen
git checkout main
git merge hotfix/login-crash

# Die Korrektur per Cherry-Pick auf den develop-Branch uebertragen
git checkout develop
git cherry-pick <hotfix-commit-sha>

Git-Hooks

Git-Hooks sind Skripte, die automatisch an bestimmten Punkten im Git-Lebenszyklus ausgefuehrt werden. Sie setzen Codequalitaet durch, validieren Commit-Nachrichten und verhindern, dass fehlerhafter Code ins Repository gelangt.

Hook-Typen und Speicherorte

Hooks befinden sich in .git/hooks/. Die am haeufigsten verwendeten Hooks sind:

Hook	Ausloeser	Gaengige Verwendung
`pre-commit`	Bevor ein Commit erstellt wird	Linting, Formatierung, Tests
`commit-msg`	Nach Eingabe der Commit-Nachricht	Nachrichtenformat validieren
`pre-push`	Vor dem Push zu einem Remote	Vollstaendige Testsuite ausfuehren
`post-merge`	Nach Abschluss eines Merge	Abhaengigkeiten installieren
`pre-rebase`	Vor dem Start eines Rebase	Rebase auf gemeinsamen Branches verhindern

Pre-Commit-Hook: Linting

#!/bin/sh
# .git/hooks/pre-commit

# ESLint auf gestagten JavaScript-Dateien ausfuehren
STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep '\.js$')

if [ -n "$STAGED_FILES" ]; then
    echo "Running ESLint on staged files..."
    npx eslint $STAGED_FILES
    if [ $? -ne 0 ]; then
        echo "ESLint failed. Fix errors before committing."
        exit 1
    fi
fi

# Prettier-Pruefung ausfuehren
STAGED_ALL=$(git diff --cached --name-only --diff-filter=ACM)
if [ -n "$STAGED_ALL" ]; then
    npx prettier --check $STAGED_ALL
    if [ $? -ne 0 ]; then
        echo "Prettier check failed. Run 'npx prettier --write .' first."
        exit 1
    fi
fi

exit 0

Commit-Msg-Hook: Conventional Commits

#!/bin/sh
# .git/hooks/commit-msg

COMMIT_MSG_FILE=$1
COMMIT_MSG=$(cat "$COMMIT_MSG_FILE")

# Conventional-Commits-Format erzwingen
PATTERN="^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert)(\(.+\))?: .{1,72}"

if ! echo "$COMMIT_MSG" | grep -qE "$PATTERN"; then
    echo "ERROR: Commit message does not follow Conventional Commits format."
    echo ""
    echo "Expected: <type>(<scope>): <description>"
    echo "Example:  feat(auth): add password reset endpoint"
    echo ""
    echo "Valid types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert"
    exit 1
fi

exit 0

Pre-Push-Hook: Testsuite

#!/bin/sh
# .git/hooks/pre-push

echo "Running test suite before push..."
npm test

if [ $? -ne 0 ]; then
    echo "Tests failed. Push aborted."
    echo "Fix failing tests before pushing."
    exit 1
fi

echo "All tests passed. Pushing..."
exit 0

Hooks mit Ihrem Team teilen

Hooks in .git/hooks/ werden nicht von Git verfolgt. Um sie zu teilen:

# Option 1: Hooks in einem verfolgten Verzeichnis speichern
mkdir -p .githooks
cp .git/hooks/pre-commit .githooks/

# Git konfigurieren, das verfolgte Verzeichnis zu verwenden
git config core.hooksPath .githooks

# Option 2: Husky verwenden (Node.js-Projekte)
npx husky install
npx husky add .husky/pre-commit "npx lint-staged"

Git Reflog und Wiederherstellung

Das Reflog ist Ihr Sicherheitsnetz. Es zeichnet jede Aenderung an HEAD auf — Commits, Rebases, Resets, Checkouts — fuer mindestens 30 Tage. Wenn Sie Commits verlieren, ist das Reflog der Weg, sie zurueckzubekommen.

Das Reflog anzeigen

# Das Reflog anzeigen
git reflog

# Die Ausgabe sieht so aus:
# a1b2c3d HEAD@{0}: commit: Add new feature
# e4f5g6h HEAD@{1}: rebase -i (finish): returning to refs/heads/main
# i7j8k9l HEAD@{2}: rebase -i (squash): Add user auth
# m0n1o2p HEAD@{3}: reset: moving to HEAD~3

Wiederherstellung nach einem fehlerhaften Reset

# Sie haben versehentlich git reset --hard HEAD~3 ausgefuehrt und 3 Commits verloren
# Schritt 1: Den verlorenen Commit im Reflog finden
git reflog

# Schritt 2: Der Commit vor dem Reset befindet sich bei HEAD@{1}
git checkout HEAD@{1}

# Schritt 3: Einen Branch erstellen, um ihn zu sichern
git checkout -b wiederhergestellte-arbeit

# Oder bestimmte Commits per Cherry-Pick zurueckholen
git cherry-pick a1b2c3d

Wiederherstellung nach einem fehlerhaften Rebase

# Wenn ein Rebase schiefgegangen ist, den Zustand vor dem Rebase finden
git reflog

# Nach dem Eintrag kurz vor "rebase -i (start)" suchen
# Zu diesem Punkt zuruecksetzen
git reset --hard HEAD@{5}

Geloeschte Branches wiederherstellen

# Sie haben einen Branch mit wichtiger Arbeit geloescht
git branch -D feature/wichtige-arbeit

# Die Branch-Spitze im Reflog finden
git reflog | grep "wichtige-arbeit"

# Den Branch am gefundenen SHA neu erstellen
git branch feature/wichtige-arbeit abc1234

Wichtig: Reflog-Eintraege verfallen nach 90 Tagen (30 Tage fuer unerreichbare Commits). Wenn Sie verlorene Arbeit entdecken, stellen Sie sie so schnell wie moeglich wieder her. Sie koennen die Verfallszeit mit git config gc.reflogExpire konfigurieren.

Git Worktree: Parallele Entwicklung

Worktrees ermoegllichen es Ihnen, mehrere Branches gleichzeitig in separaten Verzeichnissen auszuchecken. Kein Stashen, Committen oder Branch-Wechseln mehr, um einen Pull Request zu pruefen oder einen Hotfix zu bearbeiten.

Einen Worktree erstellen

# Einen Branch in einem neuen Verzeichnis auschecken
git worktree add ../hotfix-branch hotfix/login-fix

# Einen neuen Branch in einem Worktree erstellen
git worktree add -b feature/new-api ../new-api-work

# Alle Worktrees auflisten
git worktree list

Praktischer Worktree-Workflow

# Ihr Hauptarbeitsverzeichnis hat develop ausgecheckt
# Ein Produktionsbug kommt rein -- arbeiten Sie daran, ohne Ihre aktuelle Arbeit zu stoeren

git worktree add ../prod-fix main
cd ../prod-fix

# Den Bug auf einem neuen Branch beheben
git checkout -b hotfix/critical-fix
# ... Aenderungen vornehmen, committen, pushen ...

# Zu Ihrer Feature-Arbeit zurueckkehren
cd ../my-project
# develop ist genau dort, wo Sie es verlassen haben

# Aufraeumen, wenn fertig
git worktree remove ../prod-fix

Worktree fuer Code-Review

# Den PR eines Kollegen pruefen, ohne Ihren aktuellen Branch zu verlassen
git fetch origin
git worktree add ../review-pr-42 origin/feature/user-dashboard

# Den Worktree in Ihrem Editor oeffnen, den Code pruefen
# Wenn fertig:
git worktree remove ../review-pr-42

Erweiterte Stash-Nutzung

Ueber das einfache git stash hinaus gibt es leistungsstarke Optionen zur Verwaltung von laufenden Aenderungen.

Benannte Stashes

# Stash mit einer beschreibenden Nachricht
git stash push -m "WIP: refactoring auth middleware"

# Alle Stashes auflisten
git stash list
# stash@{0}: On develop: WIP: refactoring auth middleware
# stash@{1}: On develop: WIP: database migration script

Partielles Stashing

# Nur bestimmte Dateien stashen
git stash push -m "stash auth changes" src/auth.js src/middleware.js

# Interaktiver Stash -- einzelne Hunks auswaehlen
git stash push -p -m "partial stash"

Stash Apply vs. Pop

# Apply behaelt den Stash in der Liste (sicher zum erneuten Versuchen)
git stash apply stash@{0}

# Pop wendet an und entfernt den Stash aus der Liste
git stash pop stash@{0}

# Stash auf einen anderen Branch anwenden
git checkout feature/anderer-branch
git stash apply stash@{0}

Einen Branch aus einem Stash erstellen

# Einen neuen Branch erstellen und den Stash darauf anwenden
git stash branch neuer-feature-branch stash@{0}

Dies ist besonders nuetzlich, wenn der Stash mit Aenderungen auf dem aktuellen Branch in Konflikt steht.

Git Blame und Log-Forensik

Wenn Sie verstehen muessen, warum eine Codezeile existiert, oder nachvollziehen wollen, wann eine Aenderung eingefuehrt wurde, sind Gits Forensik-Werkzeuge unverzichtbar.

Git Blame

# Sehen, wer jede Zeile zuletzt geaendert hat
git blame src/auth.js

# Blame fuer einen bestimmten Zeilenbereich
git blame -L 10,20 src/auth.js

# Whitespace-Aenderungen ignorieren
git blame -w src/auth.js

# Den Commit anzeigen, der die Zeile aus einer anderen Datei verschoben oder kopiert hat
git blame -C src/auth.js

Erweiterte Log-Suchen

# Commit-Nachrichten nach einem Stichwort durchsuchen
git log --grep="authentication" --oneline

# Nach Aenderungen an einer bestimmten Funktion suchen
git log -p -S "function loginUser" -- src/

# Nach Aenderungen suchen, die einem Regex entsprechen
git log -p -G "TODO|FIXME|HACK"

# Historie einer bestimmten Datei anzeigen
git log --follow --oneline -- src/auth.js

# Commits eines bestimmten Autors in einem Datumsbereich anzeigen
git log --author="JC" --after="2025-01-01" --before="2025-12-31" --oneline

Visuelle Log-Formate

# Kompakter Branch-Graph
git log --oneline --graph --all --decorate

# Benutzerdefiniertes Format mit Datum und Autor
git log --pretty=format:"%h %ad | %s%d [%an]" --date=short

# Statistiken pro Commit anzeigen
git log --stat --oneline -10

Branching-Strategien

Die Wahl der richtigen Branching-Strategie beeinflusst die Geschwindigkeit und Codequalitaet Ihres Teams.

Git Flow

Git Flow verwendet langlebige Branches fuer verschiedene Phasen:

# Haupt-Branches
main        # Produktionsreifer Code
develop     # Integrations-Branch fuer Features

# Unterstuetzende Branches
feature/*   # Neue Features (von develop abgezweigt)
release/*   # Release-Vorbereitung (von develop abgezweigt)
hotfix/*    # Produktionskorrekturen (von main abgezweigt)

# Ein Feature starten
git checkout develop
git checkout -b feature/user-dashboard

# Ein Feature abschliessen
git checkout develop
git merge --no-ff feature/user-dashboard
git branch -d feature/user-dashboard

Am besten geeignet fuer: Teams mit geplanten Releases und mehreren Umgebungen.

GitHub Flow

Eine einfachere Alternative mit einer einzigen Regel: Alles in main ist deploybar.

# Einen Branch von main erstellen
git checkout main
git checkout -b feature/add-search

# Arbeiten, committen, pushen
git push -u origin feature/add-search

# Einen Pull Request oeffnen, Review erhalten, in main mergen
# Deployment erfolgt automatisch von main

Am besten geeignet fuer: Teams, die Continuous Deployment mit kurzlebigen Branches praktizieren.

Trunk-basierte Entwicklung

Alle Entwickler committen haeufig in main (den Trunk) und verwenden kurzlebige Feature-Branches von maximal ein bis zwei Tagen.

# Kurzlebiger Branch (maximal 1-2 Tage)
git checkout -b feature/small-change
# ... minimale Aenderungen ...
git push -u origin feature/small-change
# Schnell ueber PR in main mergen

# Feature-Flags steuern unveroeffentlichte Features
if (featureFlags.newDashboard) {
    renderNewDashboard();
}

Am besten geeignet fuer: Hochproduktive Teams mit starken CI/CD-Pipelines und Feature-Flag-Infrastruktur.

Referenztabelle fuer fortgeschrittene Git-Befehle

Befehl	Beschreibung	Beispiel
`git rebase -i HEAD~N`	Interaktives Rebase fuer die letzten N Commits	`git rebase -i HEAD~5`
`git bisect start`	Binaere Suche nach Bugs starten	`git bisect start`
`git bisect run <script>`	Automatisiertes Bisect mit einem Testskript	`git bisect run npm test`
`git cherry-pick <SHA>`	Einen bestimmten Commit auf den aktuellen Branch anwenden	`git cherry-pick a1b2c3d`
`git cherry-pick --no-commit`	Cherry-Pick ohne automatischen Commit	`git cherry-pick --no-commit a1b2c3d`
`git reflog`	Historie der HEAD-Bewegungen anzeigen	`git reflog`
`git worktree add <Pfad> <Branch>`	Einen Branch in einem separaten Verzeichnis auschecken	`git worktree add ../fix main`
`git stash push -m "msg"`	Aenderungen mit beschreibender Nachricht stashen	`git stash push -m "WIP auth"`
`git stash push -p`	Interaktiver Stash ausgewaehlter Hunks	`git stash push -p`
`git blame -L 10,20 <Datei>`	Blame fuer einen bestimmten Zeilenbereich	`git blame -L 10,20 auth.js`
`git log -S "String"`	Commits finden, die einen String hinzufuegen/entfernen	`git log -S "loginUser"`
`git log -G "Regex"`	Commits finden, die einem Regex in Diffs entsprechen	`git log -G "TODO\|FIXME"`
`git commit --fixup=<SHA>`	Einen Fixup-Commit fuer Autosquash erstellen	`git commit --fixup=a1b2c3d`
`git config core.hooksPath`	Ein benutzerdefiniertes Hooks-Verzeichnis festlegen	`git config core.hooksPath .githooks`

Fehlerbehebung

Rebase-Konflikte lassen sich nicht loesen

# Wenn ein Rebase zu viele Konflikte hat, abbrechen und einen anderen Ansatz versuchen
git rebase --abort

# Alternative: Merge statt Rebase fuer komplexe Historien verwenden
git merge develop

Bisect liefert falsche Ergebnisse

# Wenn Sie einen Commit falsch markiert haben, Protokoll einsehen und wiedergeben
git bisect log > bisect-log.txt
# Die Protokolldatei bearbeiten, um den falschen Eintrag zu entfernen
git bisect reset
git bisect replay bisect-log.txt

Hook-Skripte werden nicht ausgefuehrt

# Sicherstellen, dass die Hook-Datei ausfuehrbar ist
chmod +x .git/hooks/pre-commit

# Die Shebang-Zeile ueberpruefen
head -1 .git/hooks/pre-commit
# Sollte sein: #!/bin/sh oder #!/bin/bash

# Pruefen, ob core.hooksPath den Standardspeicherort ueberschreibt
git config --get core.hooksPath

Worktree kann nicht geloescht werden

# Erzwungenes Entfernen eines Worktree mit nicht committeten Aenderungen
git worktree remove --force ../old-worktree

# Veraltete Worktree-Eintraege bereinigen
git worktree prune

Reflog-Eintrag nicht gefunden

# Die Reflog-Verfallszeit erhoehen, bevor es zu spaet ist
git config gc.reflogExpire 180.days
git config gc.reflogExpireUnreachable 90.days

# Wenn das Reflog leer ist, fsck versuchen, um verwaiste Commits zu finden
git fsck --unreachable --no-reflogs

Cherry-Pick ergibt einen leeren Commit

# Die Aenderungen existieren bereits auf dem Ziel-Branch
# --allow-empty verwenden, um den Commit beizubehalten, oder ueberspringen
git cherry-pick --skip

# Oder pruefen, ob die Aenderung bereits angewendet wurde
git log --oneline --all -- path/to/changed/file

Zusammenfassung

Fortgeschrittene Git-Workflows veraendern grundlegend, wie Sie Code verwalten. Interaktives Rebase haelt Ihre Commit-Historie sauber und aussagekraeftig. Git Bisect verwandelt eine manuelle Fehlersuche in eine automatisierte binaere Suche. Git-Hooks setzen Codequalitaetsstandards durch, bevor fehlerhafter Code ins Repository gelangt. Reflog dient als Ihr Sicherheitsnetz und macht praktisch jeden Git-Fehler wiederherstellbar. Cherry-Pick und Worktrees bieten die Flexibilitaet, ueber Branches hinweg ohne Unterbrechung zu arbeiten.

Der Schluessel ist Uebung. Erstellen Sie ein Test-Repository, machen Sie Dutzende von Commits und probieren Sie jeden Befehl in diesem Leitfaden aus. Sobald diese Werkzeuge zur zweiten Natur werden, werden Sie komplexe Git-Situationen mit Zuversicht bewaeltigen.

Um Ihre Test- und Deployment-Pipelines nach dem Beherrschen dieser Git-Workflows zu automatisieren, lesen Sie unseren Leitfaden zu Erste Schritte mit GitHub Actions fuer CI/CD.