Git Rebase vs. Merge: Wann nimmt ma wos

git merge und git rebase bringen beide die Änderungen von deim Feature-Branch auf main, und genau diese oberflächliche Ähnlichkeit is der Grund, warum Leit sie durcheinanderbringen und entweda mit am verhedderten oda mit am ungewollt umgschriebenen Verlauf enden. Sie lösn des söbe Problem auf grundverschiedene Art, und des falsche für de Situation zum nehmen, führt zu Force-Push-Desastern oda unlesbaren Commit-Graphen.

Wos jedes von de zwoa wirklich mocht

Sogn ma, main is weitergwandert, seit du abzweigt host, und dein Feature-Branch hot eigene Commits:

      A---B---C  feature
     /
D---E---F---G  main

Merge erstöt an neichn Commit, der de beiden Verläufe zammbindet, mit zwoa Eltern:

git checkout feature
git merge main

      A---B---C-------H  feature
     /               /
D---E---F---G--------  main

Nix an A, B oda C ändert si. H is a neicher Merge-Commit, der festhoit "de zwoa Verlaufslinien sand jetzt verbunden". Da gesamte Verlauf - inklusive dem Faktum, dass du vor F und G abzweigt host - bleibt intakt.

Rebase nimmt deine Commits und spielt's einzeln auf der neichn Basis nochamoi ab:

git checkout feature
git rebase main

D---E---F---G---A'---B'---C'  feature

A', B', C' sand neiche Commits - gleiche Änderungen, gleiche Messages, aber anderer Parent, also andere Commit-Hashes. Da Abzweigungspunkt is weg; es schaut jetzt aus, ois hättest von G abzweigt und deine drei Commits von dort aus in oana geraden Linie gschriebn.

Warum die Unterscheidung wichtig is

Da Kern-Kompromiss: Merge bewahrt, wos wirklich passiert is, Rebase erzeugt an sauberer ausschauenden Verlauf, der so ned buchstäblich passiert is. Beide sand nützlich - für unterschiedliche Zielgruppen.

• Merge is ehrlich über die parallele Orbeit. Wenn zwoa Leit beide auf am oidn main aufbaut hom und ihre Branches auseinandergangen und wieda zammkemman sand, hält a Merge-Commit des wahrheitsgetreu fest. Er is nicht-destruktiv - ka bestehender Commit wird verändert, drum is er auf geteilten Branches imma sicher.
• Rebase lasst den Verlauf so lesn, ois wär er hintereinander passiert, was später leichter nachzuvollziehn is - git log zeigt oane saubere Linie statt ana Gitterstruktur aus Merge-Commits -, aber es schreibt Commit-Hashes um, und do kummt die Gefahr her.

Die Regel, die wirklich zählt: Nie geteilten Verlauf rebasen

git checkout feature
git rebase main
git push --force-with-lease

Wenn feature a Branch is, an dem nur du orbeitest, is des in Ordnung - du schreibst Commits um, auf denen sonst niemand aufgebaut hot. Wenn feature (oder schlimmer, main) a Branch is, den andere scho gepullt und darauf aufgebaut hom, schreibt a Rebase den Verlauf unter ihnen weg: de Historie von ihrem lokalen Branch und vom Remote gehn auseinander, und ihr nächster Pull produziert a verwirrendes Gewirr aus doppelten Commits, oder ihre lokalen Commits scheinen zu verschwinden (sie sand ned weg - sie sand nur nimma von dem Branch aus erreichbar, dem's zu folgen glaubt hom).

Faustregel: Rebase frei auf Branches, auf de nur du pushst; Merge (oder Rebase-und-Fast-Forward über a PR-Tool) für olles, wos scho geteilt is.

Interaktiver Rebase: Aufräumen vorm Teiln

Die ondere häufige Verwendung von Rebase hot gor nix mit ana anderen Basis zum tun - es geht ums Aufräumen von deinen eigenen ungepushten Commits, bevor du a PR aufmachst.

git rebase -i HEAD~4

Des öffnet an Editor mit deinen letzten vier Commits, wo du sie umsortieren, "fix typo" und "actually fix typo" in den Commit squashen kannst, zu dem sie gehörn, oder Messages umformulieren - alles, bevor jemand ondrer sie gsehn hot. Des is die sicherste und häufigste Verwendung von Rebase in da Praxis: an chaotischen Work-in-Progress-Verlauf in a klane Anzoi zusammenhängender Commits verwandeln, bevor er geteilter Verlauf wird.

Merge-Konflikte fühln si unterschiedlich o

Bei am Merge löst du Konflikte einmal, im einzelnen Merge-Commit. Bei am Rebase kannst du, wenn mehrere Commits dieselben Zeilen anfassn, denselben Konflikt wiederholt kriagn - einmal pro Commit, der nochamoi abgspielt wird -, was mühsamer, aber a präziser is: du lösch jede historische Änderung in dem Kontext, in dem sie tatsächlich gmocht wurde, ned oan riesigen Diff am Ende.

git rebase main
# CONFLICT in commit B
# ...resolve...
git add .
git rebase --continue
# CONFLICT in commit C, same lines
# ...resolve again...
git add .
git rebase --continue

Wenn a Rebase zu ana Konflikt-Schlammschlacht ausartet, bringt dich git rebase --abort genau dorthin zruck, wo du gstartet bist - gut zum Merken, bevor du drei Konflikte tief drinnen bist und ned sicher, ob's schlimmer wird.

A praktischer Standard

• Am eigenen Feature-Branch, willst vor'm Weitermochn auf main aufholn: rebase.
• Commits aufräumen, bevor ma a PR aufmocht: rebase -i.
• A fertigen, reviewten Feature-Branch in main bringen: wos immer die Konvention von deim Team is - beides is vertretbar, und Konsistenz zählt mehr ois die Wahl.
• Olles, wos scho gepusht is und möglicherweise von wem ondern gepullt wurde: merge, oder Rebase nur mit ausdrücklicher Team-Absprache und Vorwarnung.

Fazit

Merge sogt die Wahrheit über den parallelen Verlauf, zum Preis ana verheddertn Grafik; Rebase erzeugt an sauberen linearen Graphen, zum Preis vom Umschreibn der Commit-Identität. Die Grenze, auf de's wirklich ankummt, is ned "wos is besser" - sondern ob de Commits, die du umschreibn wüst, no immer nur dir gehörn.