Je featurebranch loopt achter op main en je hebt het nieuwe werk nodig. Git merge vs rebase is de keuze tussen twee manieren om dat te krijgen, en beide zijn correct. Ze verschillen in hoe de geschiedenis er daarna uitziet.

We maakten een piepkleine repository, voerden beide commando’s uit en plakten de echte output hieronder, zodat je het resultaat vergelijkt in plaats van het je voor te stellen. Nieuw met Git? Begin met onze Git-tutorial voor beginners (in het Engels).

Wat git merge en git rebase doen

git merge neemt de toppen van twee branches en combineert ze. Hebben beide nieuwe commits, dan maakt Git een mergecommit met twee ouders. Niets wat al bestaat wordt gewijzigd.

git rebase neemt de commits die alleen op jouw branch staan, legt ze opzij, verplaatst je branch naar de top van de andere en speelt je commits dan één voor één opnieuw af. De opnieuw afgespeelde commits zijn nieuwe commits met nieuwe hashes, ook al zijn de wijzigingen gelijk.

Git merge in de praktijk

Ons uitgangspunt: commit A op main, twee commits (F1, F2) op feature en daarna nog een commit (M1) op main. Nu mergen we 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

De grafiek toont het echte verhaal: twee werklijnen die samengevoegd zijn. De oorspronkelijke commits F1 en F2 behouden hun hashes. De prijs is een extra mergecommit, en in een druk project verandert de grafiek in een web.

Git rebase in de praktijk

Zelfde uitgangspunt, maar nu rebasen we feature op main.

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

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

De geschiedenis is één rechte lijn, alsof je na M1 met je werk begon. Kijk naar de hashes: F1 was 5a71e3c en is nu bf9149e, en F2 veranderde van 082cc6a in 1ff474b. Git heeft ze herschreven, en daarom vraagt rebase om zorg.

Merge en rebase naast elkaar

De gouden regel van rebase

Rebase geen commits die buiten je eigen repository bestaan. Na een rebase komt je branch niet meer overeen met de kopie op de server, dus pushen vraagt om een force. Heeft een collega werk op de oude commits gebouwd, dan botst zijn geschiedenis nu met de jouwe, en dat uitzoeken is pijnlijk.

Je eigen privé-featurebranch rebasen is prima. main of een branch die anderen gebruiken rebasen niet.

Een veilige teamwerkwijze

Deze routine houdt de geschiedenis schoon zonder iemand te verrassen. Het is ook wat de meeste teams gebruiken vóór hun CI-pipeline, zoals die in onze gids voor GitHub Actions CI/CD (in het Engels).

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 de serverbranch te overschrijven als iemand sinds je laatste fetch heeft gepusht, wat een gewone --force stilletjes zou vernietigen. Is de pull request goedgekeurd, merge hem dan in main.

Een mislukte rebase ongedaan maken

Een rebase lijkt destructief, maar de oude commits blijven een tijd in de reflog van Git staan, dus je kunt terug.

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

Maak vóór elke risicovolle rebase een back-upbranch met git branch backup, dan is herstel één commando. Draai je daarnaast een database of tools in containers? Bekijk onze Docker-tutorial voor beginners (in het Engels).

Tot slot

Merge bewaart de waarheid, rebase houdt haar netjes. Gebruik rebase om je eigen branch te verversen, merge om hem op te leveren en herschrijf nooit een geschiedenis waar anderen van afhangen.

Veelgestelde vragen

Blijf leren (Engelstalige artikelen)