git-rebase

De officiële Git-manpage op man7.org definieert de kernfunctie als: "Reapply commits on top of another base tip". Git pakt de commits van een branch en voert ze opnieuw uit, maar nu bovenop een andere commit — meestal de huidige HEAD van de hoofdbranch. Het resultaat is dat de commits van de feature branch lijken alsof ze pas zijn gemaakt nadat de laatste wijzigingen uit de hoofdbranch waren toegevoegd. De uiteindelijke code is identiek aan een merge, maar de geschiedenis ziet er anders uit: lineair in plaats van vertakt.

Stappen

1. Haal de nieuwste wijzigingen op

Voordat u rebaset, moet u de nieuwste remote wijzigingen ophalen. Gebruik `git fetch` om de remote-tracking branches bij te werken zonder uw lokale werk te beïnvloeden.

git fetch origin

Dit haalt alle nieuwe commits van de remote op, maar verandert niets aan uw lokale branches. U kunt nu zien waar `origin/main` staat ten opzichte van uw lokale branch.

2. Schakel naar uw feature branch

Zorg dat u op de branch staat die u wilt rebasen. Als u nog op een andere branch staat, schakel dan eerst.

git checkout feature-branch

Vervang `feature-branch` door de naam van uw branch. Controleer met `git branch` dat u op de juiste branch staat voordat u verder gaat.

3. Rebase op de hoofdbranch

Voer de rebase uit met `origin/main` als nieuwe basis. Dit past al uw lokale commits opnieuw toe bovenop de nieuwste commits van de hoofdbranch.

git rebase origin/main

Git pakt nu elke commit van uw feature branch en past deze opnieuw toe, één voor één, bovenop `origin/main`. Als er conflicten optreden, stopt Git en laat u deze oplossen.

4. Los conflicten op

Als Git conflicten meldt, open dan de conflicterende bestanden. Git markeert de conflicten met `<<<<<<<`, `=======` en `>>>>>>>`. Los elk conflict handmatig op en sla het bestand op.

git add conflicterend-bestand.txt
git rebase --continue

Git gaat verder met de volgende commit. Herhaal dit tot alle commits zijn toegepast. Wilt u stoppen, gebruik dan `git rebase --abort` om terug te keren naar de situatie van vóór de rebase.

5. Interactieve rebase voor geschiedenisbewerking

Gebruik `git rebase -i` om de geschiedenis actief te bewerken. Dit opent een editor met een lijst van commits. Het commando `git rebase -i HEAD~3` toont de laatste drie commits.

git rebase -i HEAD~3

In de editor ziet u regels zoals `pick a1b2c3d Commit-bericht`. U kunt `pick` vervangen door een van deze opties:

• `reword` — wijzig alleen het commitbericht
• `edit` — wijzig de inhoud van de commit
• `squash` — voeg de commit samen met de vorige
• `fixup` — voeg samen zonder het bericht te bewaren
• `drop` — verwijder de commit

Sla het bestand op en sluit de editor. Git voert de opgegeven acties uit.

6. Push na rebase

Als de branch al eerder was gepusht, moet u een force push uitvoeren. Dit is nodig omdat de commit-ID's zijn veranderd door de rebase.

git push --force-with-lease origin feature-branch

`--force-with-lease` is veiliger dan `--force`: het weigert de push als iemand anders in de tussentijd nieuwe commits naar de branch heeft gepusht.

7. Rebase met git-rerere

Voor workflows met frequente rebases kunt u `git-rerere` inschakelen. Deze tool hergebruikt opgeloste merge-conflicten automatisch.

git config --global rerere.enabled true

Wanneer u een conflict oplost, registreert Git de oplossing. Bij het volgende conflict dat erop lijkt, past Git de geregistreerde oplossing automatisch toe.

8. Controleer het resultaat met git-range-diff

`git-range-diff` vergelijkt twee commitranges — bijvoorbeeld vóór en na een rebase. Dit toont wat er precies is veranderd in de geschiedenis.

git range-diff origin/main...main feature-branch...feature-branch

Dit commando vergelijkt de commitranges en toont per commit welke wijzigingen zijn doorgevoerd. Dat is nuttig wanneer meerdere commits zijn herschreven of samengevoegd.

Verificatie

Controleer of de rebase is geslaagd met:

git log --oneline --graph --decorate

Dit toont de commitgeschiedenis. U ziet een lineaire lijn zonder vertakkingen. De commits van uw feature branch staan bovenop de nieuwste commits van `origin/main`. Er is geen merge-commit zichtbaar.

Controleer ook dat de code correct werkt:

git status

Dit moet "nothing to commit, working tree clean" tonen als alle conflicten zijn opgelost en de rebase is voltooid.

Veelgestelde problemen

1. "Cannot rebase: You have unstaged changes"

Git weigert te rebasen met niet-gecommitte wijzigingen. Los dit op door je wijzigingen te stashen:

git stash
git rebase origin/main
git stash pop

De stash wordt na de rebase opnieuw toegepast.

2. Conflict blijft terugkomen bij elke commit

Wanneer hetzelfde conflict bij elke commit optreedt, gebruik dan `git-rerere`. Schakel het in voordat u de rebase start:

git config --global rerere.enabled true

Git registreert uw oplossing bij de eerste keer en past deze daarna automatisch toe.

3. "Updates were rejected" bij push

Dit betekent dat de remote branch verschilt van uw lokale branch na de rebase. Gebruik `--force-with-lease`:

git push --force-with-lease origin feature-branch

Dit overschrijft de remote branch, maar weigert als anderen nieuwe commits hebben gepusht.

Waarom rebasen gevaarlijk is

`git rebase` herschrijft de geschiedenis en verandert daarmee de commit-ID's. Als een branch al is gedeeld met anderen, zien zij een mismatch tussen hun lokale geschiedenis en de gedeelde versie. De richtlijn is daarom: rebasen op commits die nog niet zijn gepusht of gedeeld is veilig; rebasen op gedeelde geschiedenis wordt afgeraden. `git reset` en `git restore` spelen ook een rol in geschiedenisbeheer, maar vervangen `rebase` niet. `git reset` zet HEAD naar een eerdere commit — destructief. `git restore` herstelt bestanden in de werkmap of index, handig na een fout in een interactieve rebase.

De term "rebase" is al sinds de vroege dagen van Git in gebruik. Een howto-document op kernel.org uit 14 augustus 2005 beschrijft het concept van het "forward port these changes" — het overbrengen van wijzigingen vanaf een fork-point naar de hoofdbranch. Dat was toen een manuele procedure; het werd al snel geautomatiseerd in het `git rebase`-commando. De technische specificatie staat in de manpage `git-rebase(1)`, onderhouden door Junio C. Hamano en Johannes E. Schindelin, wiens namen en e-mailadressen op de manpage staan zoals gepubliceerd op Linux die.net. De huidige manpage op man7.org bevestigt dezelfde kerndefinitie: "Reapply commits on top of another base tip".

Naast core Git bestaan er tools die rebase-workflows ondersteunen. Gitpulsar, een native Git-client voor GNOME geschreven in Rust, biedt een snelle, offline werkende interface zonder telemetrie. Commit is een editor die helpt bij het schrijven van betere commitberichten. Deze tools vervangen `git rebase` niet, maar ondersteunen workflows waarin het commando regelmatig wordt gebruikt.

De kernvraag blijft: wilt u een geschiedenis die precies weergeeft wat er is gebeurd, of een geschiedenis die weergeeft wat er had moeten gebeuren?