Samenvoegen (merge) — wat is het, hoe werkt merge en samenvoegstrategieën

Wat is merge in Git

Merge — dit is het git merge commando dat wijzigingen van de opgegeven tak in de huidige tak samenvoegt. Git vindt de gemeenschappelijke voorouder (gemeenschappelijke base commit), berekent de diff van elke tak ten opzichte van de voorouder en creëert een merge-commit die de gecombineerde set wijzigingen bevat. Resultaat — de doeltak wordt aangevuld met alle wijzigingen uit de samengevoegde tak.

Syntax: terwijl je in de doeltak bent (bijv. main), voer git merge feature uit. Git maakt automatisch een merge-commit aan, als er geen conflicten zijn. In het standaardbericht van de merge-commit staat: „Merge branch ’feature’ into main“. Het bericht kan worden gewijzigd via de -m vlag of worden bewerkt in de geopende editor.

Merge is een niet-destructieve operatie. In tegenstelling tot rebase raakt merge bestaande commits niet aan: ze blijven met dezelfde hashes, auteurs en data. Dit maakt merge de enige veilige manier van samenvoegen voor takken waar meerdere ontwikkelaars tegelijk aan werken. Als er iets misgaat, kan merge worden geannuleerd met het commando git merge --abort.

# Schakel naar doeltak
git checkout main

# Feature-tak samenvoegen
git merge feature

# Resultaat — merge-commit met twee ouders
git log --oneline --graph

# Samenvoegen met aangepast bericht
git merge feature -m "feat: integrate authentication module"

Soorten merge: regular, squash, fast-forward

Git ondersteunt drie samenvoegmodi, die worden gekozen afhankelijk van het gewenste resultaat. Regular merge (standaard) creëert een merge-commit. Squash merge voegt alle commits van de feature-tak samen in één. Fast-forward — verplaatst de takwijzer zonder een commit te creëren, indien mogelijk. De keuze van de modus hangt af van de workflow van het team en de geschiedenisregels.

Regular merge (--no-ff) — creëert een merge-commit, zelfs als de samenvoeging als fast-forward kan worden uitgevoerd. Aanbevolen voor de main-tak: de merge-commit markeert expliciet het moment van integratie van de feature en maakt het mogelijk om alle wijzigingen van de feature-tak eenvoudig terug te draaien met één revert van de merge-commit. GitHub gebruikt deze modus standaard bij het samenvoegen van PR’s via de Merge-knop.

Squash merge (--squash) — verzamelt alle commits van de feature-tak in één commit in de doeltak. Nuttig wanneer de ruwe geschiedenis van de feature-tak niet in main terecht mag komen. Nadeel: de verbinding met de originele commits gaat verloren — je kunt niet zien hoe de feature stap voor stap is ontwikkeld. GitHub gebruikt deze modus bij het kiezen van „Squash and merge“ in een PR.

Fast-forward (--ff) — als de doeltak geen nieuwe commits heeft na het aftakken van de feature, verplaatst Git eenvoudigweg de wijzer vooruit, zonder een merge-commit te creëren. De geschiedenis blijft lineair. De --no-ff vlag forceert het creëren van een merge-commit, --ff-only eindigt met een fout als fast-forward niet mogelijk is.

# Forceer merge-commit (aanbevolen voor main)
git merge --no-ff feature

# Squash merge — alle commits in één
git merge --squash feature
git commit -m "feat: add authentication"

# Fast-forward alleen indien mogelijk
git merge --ff-only feature

# Conflicterende merge annuleren
git merge --abort

Git samenvoegstrategieën

Samenvoegstrategieën bepalen het algoritme dat Git gebruikt om wijzigingen te combineren. Elke strategie is geschikt voor verschillende scenario’s. Git kiest automatisch de juiste strategie, maar de ontwikkelaar kan deze expliciet aangeven via de --strategy vlag. Inzicht in strategieën helpt om het gedrag van Git bij complexe samenvoegingen te voorspellen.

Recursive — de standaardstrategie voor het samenvoegen van twee takken. Git vindt de gemeenschappelijke voorouder, berekent de wijzigingen in elke tak en combineert ze. Als de gemeenschappelijke voorouder wordt gevonden, verwerkt recursive correct het hernoemen van bestanden en het toevoegen van nieuwe. Bij conflicten kan recursive extra opties gebruiken: ours (automatisch onze versie selecteren) en theirs (hun versie selecteren).

Octopus — voor gelijktijdige samenvoeging van meer dan twee takken: git merge feature1 feature2 feature3. Octopus ondersteunt geen conflictoplossing — alle conflicten moeten worden opgelost voordat het commando wordt aangeroepen. Zelden gebruikt, voornamelijk voor het combineren van meerdere onafhankelijke takken die gegarandeerd niet conflicteren (bijv. verschillende modules).

Ours — een speciale strategie die wijzigingen uit de samengevoegde tak volledig negeert en de huidige inhoud van de doeltak behoudt. De merge-commit wordt aangemaakt, maar de inhoud blijft ongewijzigd. Nuttig wanneer je in de geschiedenis het feit van samenvoegen moet vastleggen, maar feitelijk alle wijzigingen uit de externe tak wilt afwijzen.

Merge-conflicten oplossen

Merge-conflict ontstaat wanneer dezelfde regels van een bestand in beide takken op verschillende manieren zijn gewijzigd. Git kan niet automatisch bepalen welke versie correct is en pauzeert de merge. Het conflict kan ook ontstaan bij het hernoemen van een bestand in de ene tak en het wijzigen ervan in de andere, of bij het gelijktijdig verwijderen en wijzigen van hetzelfde bestand.

Het oplossingsproces: Git markeert conflicterende bestanden met markers. In het bestand verschijnen secties met <<<<<<< HEAD (onze versie), ======= (scheidingsteken) en >>>>>>> feature (hun versie). De ontwikkelaar bewerkt handmatig het conflictgedeelte, selecteert de benodigde regels uit beide versies, verwijdert de markers, slaat het bestand op en voegt het toe aan de index via git add.

Voor visuele conflictoplossing ondersteunt Git mergetool — een extern vergelijkingsinstrument. Populaire mergetool-instrumenten: Meld, KDiff3, Beyond Compare, VS Code (ingebouwde conflicteditor). Mergetool toont drie panelen: onze versie, hun versie en het resultaat. De ontwikkelaar selecteert visueel de codeblokken voor opname in het uiteindelijke bestand.

# Start merge en detecteer conflict
git merge feature
# CONFLICT (inhoud): Merge-conflict in src/main.swift

# Controleer conflicterende bestanden
git status

# Open visuele mergetool
git mergetool

# Na oplossing — toevoegen en committen
git add src/main.swift
git commit

# Merge annuleren
git merge --abort

Wanneer merge kiezen in plaats van rebase

Merge heeft de voorkeur boven rebase in een aantal belangrijke situaties. Ten eerste: bij het werken met openbare takken die toegankelijk zijn voor andere ontwikkelaars. Merge overschrijft de geschiedenis niet en collega’s kunnen veilig synchroniseren. Rebase in een openbare tak zal een uiteenlopende geschiedenis en conflicten creëren voor iedereen die al de oude commits heeft ontvangen.

De tweede situatie: bij het voltooien van een feature-tak. De meeste teams geven de voorkeur aan merge (met de --no-ff vlag) in main om het moment van integratie van de feature vast te leggen. Dit vereenvoudigt de navigatie door de geschiedenis en maakt het mogelijk om de hele feature eenvoudig terug te draaien met één git revert van de merge-commit. GitHub Flow biedt standaard drie merge-opties: eenvoudige merge, squash merge en rebase merge.

De derde situatie: bij het werken met een pull request dat is gereviewd. GitHub en GitLab bieden een merge-knop met verschillende opties. Merge (Create a merge commit) — volledige geschiedenis met merge-commit. Squash and merge — schone geschiedenis zonder ontwikkelingsdetails. Rebase and merge — lineaire geschiedenis zonder merge-commit, maar met overschrijving van commits. De keuze hangt af van de teamregels.

• Openbare takken (main, develop) — alleen merge, nooit rebase.
• PR voltooien — merge met --no-ff voor het vastleggen van het integratiemoment.
• Takken met andermans commits — merge overschrijft andermans werk niet.
• Voor een release — merge is veiliger, omdat het minder risico’s met zich meebrengt.
• Gedeelde tak — als meerdere ontwikkelaars aan de tak werken, is merge verplicht.

Beste praktijken voor het samenvoegen van takken

Eerste regel: wees altijd op de actuele versie van de doeltak voor de merge. Voer git checkout main && git pull uit voordat je de feature samenvoegt. Dit minimaliseert conflicten en garandeert dat de merge-commit alle actuele wijzigingen bevat. Als de doeltak ver vooruit is, voer dan eerst git merge main uit binnen de feature-tak om conflicten in de context ervan op te lossen.

Tweede regel: test de code na de merge. Merge kan het gedrag veranderen, zelfs als er geen conflicten waren. De CI/CD-pijplijn moet tests uitvoeren op de merge-commit voordat deze naar productie wordt gestuurd. Sommige teams gebruiken merge gates — verplichte controles die de merge blokkeren tot ze zijn doorstaan.

Derde regel: documenteer merge-commits. Het standaardbericht „Merge branch ’feature’ into main“ is weinig nuttig. Het wordt aanbevolen om een beschrijving toe te voegen van wat is samengevoegd: „Merge authentication module: login, registration, password recovery“. Dit vereenvoudigt de analyse van de geschiedenis en het zoeken naar regressies. In grote projecten worden merge-commits automatisch gegenereerd uit de naam van de PR.

• Actualiteit — voor de merge, zorg dat de doeltak is bijgewerkt (git pull).
• Testen — CI/CD moet tests uitvoeren op de resulterende merge-commit.
• Beschrijvende berichten — vermeld in de merge-commit welke feature is samengevoegd.
• Frequentie — voeg feature-takken zo vroeg en vaak mogelijk samen (maximaal een week).
• Ongedaan maken — git revert van de merge-commit draait de hele feature volledig terug.