Wanneer een git merge conflict op je scherm verschijnt, is de eerste reactie van veel ontwikkelaars paniek — terwijl een conflict eigenlijk Git's manier is om je te helpen. Git merkt dat dezelfde regels op twee branches anders zijn gewijzigd en kan niet bepalen welke versie juist is, dus het stopt en geeft de beslissing aan jou terug. Deze gids legt stap voor stap uit waarom conflicten ontstaan, hoe je de markeringen in je terminal leest en hoe je het bestand veilig opschoont.
Wat is een merge conflict precies?
Git voegt wijzigingen regel voor regel samen. Wanneer twee branches verschillende delen van hetzelfde bestand raken, combineert Git ze moeiteloos. Een conflict ontstaat alleen wanneer dezelfde regels (of regels die dicht bij elkaar liggen) op beide branches anders zijn bewerkt, of wanneer de ene kant verwijderde wat de andere wijzigde. Dan vraagt Git: "er zijn hier twee mogelijke waarheden, welke wil je?"
Conflicten kunnen bij vrijwel al deze commando's opduiken: git merge, git rebase, git pull (dat intern een merge of rebase uitvoert), git cherry-pick en git stash pop. Het mechanisme is overal hetzelfde, dus zodra je er één kunt oplossen, kun je ze allemaal oplossen.
Het conflict lezen: wat de markeringen betekenen
Als je een bestand met conflict opent, zie je drie markeringen die Git heeft toegevoegd:
<<<<<<< HEAD
const timeout = 5000;
=======
const timeout = 10000;
>>>>>>> feature/login
- Tussen
<<<<<<< HEADen=======: jouw kant (de branch waarop je zit, "ours"). - Tussen
=======en>>>>>>>: de binnenkomende kant, de branch die je samenvoegt ("theirs"). - Het label aan het eind (
feature/login) vertelt waar de conflicterende wijziging vandaan komt.
Eén belangrijk detail: tijdens een rebase is de betekenis van "ours" en "theirs" omgedraaid, omdat rebase jouw commits opnieuw afspeelt bovenop de doelbranch. Dus HEAD staat voor de doelbranch en het onderste blok bevat jouw wijziging. Houd dit in gedachten als je via de command line oplost.
Stap voor stap oplossen
Hier is een veilige, herhaalbare werkwijze:
- Bekijk de status. Voer
git statusuit; het toont de conflicterende bestanden onder de kop "Unmerged paths". - Open elk conflicterend bestand. Zoek elk markeringsblok. Je hebt drie opties: jouw kant houden, de binnenkomende kant houden, of beide handmatig samenvoegen.
- Schrijf het juiste resultaat. Je moet de drie markeringsregels (
<<<<<<<,=======,>>>>>>>) verwijderen zodat alleen de gewenste eindcode overblijft. - Markeer het als opgelost. Stage het bestand met
git add <bestand>. - Voltooi de operatie. Ga verder met
git commitbij een merge,git rebase --continuebij een rebase, ofgit cherry-pick --continuebij een cherry-pick.
Ondersteuning vanuit de editor maakt het veel makkelijker. VS Code markeert conflicterende blokken en toont de knoppen "Accept Current Change / Accept Incoming Change / Accept Both Changes". Controleer toch vóór het klikken of het resultaat echt klopt — automatisch accepteren levert niet altijd de juiste code op.
Snelle beslissingen vanaf de command line
Soms weet je dat je één hele kant van een bestand wilt, van boven tot onder. In plaats van handmatig bewerken:
# houd volledig de versie van mijn branch voor dit bestand
git checkout --ours config/app.php
# houd volledig de versie van de binnenkomende branch
git checkout --theirs config/app.php
# stage het daarna
git add config/app.php
Wil je volledig terug naar het punt vóór het conflict, dan brengt git merge --abort (of git rebase --abort bij een rebase) je terug naar de begintoestand. Dat is de schoonste manier om opnieuw te beginnen zonder iets kapot te maken.
Conflicten vooraf verminderen
Het beste conflict is het conflict dat nooit gebeurt. Een paar gewoonten verlagen het risico merkbaar:
- Commit klein en vaak, integreer regelmatig. Een branch wekenlang weghouden van main nodigt uit tot opstapelende conflicten. Blijf actueel met
git pull --rebase. - Houd bestanden klein en gericht. Een modulaire structuur, in plaats van enorme losse bestanden, verkleint de kans dat twee mensen dezelfde regel raken.
- Let op gegenereerde bestanden. Lockbestanden zoals
composer.lockenpackage-lock.jsonbotsen vaak; ze opnieuw genereren (bijv.composer install) is veiliger dan handmatig bewerken. - Standaardiseer de opmaak. Eén gedeelde formatter in het team (Prettier, PHP-CS-Fixer) elimineert nepconflicten die alleen door inspringing of witruimte ontstaan.
Je oplossing verifiëren
Na het sluiten van een conflict is "compileert het" controleren niet genoeg. Zorg dat beide kanten van de samengevoegde wijziging hun bedoeling behielden: voer de tests uit, open de app en test handmatig het gedrag dat aan het conflictgebied hangt. De eindtoestand nog eens bekijken met git diff vóór het committen is een snelle manier om een vergeten >>>>>>>-regel of oude code die verwijderd had moeten worden te betrappen.
Veelgestelde vragen
Ik heb de verkeerde kant gehouden bij het oplossen — kan ik dat ongedaan maken?
Als je nog niet hebt gecommit, annuleert git merge --abort de hele merge zodat je opnieuw kunt beginnen. Heb je al gecommit, gebruik dan git reflog om de vorige HEAD te vinden en git reset --hard <hash> om daarheen terug te keren. Precies daarom moet je niet pushen voordat je je oplossing hebt geverifieerd.
Ik los steeds dezelfde conflicten op — is daar een oplossing voor?
Ja. Schakel rerere (reuse recorded resolution) in met git config --global rerere.enabled true. Git onthoudt hoe je een conflict hebt opgelost en past het automatisch opnieuw toe als hetzelfde terugkomt — bijzonder handig bij lange rebases.
Waarom verschillen "ours" en "theirs" tussen merge en rebase?
Bij een merge is de branch waarop je zit "ours". Bij een rebase neemt Git eerst de doelbranch als basis en speelt jouw commits daarbovenop af, dus de rollen draaien om: HEAD staat voor de doelbranch en "theirs" is jouw afgespeelde wijziging. Controleer in welk commando je zit voordat je beslist.
Vertragen conflicten je project? We kunnen samen je Git-workflow, branchingstrategie en deployproces stroomlijnen. Wil je hulp bij je project, neem dan contact met me op.