Git-branch: een gids voor branches maken, beheren en mergen

Als je ooit aan een groepsproject hebt gewerkt, weet je hoe snel alles uit de hand kan lopen wanneer meerdere mensen tegelijk dezelfde bestanden proberen bij te werken. Conflicten ontstaan, bugs sluipen erin en de voortgang valt stil. Daar komen Git-branches om de hoek kijken—niet als een geavanceerde truc, maar als de basis voor schone, parallelle ontwikkeling.

In Git is branching niet alleen aan te raden; het is de norm. Of je nu experimenteert met een nieuwe feature, een bug fixt of iemands code reviewt: met branches kun je werken zonder iemand in de weg te zitten. Je kunt dingen stukmaken, itereren en je wijzigingen vervolgens netjes integreren in de hoofdcodebase.

Deze gids loodst je door de basis van branching in Git. We beginnen met git branch en git checkout, en kijken dan nauwkeuriger naar hoe branches worden gemaakt, beheerd, gemerged en verwijderd. We bespreken ook best practices, zodat je je workflow conflictvrij houdt. Hopelijk heb je aan het einde van deze gids meer begrip dan alleen het opdreunen van commando’s: je snapt dan ook beter hoe de werkstroom in elkaar steekt. Vind je dit interessant en wil je blijven oefenen? Onze cursus Introduction to GitHub Concepts is een goed startpunt.

Git-branches begrijpen

Nu de toon is gezet, leggen we uit wat een Git-branch is. In de kern is een Git-branch geen aparte map of volledige kopie van je codebase; het is een lichtgewicht verwijzing naar een specifieke commit. Dit is een van de redenen waarom Git zich onderscheidt van oudere versiesystemen: branching is snel, goedkoop en centraal in de dagelijkse workflow.

Zie een branch als een tijdlijn. Wanneer je een nieuwe branch maakt, zeg je in feite: “Laten we vanaf hier een nieuw pad verkennen.” Al je wijzigingen leven op dit pad totdat je besluit ze al dan niet terug te mergen in de hoofdlijn. Die flexibiliteit maakt het heel eenvoudig om ideeën uit te proberen, features in isolatie te bouwen en samen te werken zonder stabiele code te verstoren.

Git houdt je huidige positie in het project bij met een speciale referentie genaamd HEAD. Wanneer je van branch wisselt, wijst HEAD naar de tip van de nieuwe branch. Dit detail achter de schermen zorgt ervoor dat Git zo snel van context kan wisselen, en verklaart ook waarom commando’s als git checkout en git switch zo naadloos aanvoelen zodra je begrijpt wat er onder de motorkap gebeurt.

Begrijp je hoe Git-branches werken, dan ontgrendel je de kracht om je ontwikkelworkflow met helderheid en vertrouwen te organiseren. Wil je meekijken en deze concepten uitproberen? DataCamp’s Intermediate Git cursus behandelt branching met veel begeleide oefening.

Git-branches weergeven en bekijken

Je hebt branches gemaakt en bent ze gaan gebruiken, maar hoe houd je het overzicht? Gelukkig biedt Git eenvoudige maar krachtige hulpmiddelen om branches te lijstten, sorteren en filteren, zodat je je workflow nooit uit het oog verliest.

De huidige branch controleren

Laten we beginnen met kijken welke branches er in je lokale repository bestaan en vaststellen op welke je nu zit.

git branch

Dit commando toont al je lokale branches. Je ziet een asterisk (*) naast je huidige branch. Voor een nog gerichtere weergave, probeer:

git branch --show-current

Dit geeft alleen de naam van de branch waarin je werkt—lekker overzichtelijk.

Wil je ook remote branches zien? Gebruik:

git branch -r

En als je zowel lokale als remote branches tegelijk wilt bekijken:

git branch -a

Dit geeft je een compleet beeld van de branchstructuur van je project, wat vooral handig is bij samenwerking op platforms als GitHub. 

Branches sorteren en filteren

Naarmate je project groeit, groeit ook je lijst met branches. Sorteren en filteren helpt je die lijst effectief te beheren. Om branches te sorteren op datum van de laatste commit, gebruik je:

git branch --sort=-committerdate

Je kunt ook sorteren op andere criteria, zoals naam van de auteur, aanmaakdatum of upstream-configuratie. Hier is een handige om te filteren op branches die een specifieke commit bevatten:

git branch --contains <commit>

Dit laat zien welke branches een bepaalde commit al hebben opgenomen, wat helpt te checken of een bugfix of feature daarin is gemerged. Omgekeerd toont het onderstaande commando welke branches die commit juist nog niet hebben opgepikt:

git branch --no-contains <commit>

Branches effectief beheren draait niet alleen om ze aanmaken, maar ook om zichtbaarheid en controle. Deze commando’s helpen je ontwikkeling schoon, georganiseerd en efficiënt te houden.

Wil je beheersen hoe dit zich verhoudt tot samenwerking? De cursus Foundations of Git biedt een uitstekend fundament en behandelt realistische workflows die je vaak gebruikt.

Een nieuwe Git-branch maken

Nu je weet hoe je tussen branches lijst en wisselt, lopen we door het aanmaken ervan. Branching is een kernonderdeel van Git’s workflow en gelukkig is het maken van nieuwe branches eenvoudig—of je nu een featurebranch, hotfix of een compleet nieuw experiment opzet.

Een branch maken zonder te wisselen

Soms wil je een branch maken zonder er meteen naartoe te gaan. Handig als je meerdere branches tegelijk voorbereidt of workflows voor anderen inricht.

git branch new-feature

Dit commando maakt een branch met de naam new-feature, maar je blijft op je huidige branch. Je kunt later overschakelen wanneer je eraan wilt werken.

Gelijktijdig een branch maken en wisselen

Als je meteen in de ontwikkeling duikt, kun je in één stap een nieuwe branch maken en ernaartoe wisselen. In oudere Git-versies gebruikte je:

git checkout -b new-feature

Maar in moderne Git is deze aanpak helderder en intuïtiever:

git switch -c new-feature

Dit creëert niet alleen de branch, maar checkt ’m ook meteen uit, zodat je direct kunt beginnen.

Upstream-branches instellen

Als je met remote repositories werkt, wil je vaak dat je lokale branch een remote branch volgt. Dat maakt pushen en pullen eenvoudiger. Om meteen een branch te maken die een remote branch volgt, gebruik je:

git branch --track new-feature origin/new-feature

Heb je de branch al gemaakt en wil je de upstream instellen of wijzigen? Gebruik dan dit commando:

git branch --set-upstream-to=origin/new-feature

Zo weet je lokale branch van welke remote branch hij moet pullen of waarnaar hij moet pushen—dat houdt je workflow soepel en verbonden.

Wisselen tussen Git-branches

Heb je meerdere branches aangemaakt, dan moet je vaak ertussen wisselen—bijvoorbeeld terug naar main om een fix te mergen of naar een featurebranch om door te coderen. Git maakt dit proces naadloos, en zoals vaak bij Git, zijn er meerdere manieren.

Met git checkout

Lange tijd was git checkout het standaardcommando om van branch te wisselen:

git checkout feature-login

Dit commando schakelt je werkdirectory over naar de feature-login-branch en werkt al je bestanden bij naar de snapshot van die branch. Het is betrouwbaar en nog steeds veelgebruikt. Maar let op: git checkout doet heel veel. Het wordt gebruikt om branches te wisselen, bestanden te herstellen en zelfs commits uit te checken. Dat kan verwarrend zijn, vooral als je net begint.

Met git switch

Om het intuïtiever te maken, introduceerde Git in versie 2.23 git switch:

git switch feature-login

Dit doet precies wat je verwacht: van branch wisselen. Het raakt je working tree niet en reset je bestanden niet, tenzij je dat expliciet aangeeft. Simpeler, veiliger en makkelijker te leren en onthouden.

Wanneer gebruik je welke?

• Gebruik git switch om tussen branches te wisselen—het is duidelijk en doelgericht.
• Gebruik git checkout als je bestanden wilt herstellen of een specifieke commit wilt bekijken.

Git-branches mergen

Je hebt aan een feature gewerkt in een aparte branch. Nu komt het erop aan: je wijzigingen combineren met de main-branch. In Git heet dit proces mergen. Afhankelijk van de geschiedenis van je branches zijn er verschillende benaderingen.

Fast-forward merge

Stel dat je feature-branch begon vanaf main en dat terwijl jij eraan werkte, niemand main heeft aangeraakt. Dan hoeft Git weinig te doen: het verplaatst simpelweg de main-pointer vooruit naar de laatste commit in feature-branch.

git checkout main
git merge feature-branch

Er wordt geen nieuwe commit gemaakt—Git voert een fast-forward uit op main. Schoon, simpel en perfect voor soloprojecten of kortstondige branches.

Three-way merge

Het wordt interessanter als beide branches onafhankelijk van elkaar zijn doorontwikkeld. Misschien heeft je teamgenoot wijzigingen toegevoegd aan main terwijl jij in feature-branch codeerde. Nu moet Git naar drie snapshots kijken: de gemeenschappelijke voorouder, jouw branch en de doelbranch.

git checkout main
git merge feature-branch

In dit geval maakt Git een nieuwe mergecommit om de twee branches te combineren. Zijn er conflicten—bijvoorbeeld jij en je teamgenoot hebben dezelfde regel in hetzelfde bestand aangepast—dan vraagt Git je die handmatig op te lossen. Je bewerkt het bestand, markeert het als opgelost en commit vervolgens de merge.

git add .
git commit

Klinkt dit wat spannend? Onze Git Merge Tutorial: A Comprehensive Guide with Examples is een uitstekende walkthrough die alle basis behandelt, inclusief het soepel afhandelen van conflicten.

Rebasen in plaats van mergen

Geen fan van mergecommits die je historie vervuilen? Je bent niet de enige. Daarvoor is git rebase. In plaats van een nieuwe mergecommit te maken, speelt rebase je wijzigingen opnieuw af boven op een andere branch, wat resulteert in een schonere, lineaire geschiedenis.

git checkout feature-branch
git rebase main

Wanneer je daarna merged, ziet Git een rechte lijn—geen mergecommit nodig. Gebruik dit echter met beleid, vooral bij gedeelde branches. Geschiedenis herschrijven kan riskant zijn als anderen aan dezelfde code werken.

Wil je weten wanneer je beter kunt mergen of rebasen (en hoe je veilig rebaset)? De Intermediate Git cursus biedt praktische, hands-on begeleiding.

Git-branches verwijderen

Na een succesvolle merge is het verstandig om branches die je niet meer nodig hebt op te ruimen, zowel lokaal als remote. Zo houd je je werkruimte netjes en is je Git-geschiedenis makkelijker te volgen. We lopen door hoe je dat doet zonder bang te hoeven zijn dat je per ongeluk iets belangrijks verwijdert.

Lokale branches verwijderen

Als een branch is gemerged en zijn taak erop zit, kun je ’m veilig uit je lokale repository verwijderen:

git branch -d feature-branch

De -d-vlag staat voor “delete”. Git controleert of de branch al is gemerged om dataverlies te voorkomen.

Maar wat als je een branch wilt verwijderen, ook als hij niet is gemerged? Dan gebruik je de hoofdletter -D:

git branch -D feature-branch

Dit dwingt verwijdering af, zelfs als Git waarschuwt dat de branch niet is gemerged. Wees zeker dat je die wijzigingen niet meer nodig hebt voordat je op enter drukt.

Op zoek naar meer diepgang in het beheren van je lokale werkruimte en branches? Bekijk onze tutorial Git Pull Force: How to Overwrite a Local Branch With Remote. Een handige aanvulling om ervoor te zorgen dat je niet alleen verwijdert, maar ook veilig beheert.

Remote branches verwijderen

Lokaal opruimen is maar de helft van het werk. Als de branch ook op een remote (zoals GitHub) bestaat, wil je ’m daar ook weghalen—zeker als je klaar bent met de feature of bugfix.

git push origin --delete feature-branch

Dit commando vertelt Git om de branch van de origin-remote te verwijderen. Het is direct en helpt te voorkomen dat je remote vervuild raakt met ongebruikte branches.

Heb je remote branches verwijderd, ruim dan ook je lokale trackingreferenties op.

git fetch -p

De -p staat voor “prune”. Hiermee verwijder je verouderde remote-trackingbranches die niet meer op de server bestaan.

Voor meer nuttige Git-hygiëne, zie de Git Push and Pull Tutorial en de Complete Git Cheat Sheet—perfecte naslagwerken.

Git-branches pushen en pullen

Heb je je branches lokaal aangemaakt en georganiseerd, dan is de volgende stap ze synchroniseren met de remote repository. Dit is essentieel voor samenwerking en back-up. We lopen door hoe je branches effectief pusht, pullt en tracked.

Een nieuwe branch naar remote pushen

Je hebt lokaal een nieuwe feature gemaakt en getest en wilt ’m nu delen met je team of back-uppen. Om een nieuwe branch naar een remote repository (meestal origin genoemd) te pushen, gebruik je:

git push -u origin new-feature

De vlag -u (kort voor --set-upstream) vertelt Git om de remote branch te onthouden voor toekomstige pulls en pushes. Zo kun je de volgende keer gewoon git pull of git push doen zonder de branch te specificeren.

Benieuwd wat er achter de schermen gebeurt bij een push of pull? Onze Git Push and Pull Tutorial legt het uit met voorbeelden die je kunt volgen.

Wijzigingen van een remote branch pullen

Stel dat iemand anders updates heeft gepusht naar dezelfde branch waar jij aan werkt. Dan wil je die wijzigingen binnenhalen om in sync te blijven:

Git pull origin new-feature

Dit haalt de laatste commits van de remote op en merget ze in je lokale branch. Wil je mergecommits vermijden, overweeg dan het volgende:

git pull --rebase origin new-feature

Zoals in de merge-sectie uitgelegd, helpt --rebase je historie schoon te houden.

Een remote branch tracken

Wil je gaan werken met een branch die al op de remote staat, dan is dit de makkelijkste manier om het in te richten:

git checkout --track origin/feature-xyz

Dit commando checkt de remote branch uit en zet automatisch tracking op, zodat toekomstige pulls en pushes moeiteloos gaan.

Veelvoorkomende problemen en troubleshooting

Zelfs met de beste workflows gaat niet altijd alles vlekkeloos. Of het nu een mergeconflict is, een per ongeluk verwijderde branch of ongecommitte wijzigingen die in de weg zitten—Git heeft tools om te herstellen. Laten we kijken naar veelvoorkomende branchproblemen en hoe je ze oplost.

Mergeconflicten afhandelen

Je hebt net geprobeerd een branch te mergen en Git gooit een mergeconflict. Dit gebeurt wanneer twee branches hetzelfde deel van een bestand op verschillende manieren wijzigen en Git niet kan beslissen welke wijziging behouden moet blijven.

Zo pak je het aan:

git status

Dit vertelt je welke bestanden in conflict zijn. Gebruik daarna:

git diff

Om te zien wat het probleem veroorzaakt. Open vervolgens handmatig de conflicterende bestanden, los de verschillen op en daarna

git add <resolved-file>
git commit

Wil je meer leren over mergeworkflows en het oplossen van conflicten? Bekijk de Git Merge Tutorial voor een volledige walkthrough.

Verwijderde branches herstellen

Per ongeluk een branch verwijderd en voel je paniek opkomen? Geen zorgen—het is niet voorgoed weg als je snel handelt.

Je kunt ’m terughalen met git reflog, dat je recente HEAD-posities logt:

git reflog

Zoek de commit-hash van vóórdat je de branch verwijderde, en maak ’m opnieuw met:

git checkout -b your-branch-name <commit-hash>

En zo is je branch terug. Wil je beter begrijpen hoe Git deze referenties bijhoudt? Onze Git Reflog Guide legt het uit met echte voorbeelden.

Wijzigingen stashen vóór het wisselen

Soms wil je van branch wisselen terwijl je ongecommitte wijzigingen hebt. Git laat je niet wisselen als dat tot verlies van werk kan leiden. Daar is git stash voor.

git stash

Git zet je wijzigingen tijdelijk opzij. Na het wisselen van branch kun je ze terughalen met:

git stash pop

Dit is vooral handig wanneer je tussen features of hotfixes heen en weer springt.

Beheer je veel wijzigingen of ruim je je working directory op? Dan is Git Clean: Remove Untracked Files and Keep Repos Tidy ook de moeite waard.

Geavanceerde branchingstrategieën

Je hebt nu gezien hoe je Git-branches eenvoudig maakt, wisselt en beheert. Maar hoe gebruiken teams deze branches in echte projecten? Het antwoord zit in de juiste branchingstrategie—een structuur voor hoe en wanneer je branches gebruikt in je ontwikkelworkflow. We verkennen enkele van de populairste aanpakken.

Feature-branchworkflow

De feature-branchworkflow is een van de meest gebruikte strategieën, zeker bij samenwerking. Zo werkt het:

Elke nieuwe feature krijgt een eigen branch, gemaakt vanaf main (of develop). Zo kunnen developers onafhankelijk werken zonder production-ready code te beïnvloeden.

git switch -c feature/login-page

Als de feature af is en getest, wordt hij teruggemerged in de main-branch (of een staging-branch) via een pull request.

Dit model helpt werk te isoleren, maakt code reviews beheersbaar en voorkomt dat je main-branch volloopt met half afgemaakte features. Voor soepele remote samenwerking: vergeet niet je branches te pushen:

git push -u origin feature/login-page

Een opfrisser nodig over branches pushen en pullen? De Git Push and Pull Tutorial neemt je door het hele proces.

GitFlow-workflow

Werk je aan een project met reguliere releases, dan kan GitFlow goed passen. Deze workflow introduceert gestructureerde rollen voor verschillende branchtypes:

• main: bevat altijd production-ready code.

• develop: integratiebranch voor features.

• feature/*: kortstondige branches voor nieuwe features.

• release/*: pre-productiebranches voor testen.

• hotfix/*: snelle fixes gebaseerd op main.

Hier is een snel voorbeeld van het starten van een nieuwe featurebranch met GitFlow-tools:

git flow feature start payment integration

Deze strategie voegt wat complexiteit toe, maar blinkt uit bij grotere teams waar duidelijke structuur en stabiliteit prioriteit zijn. Verken je workflows buiten GitHub? Bekijk dan What GitLab Is: Features, Benefits, and How to Get Started voor een andere kijk op gestructureerde Git-praktijken.

Trunk-based development

Houd je van minimale branching en snelle oplevering? Trunk-based development is misschien jouw stijl. In deze strategie committen alle developers naar één branch, meestal main, met kleine en frequente commits. In plaats van langlevende featurebranches moedigt deze aanpak kortlevende branches of directe commits naar main aan.

Het is snel en overzichtelijk, maar vraagt discipline, sterke testautomatisering en goede communicatie. Dit model is gangbaar bij startups en teams die DevOps of CI/CD toepassen. Een branchingstrategie kies je op basis van teamgrootte, releaserooster en natuurlijk de mate van samenwerking.

Conclusie

Branches vormen het hart van Git’s versiesysteem. Ze stellen developers in staat om aan nieuwe features, bugfixes en experimenten te werken in isolatie, zonder de hoofdcodebase te verstoren. Die flexibiliteit leidt tot schonere, beter georganiseerde workflows en betere team­ samenwerking.

Door vaak te committen, verantwoordelijk te mergen en een schone branchstructuur te behouden, verklein je de kans op conflicten en maak je je codebase eenvoudiger te navigeren en te onderhouden. Zonder twijfel helpt het beheersen van Git-branches je om op termijn betere software te leveren.