Inhoudsopgave
Git is het fundament van vrijwel elke moderne softwareontwikkeling, maar het gebruik ervan verschilt enorm per team. Het ene team werkt direct op main, het andere heeft een uitgebreid branchingssysteem met strikte regels. Zonder duidelijke afspraken ontstaan merge-conflicten, gaan commits verloren en wordt de geschiedenis van een repository een onleesbare brij. Een goede git workflow is geen bureaucratie — het is de infrastructuur waarop betrouwbare software wordt gebouwd.
Branching strategie kiezen
De bekendste strategieën zijn Git Flow, GitHub Flow en trunk-based development. Git Flow werkt met vaste branches voor features, releases en hotfixes en is geschikt voor projecten met geplande releases. GitHub Flow is eenvoudiger: je maakt een branch per feature, opent een pull request en merget naar main na review. Trunk-based development gaat nog verder en werkt met zeer korte branches of direct op main, gecombineerd met feature flags. Kies de strategie die past bij je releasecadans en teamgrootte, en houd je er consequent aan.
Commit messages die iets zeggen
Een commit message als “fix” of “wip” is nutteloos voor iedereen die later de geschiedenis doorzoekt. Een goede commit message beschrijft wat er is veranderd én waarom, in de gebiedende wijs: “Voeg validatie toe aan e-mailformulier” in plaats van “e-mailformulier gefixt”. De Conventional Commits-standaard gaat verder en voegt een type toe zoals feat:, fix: of chore:, wat geautomatiseerde changelogs en semantische versiebeheer mogelijk maakt. Kleine, gerichte commits met duidelijke messages maken code review en debugging aanzienlijk eenvoudiger.
Pull requests als kwaliteitspoort
Een pull request is meer dan een technische handeling om code samen te voegen — het is een kwaliteitscontrole. Een goede PR is klein genoeg om grondig te reviewen, heeft een duidelijke beschrijving van wat er is veranderd en waarom, en bevat geen ongerelateerde wijzigingen. Als reviewer is het je taak om niet alleen te controleren of de code werkt, maar ook of hij leesbaar, onderhoudbaar en consistent is met de rest van de codebase. PR-templates helpen om die structuur af te dwingen zonder dat je het elke keer opnieuw hoeft te bespreken.
Omgaan met merge-conflicten
Merge-conflicten zijn onvermijdelijk, maar je kunt ze minimaliseren. Kleine, frequente commits en korte branch-levensduur verminderen de kans op grote conflicten aanzienlijk. Sync je branch regelmatig met main via rebase of merge zodat je niet te ver afdrijft. Als een conflict toch optreedt, los het dan op met begrip van beide kanten van de wijziging — niet door blind één versie te kiezen. Tools zoals de merge editor in VS Code of GitLens maken het visueel inzichtelijker en verminderen de kans op fouten bij het oplossen.
Automatisering via CI
Een git workflow wordt pas echt krachtig in combinatie met een CI-pipeline. Elke push of pull request triggert automatisch tests, linting en eventueel een buildcheck. Zo weet je al vóór de code review of de wijziging de basisvereisten haalt. Platforms zoals GitHub Actions, GitLab CI en Bitbucket Pipelines maken dit eenvoudig in te richten met een yaml-configuratiebestand in je repository. Een groene pipeline is geen garantie voor goede code, maar een rode pipeline is een duidelijk signaal dat er iets mis is voordat het main bereikt.