Der Unterschied zwischen merge und rebase in Git

Eingabe des Dienstes
1

Weder rebase noch merge bei pull löschen Ihre Arbeit automatisch — in beiden Fällen bleiben Ihre Commits im Repository (in der Branch-Geschichte oder als alte SHAs, solange der reflog aktiv ist).

  • pull.rebase false (merge): git pull erstellt einen Merge-Commit, Ihre und fremden Commits werden nicht überschrieben, die Branch-Geschichte wird einfach verzweigt und zusammengeführt. Visuell „sicherer“ für die Übersicht: Sie sehen deutlich, wo sich die Linien treffen.
  • pull.rebase true (rebase): Ihre lokalen Commits werden über die Remote-Commits kopiert (neue Hash-Werte). Das Inhalt der Commits ist meistens identisch, aber die „alten“ Commits bleiben nach erfolgreichem rebase nur noch im git reflog — das ist normal, von dort können Sie bei Bedarf wiederherstellen (git reset --hard zu einem gewünschten ref aus dem reflog), falls etwas schiefgelaufen ist.

Wenn das Hauptziel ist, „keine Arbeit zu verlieren“:

  1. Vor risikobehafteten Schritten — Commit (oder git stash) und optional eine eigene Backup-Branch (git branch backup-tgisn-46) — eine Kopie des Branch-Pointers, günstiger Backup.
  2. Verwechseln Sie nicht mit Verlust durch Befehle wie git reset --hard, force push ohne Notwendigkeit, git clean -fd.
  3. Nach rebase/merge sollten Sie ein paar Tage lang nicht aggressiv git gc ausführen — der reflog hält einen Notfall-Exit bereit.

Praktisch für „keine Arbeit verlieren, keine komplexe Historie“: git config pull.rebase false — bei Konflikten erhalten Sie immer einen merge, ohne lokale Commits zu überschreiben. Wenn Ihnen der rebase-Ansatz bereits gefällt (wie früher mit pull --rebase) — lassen Sie pull.rebase true stehen, aber vermeiden Sie push --force auf gemeinsame Branches ohne vorherige Absprache.

Zusammenfassung: Die Wahl der pull-Strategie führt nicht zur Verlust von Arbeit; das Risiko liegt in anderen Befehlen und force push; für Ruhe vor unklaren Operationen — Commit + Backup-Branch vor unklaren Operationen.

Die gleiche Situation wie bei Ihnen: Ein gemeinsamer Commit C, danach auf origin fünf Commits r1…r5, lokal — ein L (meine Arbeit).

1. Vor pull (verzweigt)

gitGraph
  commit id: "C (gemeinsam)"
  branch local
  checkout local
  commit id: "L (mein Commit)"
  checkout main
  commit id: "r1"
  commit id: "r2"
  commit id: "r3"
  commit id: "r4"
  commit id: "r5"

Bedeutung: Ende von local = L, Ende von main = r5, gemeinsamer Vorfahr = C. Dieses ist nicht verloren, es ändert sich nur, wie die Geschichte zusammengesetzt wird.

2. Nach git pull ohne rebase (pull.rebase false → merge)

gitGraph
  commit id: "C"
  branch local
  checkout local
  commit id: "L"
  checkout main
  commit id: "r1"
  commit id: "r2"
  commit id: "r3"
  commit id: "r4"
  commit id: "r5"
  checkout local
  merge main
  commit id: "M (Merge-Commit)"

Ein Merge-Commit M mit zwei Eltern (L und r5) entsteht. Die Commits L und r1…r5 bleiben als Objekte erhalten; die Geschichte ist verzweigt, es gibt keine Überschreibungen.

3. Nach git pull mit rebase (pull.rebase true → rebase)

gitGraph
  commit id: "C"
  commit id: "r1"
  commit id: "r2"
  commit id: "r3"
  commit id: "r4"
  commit id: "r5"
  commit id: "L′ (gleicher Patch, neuer Hash)"

Die Geschichte ist linear: Ihre Arbeit liegt obenauf den Remote-Commits. Der Commit L hat in der Geschichte einen neuen Commit L′ (gleicher Diff relativ zu r5, anderer Hash); der alte L bleibt noch eine Weile im git reflog sichtbar, bis Sie reflog expire entfernen.

Kurzfassung: Merge — Verzweigung + Merge-Knoten; Rebase — eine Linie, Ihr Commit „überlagert“ über die Remote-Commits. Ihre Arbeit im Sinne von Dateiänderungen verschwindet in beiden normalen Szenarien nicht; es unterscheidet sich nur die Form der Historie und der Hash des lokalen Commits bei Rebase.