Git is het meest gebruikte versiebeheersysteem ter wereld en stelt ontwikkelaars in staat om elke wijziging in hun broncode nauwkeurig bij te houden. Met Git werk je nooit meer met verwarrende mappenstructuren zoals project-definitief-v2-echt-definitief, maar houd je via een gestructureerde geschiedenis precies bij wie wat wanneer heeft aangepast. Denk aan een team dat samen aan een webshop bouwt: de ene developer werkt aan de betaalpagina, de andere aan de productcatalogus, en Git zorgt ervoor dat hun werk zonder conflicten samenkomt. Ook bij solo-projecten is Git onmisbaar: je kunt experimenteren met nieuwe functies zonder bang te zijn dat je werkende code kapotmaakt, omdat je altijd terug kunt naar een eerdere versie. Git is daarmee de ruggengraat van moderne softwareontwikkeling en een vaardigheid die elke developer moet beheersen.
Hoe werkt Git?
Git werkt op basis van een lokale repository: een verborgen map op jouw computer waarin Git alle versies van jouw project opslaat. Wanneer je klaar bent met een reeks wijzigingen, maak je een commit aan — een momentopname van jouw codebase op dat moment. Elke commit krijgt een unieke identificatiecode en bevat informatie over wie de wijziging heeft gemaakt, wanneer dat was, en wat de reden was.
De drie zones van Git
Om Git goed te begrijpen, is het belangrijk om de drie zones te kennen waardoor jouw bestanden bewegen:
- Working directory: de map op jouw computer waar je werkt en bestanden aanpast.
- Staging area: een tussengebied waar je aangeeft welke wijzigingen in de volgende commit meegenomen worden.
- Repository: de permanente geschiedenis van alle commits die je hebt gemaakt.
Dit drielaagse systeem geeft je volledige controle over wat je vastlegt. Je hoeft niet alle wijzigingen in één commit te stoppen; je kunt zorgvuldig kiezen welke bestanden of zelfs welke regels code je wilt opnemen.
Branches: parallel werken zonder chaos
Een van de krachtigste functies van Git is het werken met branches. Een branch is een onafhankelijke kopie van jouw code waarop je kunt experimenteren zonder de hoofdversie aan te raken. Stel dat jouw team werkt aan versie 1.0 van een applicatie die al live staat, en tegelijkertijd wil beginnen met het ontwikkelen van een grote nieuwe functie. Je maakt dan een aparte branch aan voor die nieuwe functie. Zo blijft de stabiele versie beschikbaar voor hotfixes terwijl de nieuwe functie rustig wordt ontwikkeld.
Mergen en rebasen
Wanneer een branch klaar is, voeg je deze samen met de hoofdbranch via een merge. Git probeert dit automatisch te doen, maar bij conflicterende wijzigingen — als twee developers dezelfde regel code anders hebben aangepast — vraagt Git jou om handmatig te kiezen welke versie correct is. Een alternatief voor mergen is rebasen, waarbij je de commits van jouw branch alsof ze na de laatste commits van de hoofdbranch zijn gemaakt opnieuw afspeelt. Dit zorgt voor een schonere, lineaire geschiedenis.
Git versus platforms zoals GitHub, GitLab en Bitbucket
Git zelf draait volledig lokaal op jouw machine, maar in de praktijk wil je jouw code ook op een centrale locatie bewaren zodat teamleden eraan kunnen samenwerken en jij een backup hebt. Dat is waar platforms als GitHub, GitLab en Bitbucket om de hoek komen kijken. Deze diensten hosten jouw Git-repositories in de cloud en voegen extra functies toe zoals:
- Pull requests (of merge requests): een gestructureerde manier om code te laten reviewen voordat het samenkomt met de hoofdbranch.
- Issue tracking: het bijhouden van bugs en taken gekoppeld aan jouw codebase.
- CI/CD-integraties: automatisch testen en deployen van code bij elke commit.
- Toegangsbeheer: bepalen wie jouw code mag lezen, schrijven of beheren.
Het is belangrijk om te begrijpen dat Git het versiebeheersysteem is, en GitHub het platform dat Git-repositories host. Je kunt Git gebruiken zonder GitHub, maar GitHub werkt altijd met Git.
Essentiële Git-commando’s voor dagelijks gebruik
Als je begint met Git, zul je merken dat een handvol commando’s verantwoordelijk is voor het overgrote deel van jouw dagelijkse werk. Hier zijn de commando’s die je het vaakst nodig hebt:
- git init: maak een nieuwe lokale repository aan in de huidige map.
- git clone [url]: kopieer een bestaande remote repository naar jouw computer.
- git status: bekijk welke bestanden zijn gewijzigd en welke klaarstaan voor de volgende commit.
- git add [bestand]: voeg een bestand toe aan de staging area.
- git commit -m “bericht”: maak een commit aan met een beschrijvend bericht.
- git push: stuur jouw commits naar de remote repository.
- git pull: haal de laatste wijzigingen op uit de remote repository.
- git branch: bekijk alle beschikbare branches of maak een nieuwe aan.
- git checkout [branch]: wissel naar een andere branch.
- git merge [branch]: voeg een branch samen met de huidige branch.
Met deze tien commando’s kom je al een heel eind. Naarmate je meer ervaring opdoet, leer je ook geavanceerde commando’s kennen zoals git rebase, git stash en git cherry-pick.
Git in een professionele workflow: GitFlow en trunk-based development
In grotere teams is het belangrijk om afspraken te maken over hoe je branches gebruikt en wanneer je merget. Twee populaire benaderingen zijn GitFlow en trunk-based development.
GitFlow is een uitgebreid branchingmodel met vaste rollen voor verschillende branches: een main-branch voor productiecode, een develop-branch voor integratie, feature-branches voor nieuwe functies, release-branches voor voorbereiding op een release, en hotfix-branches voor urgente productiefouten. Dit model werkt goed voor teams die werken met geplande releases.
Trunk-based development gaat uit van één centrale branch — de trunk of main — waar iedereen meerdere keren per dag naar pusht. Features worden beschermd door feature flags die code verbergen totdat die klaar is voor productie. Dit model past goed bij teams die continu deployen.
Conclusie
Git is een onmisbaar gereedschap voor elke moderne softwareontwikkelaar en vormt de basis van vrijwel alle professionele ontwikkelworkflows. Door Git te gebruiken, bescherm je jouw werk tegen verlies, werk je efficiënt samen met collega’s en houd je te allen tijde een volledig overzicht van de geschiedenis van jouw project. Of je nu solo werkt aan een persoonlijk project of deel uitmaakt van een groot enterprise-team, de investering in het leren van Git betaalt zich keer op keer terug. Begin met de basiscommando’s, oefeen met branches en merges, en verken vervolgens platforms als GitHub of GitLab om de volledige kracht van Git te benutten. Heb je Git nog niet in gebruik? Start vandaag nog met git init en ontdek hoe verslebeheer jouw manier van werken voorgoed verandert.
Veelgestelde vragen
-
Wat is het verschil tussen Git en GitHub?
Git is het versiebeheersysteem dat lokaal op jouw computer draait en waarmee je wijzigingen in code bijhoudt. GitHub is een online platform dat Git-repositories host en extra samenwerkingsfuncties biedt zoals pull requests en issue tracking. Je kunt Git gebruiken zonder GitHub, maar GitHub vereist altijd Git als onderliggende technologie. -
Is Git moeilijk te leren?
De basiscommando’s van Git zijn binnen een dag te leren en dekken al het overgrote deel van jouw dagelijkse gebruik. De meer geavanceerde concepten zoals rebasen, cherry-picken en het oplossen van merge-conflicten vereisen wat meer oefening. Met goede online tutorials en hands-on practice ben je al snel productief. -
Kan ik Git ook gebruiken voor andere bestanden dan code?
Ja, Git werkt met alle tekstbestanden, dus je kunt het ook gebruiken voor documentatie, configuratiebestanden of zelfs manuscripten. Git is minder geschikt voor grote binaire bestanden zoals afbeeldingen of video’s, al bestaat er een uitbreiding genaamd Git LFS (Large File Storage) die hier een oplossing voor biedt. -
Wat doe ik als er een merge-conflict optreedt?
Een merge-conflict treedt op wanneer twee personen dezelfde regel code anders hebben aangepast. Git markeert de conflicterende regels in het bestand en jij moet handmatig kiezen welke versie correct is. De meeste code-editors en IDE’s hebben ingebouwde tools die het oplossen van merge-conflicten visueel en intuïtief maken. -
Hoe schrijf ik goede commit-berichten?
Een goed commit-bericht begint met een korte, beschrijvende samenvatting van maximaal 50 tekens in de gebiedende wijs, zoals “Voeg validatie toe aan het inlogformulier”. Optioneel kun je een lege regel toevoegen gevolgd door een langere uitleg over waarom de wijziging is gemaakt. Goede commit-berichten maken de geschiedenis van jouw project leesbaar en zijn onmisbaar bij het terugzoeken van bugs.