software development
Git versiebeheer: alles wat je moet weten over branches, commits en workflows
Git geeft ontwikkelteams volledige controle over codegeschiedenis via branches, commits en merges. Ontdek hoe gedistribueerd versiebeheer samenwerking versnelt, CI/CD-pipelines mogelijk maakt en waarom Git de ruggengraat is van elk modern softwareproject.
Wat is Git versiebeheer: alles wat je moet weten over branches, commits en workflows?
Git is een gedistribueerd versiebeheersysteem waarmee ontwikkelaars wijzigingen in broncode bijhouden, samenwerken aan projecten en eerdere versies van bestanden herstellen. Linus Torvalds ontwikkelde Git in 2005 voor het beheer van de Linux-kernel, nadat bestaande systemen niet voldeden aan zijn eisen voor snelheid en gedistribueerd werken. Sindsdien is Git uitgegroeid tot het meest gebruikte version control system ter wereld, met meer dan 100 miljoen repositories alleen al op GitHub. Vrijwel elke CI/CD-pipeline, code review-workflow en deployment-strategie in de moderne softwareontwikkeling is gebouwd op Git als fundament.
Hoe werkt Git versiebeheer: alles wat je moet weten over branches, commits en workflows technisch?
Git werkt met een gedistribueerd model waarbij elke ontwikkelaar een volledige kopie van de repository heeft, inclusief de complete geschiedenis. Dit betekent dat je offline kunt werken, committen en branches aanmaken zonder verbinding met een server. Wijzigingen worden vastgelegd als commits die een snapshot van alle bestanden op een bepaald moment vormen, geïdentificeerd door een unieke SHA-1 hash. Branches maken het mogelijk om parallel aan verschillende features of bugfixes te werken zonder de hoofdcode te beïnvloeden. Git gebruikt een Directed Acyclic Graph (DAG) om de relatie tussen commits bij te houden, wat complexe branchingstructuren mogelijk maakt. Merging combineert branches weer samen, waarbij Git automatisch wijzigingen samenvoegt via een three-way merge algoritme of conflicten signaleert wanneer dezelfde regels in beide branches zijn gewijzigd. Rebasing herschrijft de commit-geschiedenis voor een lineaire timeline, wat de leesbaarheid van de projectgeschiedenis verbetert maar voorzichtig gebruikt moet worden op gedeelde branches. Remote repositories op platforms als GitHub, GitLab of Bitbucket faciliteren samenwerking via pull requests en code reviews. Git hooks automatiseren taken bij bepaalde acties, zoals pre-commit checks die linting en tests uitvoeren voordat code gecommit wordt. Strategieën als Git Flow, GitHub Flow en trunk-based development bieden structuur voor teamworkflows afhankelijk van de releasefrequentie en teamgrootte. Stashing bewaart tijdelijk onafgemaakte wijzigingen zodat je kunt wisselen naar een andere branch, cherry-picking verplaatst individuele commits tussen branches, en bisect helpt bij het opsporen van de exacte commit die een bug heeft geintroduceerd via een binaire zoekstrategie. Submodules maken het mogelijk om externe repositories als afhankelijkheden binnen je project te beheren, terwijl Git LFS (Large File Storage) grote binaire bestanden als afbeeldingen en video's efficient opslaat buiten de reguliere repository. Signed commits met GPG of SSH keys verifieren de identiteit van de auteur en voorkomen dat kwaadwillenden commits namens iemand anders pushen. Worktrees stellen je in staat om meerdere branches tegelijk uitgecheckt te hebben in verschillende directories, handig voor het parallel reviewen van pull requests.
Hoe past MG Software Git versiebeheer: alles wat je moet weten over branches, commits en workflows toe in de praktijk?
Bij MG Software is Git het fundament van al onze ontwikkelworkflows. We werken met GitHub als remote platform en hanteren een trunk-based development strategie met feature branches en pull requests. Elke wijziging doorloopt een verplichte code review voordat deze gemerged wordt naar de main branch. We gebruiken Git hooks voor pre-commit checks met Biome (linting en formatting) en GitHub Actions voor automatische testing, build-verificatie en deployment naar Vercel. Onze commit-conventies volgen Conventional Commits zodat changelogs automatisch gegenereerd kunnen worden. Voor onze klanten richten we professionele Git-workflows in, inclusief branch protection rules, verplichte reviews en geautomatiseerde CI/CD, zodat hun teams effectief en veilig aan code kunnen samenwerken zonder risico op productie-incidenten door ongeteste code. We gebruiken CODEOWNERS-bestanden om automatisch de juiste reviewers toe te wijzen per codegebied en configureren required status checks zodat alleen builds die slagen gemerged kunnen worden. Bij complexere projecten met meerdere repositories zetten we monorepo-tooling in met gedeelde Git-configuraties.
Waarom is Git versiebeheer: alles wat je moet weten over branches, commits en workflows belangrijk?
Zonder versiebeheer is professionele softwareontwikkeling in teamverband vrijwel onmogelijk. Git biedt ontwikkelaars de zekerheid dat ze op elk moment kunnen terugkeren naar een werkende staat van hun code, dat ze parallel aan verschillende functionaliteiten kunnen werken zonder elkaar te blokkeren, en dat elke wijziging traceerbaar is. In een professionele omgeving waar meerdere ontwikkelaars dagelijks code wijzigen, voorkomt Git dataverlies, vermindert het conflicten en maakt het gecontroleerde samenwerking mogelijk. De combinatie van Git met CI/CD-pipelines en code review-processen is de basis van moderne software delivery, waarmee teams sneller, veiliger en met meer vertrouwen code naar productie kunnen brengen. Git vormt ook de basis van GitOps-workflows waarbij de gewenste staat van infrastructuur en applicaties in een Git-repository wordt bijgehouden, waardoor elke wijziging traceerbaar, reviewbaar en automatisch reversible is.
Veelgemaakte fouten met Git versiebeheer: alles wat je moet weten over branches, commits en workflows
Veelvoorkomende fouten zijn direct committen op de main-branch zonder review, onduidelijke commitberichten schrijven zoals "fix" of "update" zonder context, en merge-conflicten onzorgvuldig oplossen door code van collega's onbedoeld te overschrijven. Teams vergeten vaak branch protection rules in te stellen, waardoor iedereen direct naar main kan pushen. Het committen van gevoelige gegevens zoals wachtwoorden of API-keys in de repository is een ander veelvoorkomend probleem dat lastig te corrigeren is omdat Git de volledige geschiedenis bewaart. Een goede branchingstrategie, conventionele commitberichten en pre-commit hooks voorkomen veel van deze problemen structureel. Ontwikkelaars maken soms enorm grote commits die tientallen bestanden wijzigen, wat code reviews onpraktisch maakt en de kans op verborgen bugs verhoogt. Het niet opschonen van stale branches na een merge leidt tot een onoverzichtelijke repository met honderden ongebruikte branches die navigatie bemoeilijken.
Welke voorbeelden zijn er van Git versiebeheer: alles wat je moet weten over branches, commits en workflows?
- Een team van vijf ontwikkelaars dat via Git branches gelijktijdig aan verschillende features werkt, en via pull requests op GitHub elkaars code reviewt voordat wijzigingen samengevoegd worden in de main branch met verplichte goedkeuring.
- Een bedrijf dat met Git tags releases markeert en semantic versioning toepast, zodat ze op elk moment kunnen terugkeren naar een eerdere, stabiele versie van hun software wanneer er een bug in productie ontdekt wordt.
- Een open-source project op GitHub waarbij honderden bijdragers via forks en pull requests nieuwe functionaliteiten toevoegen, terwijl de kernmaintainers via CODEOWNERS-bestanden en automatische checks de kwaliteit bewaken.
- Een DevOps-team dat Git hooks gebruikt om bij elke commit automatisch unit tests, linting en security scans uit te voeren, waardoor code die niet aan kwaliteitsnormen voldoet niet eens in de repository terecht kan komen.
- Een freelancer die met Git Stash onafgemaakte werkzaamheden parkeert om snel een hotfix te maken op een andere branch, en daarna het eerder bewaarde werk weer oppakt zonder iets te verliezen.
Verder lezen
Veelgestelde vragen
Wat is het verschil tussen Git en GitHub?
Git is de versiebeheersoftware die lokaal op je computer draait en wijzigingen in code bijhoudt. GitHub is een online platform dat Git-repositories host en extra functies biedt zoals pull requests, code reviews, issue tracking, projectmanagement en CI/CD via GitHub Actions. Je kunt Git gebruiken zonder GitHub (alternatieven zijn GitLab en Bitbucket), maar een remote platform maakt samenwerking in teams veel eenvoudiger en veiliger.
Waarom zou ik Git gebruiken in plaats van bestanden handmatig opslaan?
Git houdt automatisch een volledige geschiedenis bij van alle wijzigingen, wie ze heeft gemaakt en wanneer. Je kunt op elk moment terug naar een eerdere versie, parallel aan meerdere features werken via branches, en conflicten bij samenwerking gecontroleerd oplossen. Handmatig kopiëren van bestanden zoals "project_v2_final_echt_final.zip" leidt al snel tot verwarring, verlies van werk en onmogelijkheid om te achterhalen wat er wanneer gewijzigd is.
Is Git moeilijk om te leren?
De basis van Git, namelijk commits maken, branches aanmaken en pushen naar een remote repository, is binnen een uurtje te leren. Geavanceerde concepten zoals rebasing, cherry-picking en het oplossen van complexe merge-conflicten vragen meer oefening en inzicht. Visuele tools als de ingebouwde Git-functionaliteiten in VS Code, GitKraken of GitHub Desktop maken Git toegankelijker voor beginners die nog niet vertrouwd zijn met de command line.
Wat is een Git branch en waarom gebruik je die?
Een branch is een onafhankelijke lijn van ontwikkeling binnen je repository. Je maakt een branch aan om aan een nieuwe feature of bugfix te werken zonder de stabiele hoofdcode (main branch) aan te raken. Wanneer je werk klaar is, merge je de branch terug. Dit maakt het mogelijk dat meerdere ontwikkelaars tegelijk aan verschillende onderdelen werken zonder elkaar te blokkeren, en dat onafgemaakte features de productie-omgeving niet beïnvloeden.
Wat is het verschil tussen merge en rebase?
Bij een merge worden twee branches samengevoegd en ontstaat er een merge-commit die beide geschiedenissen bewaart. Bij een rebase worden de commits van je branch verplaatst naar het uiteinde van de doelbranch, waardoor een lineaire geschiedenis ontstaat zonder extra merge-commits. Rebase geeft een nettere geschiedenis maar herschrijft commits, wat problemen kan veroorzaken op branches die door meerdere mensen worden gebruikt. De vuistregel: rebase voor lokale branches, merge voor gedeelde branches.
Hoe los ik een merge-conflict op?
Een merge-conflict ontstaat wanneer Git niet automatisch kan bepalen welke wijzigingen behouden moeten worden omdat dezelfde regels in beide branches zijn aangepast. Git markeert de conflicterende secties in het bestand met speciale markers. Je opent het bestand, kiest welke wijzigingen je wilt behouden of combineert ze handmatig, verwijdert de conflictmarkers en maakt een nieuwe commit. IDE's als VS Code bieden visuele tools die dit proces vereenvoudigen met knoppen voor "Accept Current", "Accept Incoming" of "Accept Both".
Wat zijn Git hooks en waarvoor gebruik je ze?
Git hooks zijn scripts die automatisch worden uitgevoerd bij bepaalde Git-acties zoals committen, pushen of mergen. De meest gebruikte hook is pre-commit, die checks uitvoert voordat een commit wordt vastgelegd, zoals linting, formatting en het scannen op gevoelige gegevens. Pre-push hooks kunnen tests draaien voordat code naar de remote repository wordt gepusht. Tools als Husky en lint-staged maken het eenvoudig om hooks te configureren en te delen met je team via de repository.
Dit begrip in jullie systeem?
Wij bouwen hier dagelijks mee. In een gesprek van een uur weet je of het een portaal, een koppeling of een herbouw is.