Branch-hes samenvoegen — wat het is, methoden van samenvoegen en conflictoplossing

Wat is merge in Git

Merge in Git — is de bewerking van het samenvoegen van twee of meer ontwikkelingsgeschiedenissen in één. Wanneer een ontwikkelaar een branch merged, vindt Git automatisch de gemeenschappelijke voorouder (base commit) en maakt een nieuwe merge-commit die de wijzigingen van beide branches bevat. Three-way merge — het standaardalgoritme dat drie toestanden vergelijkt: de gemeenschappelijke voorouder, de eerste branch en de tweede branch.

Het merge-proces begint met het commando git merge. Git bepaalt het punt waar de branches uiteenliepen en past de wijzigingen van de bronbranch sequentieel toe op de doelbranch. Als de wijzigingen niet conflicteren, voert Git fast-forward uit of maakt een merge-commit, afhankelijk van de instellingen. Fast-forward — het scenario waarbij de doelbranch eenvoudigweg wordt verplaatst naar de commits van de bronbranch.

# Schakel naar doelbranch en voeg samen
git checkout main
git merge feature/payment-module

# Voeg samen met expliciete no-fast-forward
git merge --no-ff feature/payment-module

# Breek samenvoeging af als conflicten te complex zijn
git merge --abort

De vlag --no-ff (no fast-forward) forceert het maken van een merge-commit, zelfs wanneer fast-forward mogelijk is. Dit bewaart de informatie dat de wijzigingen in een aparte branch zijn gemaakt. Veel teams geven de voorkeur aan deze aanpak om de vertakking van de geschiedenis expliciet te behouden.

Manieren van branch-samenvoeging

In Git bestaan drie hoofdstrategieën voor het samenvoegen van branches, elk geschikt voor een specifiek scenario. De keuze van de strategie hangt af van de teamcultuur en de vereisten voor de zuiverheid van de projectgeschiedenis.

Standard merge maakt een merge-commit met twee ouders. De volledige geschiedenis blijft behouden, maar de vertakkingsgraaf wordt complexer. Squash merge combineert alle commits van de feature-branch in één en past deze toe op de doelbranch — de geschiedenis wordt lineair en schoon, maar informatie over tussenliggende stappen gaat verloren.

Rebase, hoewel geen volwaardige merge, bereikt hetzelfde resultaat — wijzigingen van de ene branch worden overgebracht naar de andere. Het verschil is dat de geschiedenis wordt herschreven: commits van de feature-branch worden opnieuw gemaakt bovenop de laatste commit van de doelbranch. Dit geeft een perfect lineaire geschiedenis, maar vereist force push bij het verzenden.

Hoe conflicten oplossen bij mergen

Een conflict bij mergen ontstaat wanneer in twee branches dezelfde regels van een bestand zijn gewijzigd. Git kan niet automatisch bepalen welke versie behouden moet worden en vereist tussenkomst van de ontwikkelaar. Conflicten worden in bestanden weergegeven als speciale markers: <<<<<<<, =======, >>>>>>>.

Het conflictoplossingsproces omvat verschillende stappen. Eerst opent de ontwikkelaar het conflicterende bestand en kiest handmatig de gewenste wijzigingen. Het is belangrijk om niet simpelweg een van de versies te kiezen, maar de logica van beide wijzigingen te begrijpen en een correcte beslissing te nemen. Na het bewerken van het bestand worden de conflictmarkers verwijderd en worden de wijzigingen via git add aan de staging area toegevoegd.

# Bekijk lijst van conflicterende bestanden
git status

# Start mergetool (bijv. VS Code, IntelliJ)
git mergetool

# Na het oplossen van alle conflicten
git add .
git merge --continue

# Of breek de samenvoeging volledig af
git merge --abort

Het gebruik van visuele merge-tools versnelt het oplossen van conflicten aanzienlijk. VS Code, IntelliJ IDEA en GitKraken bieden interfaces met drie panelen: huidige branch, inkomende branch en resultaat. De tool git mergetool opent automatisch de geconfigureerde editor voor elk conflicterend bestand.

De beste manier om complexe conflicten te voorkomen is regelmatige synchronisatie van de feature-branch met de hoofdbranch. Als de ontwikkelaar dagelijks main in zijn eigen branch merged, zullen conflicten klein en gemakkelijk oplosbaar zijn. Ophoping van wijzigingen gedurende een week garandeert complexe conflicten met een hoog risico op fouten.

Wanneer rebase gebruiken in plaats van merge

Rebase en merge — twee manieren om wijzigingen te combineren, en de keuze ertussen veroorzaakt vaak discussies in teams. Rebase verplaatst commits van de ene branch naar de andere en herschrijft de geschiedenis. Merge maakt een nieuwe merge-commit en behoudt de vertakkingsgeschiedenis. Elke benadering heeft zijn voor- en nadelen.

Rebase is geschikt wanneer een ontwikkelaar in zijn lokale feature-branch werkt en een schone lineaire geschiedenis wil krijgen voordat hij een Pull Request maakt. Na rebase worden alle commits sequentieel gerangschikt, zonder overbodige merge-commits. Rebase vereist echter force push en is niet toepasbaar op branches waar meerdere mensen tegelijkertijd aan werken.

• Rebase — voor persoonlijke feature-branches waar een schone geschiedenis nodig is
• Merge — voor gedeelde branches en het vastleggen van het samenvoegingsmoment
• Squash — wanneer de feature-branch veel kleine werk-commits bevat

De gouden regel van Git: gebruik geen rebase op commits die al naar de gedeelde repository zijn gepusht. Dit garandeert dat de geschiedenis in de gedeelde branch onveranderd blijft en andere ontwikkelaars geen dubbele of verloren commits tegenkomen. Voor integratie van de feature-branch in de hoofdbranch gebruik je merge via Pull Request.

Beste praktijken voor branch-samenvoeging

Het juiste merge-proces — de basis van stabiele ontwikkeling. In modern teamwerk wordt merge niet via de console uitgevoerd, maar via Pull Request op GitHub of Merge Request in GitLab. Een PR doorloopt code-review, automatische CI-controles en wordt pas daarna in de hoofdbranch gemerged.

Eerste praktijk — merge alleen na het doorstaan van alle controles. De CI-pipeline moet het project bouwen, tests uitvoeren en de codekwaliteit controleren. Als zelfs maar één controle niet is geslaagd, wordt de merge geblokkeerd. Moderne platforms (GitHub, GitLab) hebben ingebouwde bescherming: branch protection rules blokkeren automatisch merge bij CI-falen.

Tweede praktijk — merge nooit kapotte code. Voor het mergen moet de ontwikkelaar ervoor zorgen dat zijn wijzigingen de build niet breken en bestaande functionaliteit niet regresseren. Hiervoor bestaan geautomatiseerde tests en code-review.

Derde praktijk — ruim feature-branches op na het mergen. Een branch die al is gemerged, moet worden verwijderd. Dit voorkomt verwarring en rommel in de repository. GitHub biedt automatisch aan om de branch te verwijderen na het mergen van een PR, en de repository-instellingen kunnen worden geconfigureerd voor automatische verwijdering.