Git Rebase: hoe het werkt en waarom je het zou moeten gebruiken

In het versiebeheersysteem Git zijn er twee manieren om één branch met een andere te combineren, vertegenwoordigd door verschillende commando’s:

• git merge. Commits van de ene branch worden overgebracht naar een andere door een merge commit te maken.

• git rebase. Commits van de ene branch worden overgebracht naar een andere branch terwijl de oorspronkelijke volgorde van wijzigingen behouden blijft.

Eenvoudig gezegd: met git merge worden de commits van een branch “samengevoegd” tot één commit, terwijl ze met git rebase ongewijzigd blijven, maar de branches toch worden gecombineerd.

Het git rebase-commando maakt het dus mogelijk om de commits van beide branches te combineren en een gedeelde wijzigingsgeschiedenis te vormen.

Deze gids behandelt het git rebase-commando, dat verantwoordelijk is voor het herbaseren (rebasen) van commits (wijzigingen) van de ene branch naar een andere.

Alle voorbeelden in deze gids gebruiken Git versie 2.34.1, uitgevoerd op een Hostman-server met het Ubuntu 22.04-besturingssysteem.

Je kunt deze handleidingen gebruiken om Git op je machine te installeren:

• Installing Git on Ubuntu
• Installing Git on Windows

Wat is Git Rebase

Git Rebase is een krachtig Git-commando dat voornamelijk wordt gebruikt om wijzigingen van de ene branch in een andere te integreren door de commitgeschiedenis te herschrijven. In tegenstelling tot git merge, dat een nieuwe merge commit maakt om branches te combineren en de geschiedenis van beide behoudt, werkt git rebase door een reeks commits van de ene branch naar een andere te verplaatsen of te “herhalen”. Dit proces resulteert in een lineaire geschiedenis, waardoor het lijkt alsof de feature branch rechtstreeks is ontwikkeld vanaf de meest recente commit van de doelbranch, zoals main of master. Op deze manier wordt de commitgeschiedenis opgeschoond en worden onnodige merge commits verwijderd, wat leidt tot een overzichtelijkere projectgeschiedenis.

Hoe Git Rebase werkt

De beste manier om te begrijpen hoe rebasing in Git werkt, is door naar een abstracte repository met meerdere branches te kijken en de rebase-operatie stap voor stap te analyseren.

Branches aanmaken

Laten we aannemen dat we een repository hebben gemaakt met één enkele branch, master, die slechts één commit bevat. De master-branch ziet er als volgt uit:

master
  commit_1

Vervolgens hebben we op basis van master een nieuwe branch aangemaakt, hypothesis, waarin we enkele functies wilden testen. In deze nieuwe branch hebben we meerdere commits gemaakt om de code te verbeteren. De branch ziet er nu als volgt uit:

hypothesis
  commit_4
  commit_3
  commit_2
  commit_1

Later hebben we nog een commit toegevoegd aan de master-branch om een kwetsbaarheid dringend te verhelpen. De master-branch ziet er nu als volgt uit:

master
  commit_5
  commit_1

Onze repository bevat nu twee branches:

master
  commit_5
  commit_1

hypothesis
  commit_4
  commit_3
  commit_2
  commit_1

De master-branch is de hoofdbranch, terwijl hypothesis een secundaire (afgeleide) branch is. Latere commits worden boven eerdere vermeld, vergelijkbaar met de uitvoer van het commando git log.

Branches samenvoegen

Stel dat we willen doorgaan met werken aan de functie die we eerder naar de aparte branch hypothesis hebben verplaatst. Deze branch bevat echter niet de kritieke bugfix die we in master hebben aangebracht.

Daarom willen we de toestand van hypothesis synchroniseren met master zodat de fix-commit ook in de feature branch verschijnt. Met andere woorden, we willen dat de repositorystructuur er als volgt uitziet:

master
  commit_5
  commit_1

hypothesis
  commit_4
  commit_3
  commit_2
  commit_5
  commit_1

Zoals je kunt zien, herhaalt de branch hypothesis nu exact de geschiedenis van master, ook al is hij oorspronkelijk vóór commit_5 aangemaakt. Met andere woorden: hypothesis bevat nu de geschiedenis van beide branches — die van zichzelf en die van master.

Om dit te bereiken, moeten we een rebase uitvoeren met het commando git rebase.

Daarna kunnen de wijzigingen in hypothesis worden samengevoegd met master via het klassieke git merge-commando, dat een merge commit maakt.

De repositorystructuur ziet er daarna als volgt uit:

master
  commit_merge
  commit_5
  commit_1

hypothesis
  commit_4
  commit_3
  commit_2
  commit_5
  commit_1

Bovendien kan het uitvoeren van git merge na git rebase de kans op conflicten verkleinen.

Praktijk: git rebase

Nu we het theoretische aspect van het git rebase-commando hebben behandeld, kunnen we overgaan tot het testen ervan in een echte repository van een voorbeeldproject. De repositorystructuur zal dezelfde zijn als in het eerdere theoretische voorbeeld.

Een repository aanmaken

Laten we eerst een aparte map maken om de repository in te plaatsen:

mkdir rebase

Ga er vervolgens in:

cd rebase

We kunnen nu de repository initialiseren:

git init

In de console verschijnt een standaard informatief bericht:

hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
...

In de huidige map verschijnt een verborgen map genaamd .git, die je kunt bekijken met het volgende commando:

ls -a

De vlag -a betekent all en maakt het mogelijk om het bestandssysteem in uitgebreide modus te bekijken. De inhoud zal zijn:

.  ..  .git

Voordat we commits maken, moeten we enkele basisgebruikersgegevens instellen.

Eerst de naam:

git config --global user.name "NAME"

Daarna het e-mailadres:

git config --global user.email "NAME@HOST.COM"

De master-branch vullen

Met behulp van eenvoudige tekstbestanden zullen we het toevoegen van verschillende functies aan het project simuleren. Elke nieuwe functie wordt weergegeven als een afzonderlijke commit.

Maak een bestand voor de eerste geïmproviseerde functie:

nano function_1

Voeg de volgende inhoud toe:

Function 1

Indexeer vervolgens de aangebrachte wijzigingen in de repository:

git add .

Controleer voor de zekerheid de indexstatus:

git status

In de console verschijnt het volgende bericht, waarin de geïndexeerde wijzigingen worden weergegeven:

On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   function_1

We kunnen nu committen:

git commit -m "commit_1"

De console toont een bericht dat de succesvolle commit in master bevestigt:

[master (root-commit) 4eb7cc3] commit_1
 1 file changed, 1 insertion(+)
 create mode 100644 function_1

De hypothesis-branch vullen

Laten we nu een nieuwe branch maken met de naam hypothesis:

git checkout -b hypothesis

De vlag -b zorgt ervoor dat we direct overschakelen naar de nieuwe branch.

De console geeft een bevestigingsbericht weer:

Switched to a new branch 'hypothesis'

Vervolgens maken we drie opeenvolgende commits met drie bestanden, vergelijkbaar met master:

• commit_2 met bestand function_2 en inhoud: Function 2
• commit_3 met bestand function_3 en inhoud: Function 3
• commit_4 met bestand function_4 en inhoud: Function 4

Als we vervolgens de lijst met commits controleren:

git log --oneline

De console toont de volgende volgorde:

d3efb82 (HEAD -> hypothesis) commit_4
c9f57b7 commit_3
c977f16 commit_2
4eb7cc3 (master) commit_1

Hier wordt de vlag --oneline gebruikt om de commitinformatie in verkorte vorm weer te geven.

Een commit toevoegen aan de master-branch

De laatste stap is om nog een commit toe te voegen aan de hoofdbranch master. Laten we daar naartoe schakelen:

git checkout master

De console bevestigt de overschakeling:

Switched to branch 'master'

Maak nu een nieuw bestand aan voor een extra functie:

nano function_5

Met de volgende inhoud:

Function 5

Indexeer de aangebrachte wijzigingen:

git add .

Maak vervolgens de nieuwe commit aan:

git commit -m "commit_5"

Als we de lijst met commits controleren:

git log --oneline

De master-branch heeft nu twee commits:

3df7a00 (HEAD -> master) commit_5
4eb7cc3 commit_1

Branches samenvoegen met git rebase

Om een rebase uit te voeren, moet je eerst overschakelen naar de hypothesis-branch:

git checkout hypothesis

Voer vervolgens de rebase uit:

git rebase master

Daarna geeft de console een bericht weer dat de succesvolle rebase bevestigt:

Successfully rebased and updated refs/heads/hypothesis.

Controleer nu de lijst met commits:

git log --oneline

De console toont een lijst met de commits van beide branches in hun oorspronkelijke volgorde:

8ecfd58 (HEAD -> hypothesis) commit_4
f715aba commit_3
ee47470 commit_2
3df7a00 (master) commit_5
4eb7cc3 commit_1

De hypothesis-branch bevat nu de volledige geschiedenis van de repository.

Conflicten oplossen

Net als bij git merge kunnen er tijdens het gebruik van het git rebase-commando conflicten optreden die handmatig moeten worden opgelost.

Laten we onze repository zo aanpassen dat we opzettelijk een rebase-conflict creëren.

Maak een nieuw bestand in de hypothesis-branch:

nano conflict

Voeg de volgende tekst toe:

There must be a conflict here!

Indexeer de wijziging:

git add .

Maak de commit aan:

git commit -m "conflict_1"

Schakel nu over naar de master-branch:

git checkout master

Maak een vergelijkbaar bestand aan:

nano conflict

Met de volgende inhoud:

There must NOT be a conflict here!

Indexeer de wijziging:

git add .

Maak de commit aan:

git commit -m "conflict_2"

Open het aangemaakte bestand opnieuw:

nano conflict

Wijzig de inhoud in:

There definitely must NOT be a conflict here!

Indexeer opnieuw de wijzigingen:

git add .

Maak nog een commit:

git commit -m "conflict_3"

Schakel nu terug naar de hypothesis-branch:

git checkout hypothesis

Voer de rebase opnieuw uit:

git rebase master

De console zal een conflictmelding weergeven:

Auto-merging conflict
CONFLICT (add/add): Merge conflict in conflict
error: could not apply 6003ed7... conflict_1
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 6003ed7... conflict_1

Git stelt voor om het conflicterende bestand te bewerken, de wijzigingen te indexeren met git add en vervolgens de rebase voort te zetten met de optie --continue.

Dat is precies wat we gaan doen:

nano conflict

Het bestand bevat twee conflicterende versies die tussen speciale markeringen staan:

<<<<<<< HEAD
There definitely must NOT be a conflict here!
=======
There must be a conflict here!
>>>>>>> 6003ed7 (conflict_1)

Onze taak is om de onnodige delen te verwijderen en het bestand in te vullen met een uiteindelijke versie van de tekst:

There must absolutely definitely unanimously NOT be any conflict here!

Indexeer vervolgens de wijzigingen:

git add .

Ga verder met de rebase:

git rebase --continue

Daarna opent de console een teksteditor waarin wordt voorgesteld om het oorspronkelijke commitbericht te wijzigen van de commit waarin het conflict optrad:

conflict_1

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# interactive rebase in progress; onto bd7aefc
# Last commands done (4 commands done):
#    pick 8ecfd58 commit_4
#    pick 6003ed7 conflict_1
# No commands remaining.
# You are currently rebasing branch 'hypothesis' on 'bd7aefc'.
#
# Changes to be committed:
#       modified:   conflict
#

De console zal vervolgens een bericht tonen dat bevestigt dat het rebase-proces succesvol is voltooid:

[detached HEAD 482db49] conflict_1
 1 file changed, 1 insertion(+), 1 deletion(-)
Successfully rebased and updated refs/heads/hypothesis.

Controleer nu de lijst met commits in de hypothesis-branch:

git log --oneline

Je zult de oorspronkelijke volgorde van alle aangebrachte wijzigingen zien:

482db49 (HEAD -> hypothesis) conflict_1
bd5d036 commit_4
407e245 commit_3
948b41c commit_2
bd7aefc (master) conflict_3
d98648d conflict_2
3df7a00 commit_5
4eb7cc3 commit_1

Merk op dat de commits conflict_2 en conflict_3, die in de master-branch zijn gemaakt, eerder in de geschiedenis verschijnen dan conflict_1. Dit geldt echter voor alle commits die in de master-branch zijn gemaakt.

Rebase van een externe repository

Naast het werken met lokale branches, kan rebasen ook worden uitgevoerd bij het ophalen van wijzigingen uit een externe repository. Om dit te doen, moet je de optie --rebase toevoegen aan het standaard pull-commando:

git pull --rebase remote branch

Waarbij:

• remote de externe repository is

• branch de externe branch is

In wezen is deze pull-configuratie gelijk aan git rebase, behalve dat de wijzigingen (commits) die op de huidige branch worden toegepast afkomstig zijn uit de externe repository.

Belangrijkste voordelen van Git Rebase

• Lineariteit 

Het git rebase-commando maakt het mogelijk om een vrij lineaire geschiedenis van de doelbranch te vormen, bestaande uit opeenvolgende commits. Een dergelijke opeenvolging zonder vertakkingen maakt de geschiedenis gemakkelijker te begrijpen en te analyseren.

• Minder conflicten 

Het uitvoeren van git rebase vooraf kan de kans op conflicten bij het samenvoegen van branches met git merge aanzienlijk verkleinen. Conflicten zijn gemakkelijker op te lossen in opeenvolgende commits dan in commits die zijn samengevoegd tot één enkele merge commit. Dit is vooral relevant bij het pushen van branches naar externe repositories.

Nadelen van Git Rebase

• Wijziging van de geschiedenis 

In tegenstelling tot merge, herschrijft rebase gedeeltelijk de geschiedenis van de doelbranch en verwijdert onnodige elementen uit de geschiedenis.

• Risico op fouten 

De mogelijkheid om de commitgeschiedenis aanzienlijk te herstructureren kan leiden tot onherstelbare fouten in de repository. Dit betekent dat sommige gegevens permanent verloren kunnen gaan.

Wanneer Git Rebase gebruiken

Git rebase is bijzonder nuttig bij het werken aan kleine of individuele feature branches die uiteindelijk in een gedeelde hoofdbranch zullen worden samengevoegd. Het is ook uitstekend voor het schoon en lineair houden van de geschiedenis, wat vooral gunstig is bij open-sourceprojecten of wanneer je de commitgeschiedenis van een project moet behouden voor eenvoudig debuggen en beter begrip.

In teamomgevingen met meerdere bijdragers moet rebase echter voorzichtig worden gebruikt om problemen te voorkomen die verband houden met het herschrijven van openbare geschiedenis. Het is belangrijk om met je team te communiceren over wanneer rebasen gepast is en ervoor te zorgen dat iedereen zich bewust is van het potentiële risico op conflicten. In veel gevallen kan het gebruik van git merge voor het integreren van branches veiliger en eenvoudiger zijn, vooral wanneer wordt gewerkt aan gedeelde branches of wanneer een niet-lineaire geschiedenis acceptabel is.

Belangrijke overwegingen

• Herschrijven van de geschiedenis

Een van de belangrijkste aspecten van git rebase is dat het de commitgeschiedenis herschrijft, wat betekent dat de SHA-1-hashes van de gerebaseerde commits veranderen. Dit kan problemen veroorzaken in samenwerkingsomgevingen, vooral wanneer je een branch rebase die al naar een gedeelde externe repository is gepusht. Het herschrijven van de geschiedenis kan leiden tot conflicten met andere ontwikkelaars die hun werk hebben gebaseerd op de vorige geschiedenis. Het kan ook problemen veroorzaken bij het pushen van de gerebaseerde branch, omdat de externe repository zal detecteren dat de lokale geschiedenis niet langer overeenkomt met de externe.

• Vermijd het rebasen van openbare branches

Een veelgebruikte best practice is om te voorkomen dat je openbare branches rebase die al met anderen zijn gedeeld. Omdat rebase de commitgeschiedenis verandert, kan het rebasen van openbare branches waarop meerdere ontwikkelaars vertrouwen leiden tot uiteenlopende geschiedenissen, verwarring en moeilijk op te lossen mergeconflicten. Over het algemeen is git rebase het meest geschikt voor lokale branches of voor het voorbereiden van een feature branch op een definitieve samenvoeging in een hoofdbranch. Openbare branches, vooral die waar meerdere mensen aan werken, moeten meestal worden samengevoegd in plaats van gerebased.

• Potentiële conflicten

Tijdens een rebase, als er conflicterende wijzigingen zijn in zowel de feature branch als de doelbranch, zal Git stoppen en vragen om het conflict handmatig op te lossen. Hoewel het oplossen van conflicten tijdens een rebase vergelijkbaar is met dat tijdens een merge, vereist rebasen dat je conflicten oplost voor elke commit die opnieuw moet worden toegepast, wat het proces vervelender kan maken, vooral bij grote feature branches. Zodra de conflicten zijn opgelost, kun je de rebase voortzetten met het commando git rebase --continue.

Conclusie

Het samenvoegen van twee branches met behulp van rebase, geïmplementeerd met het git rebase-commando, verschilt fundamenteel van de klassieke merge die wordt uitgevoerd met het git merge-commando.

• git merge verandert de commits van een branch in één enkele commit in een andere.

• git rebase verplaatst commits van de ene branch naar het einde van een andere terwijl de oorspronkelijke volgorde behouden blijft.

Een vergelijkbaar rebase-effect kan ook worden bereikt door het gebruik van het git pull-commando met de extra optie --rebase.

Aan de ene kant stelt het git rebase-commando je in staat een schonere en beter te begrijpen commitgeschiedenis te creëren in de hoofdbranch, wat de onderhoudbaarheid van de repository verhoogt.

Aan de andere kant vermindert git rebase het detailniveau van de wijzigingen binnen de branch, vereenvoudigt de geschiedenis en verwijdert sommige van de vermeldingen.

Om deze reden is rebasen een functie die bedoeld is voor meer ervaren gebruikers die begrijpen hoe Git werkt.

Meestal wordt het git rebase-commando samen met het git merge-commando gebruikt, waardoor je een zo optimaal mogelijke repository- en branchstructuur kunt bereiken.