Ihr Feature-Branch liegt hinter main zurück, und Sie brauchen die neue Arbeit. Git merge vs rebase ist die Wahl zwischen zwei Wegen dorthin, und beide sind korrekt. Sie unterscheiden sich darin, wie die Historie danach aussieht.

Wir haben ein winziges Repository gebaut, beide Befehle ausgeführt und die echte Ausgabe unten eingefügt, damit Sie das Ergebnis vergleichen können, statt es sich vorzustellen. Neu bei Git? Beginnen Sie mit unserem Git-Tutorial für Anfänger (auf Englisch).

Was git merge und git rebase tun

git merge nimmt die Spitzen zweier Branches und kombiniert sie. Haben beide neue Commits, erzeugt Git einen Merge-Commit mit zwei Eltern. Nichts, was bereits existiert, wird verändert.

git rebase nimmt die Commits, die nur auf Ihrem Branch liegen, legt sie beiseite, setzt Ihren Branch auf die Spitze des anderen und spielt Ihre Commits dann nacheinander neu ab. Die abgespielten Commits sind neue Commits mit neuen Hashes, auch wenn ihre Änderungen gleich sind.

Git merge in der Praxis

Unser Ausgangspunkt: Commit A auf main, zwei Commits (F1, F2) auf feature und danach ein weiterer Commit (M1) auf main. Nun mergen wir main in feature.

git switch feature
git merge main
git log --oneline --graph

*   f507aab Merge main into feature
|\
| * 8842fb5 M1
* | 082cc6a F2
* | 5a71e3c F1
|/
* 8766865 A

Der Graph zeigt die wahre Geschichte: zwei Arbeitslinien, die zusammengeführt wurden. Die ursprünglichen Commits F1 und F2 behalten ihre Hashes. Der Preis ist ein zusätzlicher Merge-Commit, und in einem belebten Projekt wird der Graph zu einem Geflecht.

Git rebase in der Praxis

Gleicher Ausgangspunkt, aber diesmal rebasen wir feature auf main.

git switch feature
git rebase main
git log --oneline --graph

* 1ff474b F2
* bf9149e F1
* 8842fb5 M1
* 8766865 A

Die Historie ist eine gerade Linie, als hätten Sie Ihre Arbeit nach M1 begonnen. Schauen Sie auf die Hashes: F1 war 5a71e3c und ist jetzt bf9149e, F2 wechselte von 082cc6a zu 1ff474b. Git hat sie neu geschrieben, und deshalb braucht Rebase Sorgfalt.

Merge und Rebase im Vergleich

Die goldene Regel des Rebase

Rebasen Sie keine Commits, die außerhalb Ihres eigenen Repositorys existieren. Nach einem Rebase passt Ihr Branch nicht mehr zur Kopie auf dem Server, sodass das Pushen einen Force-Push braucht. Hat ein Kollege auf den alten Commits aufgebaut, widerspricht seine Historie nun Ihrer, und das zu bereinigen ist mühsam.

Den privaten Feature-Branch zu rebasen ist in Ordnung. main oder einen Branch, den andere nutzen, zu rebasen, nicht.

Ein sicherer Team-Workflow

Diese Routine hält die Historie sauber, ohne jemanden zu überraschen. Die meisten Teams nutzen sie vor ihrer CI-Pipeline, etwa der aus unserem GitHub-Actions-CI/CD-Leitfaden (auf Englisch).

git switch feature
git fetch origin
git rebase origin/main        # or: git pull --rebase
# fix conflicts, then: git add <file> && git rebase --continue
git push --force-with-lease   # only on your own branch

--force-with-lease weigert sich, den Server-Branch zu überschreiben, wenn seit Ihrem letzten Fetch jemand gepusht hat, was ein einfaches --force stillschweigend zerstören würde. Ist der Pull Request genehmigt, mergen Sie ihn in main.

Ein missglücktes Rebase rückgängig machen

Ein Rebase wirkt zerstörerisch, aber die alten Commits bleiben eine Weile im reflog von Git, sodass Sie zurückgehen können.

git reflog                    # find the commit before the rebase
git reset --hard HEAD@{5}     # example position, check reflog first

Legen Sie vor jedem riskanten Rebase mit git branch backup einen Backup-Branch an, dann ist die Wiederherstellung ein einziger Befehl. Betreiben Sie nebenbei eine Datenbank oder Tools in Containern? Lesen Sie unser Docker-Tutorial für Anfänger (auf Englisch).

Fazit

Merge bewahrt die Wahrheit, Rebase hält sie ordentlich. Nutzen Sie Rebase, um Ihren eigenen Branch aufzufrischen, Merge, um ihn auszuliefern, und schreiben Sie niemals eine Historie um, von der andere abhängen.

Häufig gestellte Fragen

Weiterlernen (englische Artikel)