Git en versiebeheer in mobiele ontwikkeling: wat het is, basiscommando's en hoe het werkt

Versiebeheer en Git: wat is het?

Git is een gedistribueerd versiebeheersysteem (VCS) gemaakt door Linus Torvalds in 2005 voor de ontwikkeling van de Linux-kernel. In tegenstelling tot gecentraliseerde systemen (SVN, CVS) slaat Git een volledige kopie van de projectgeschiedenis op elke computer van de ontwikkelaar op. Dit betekent dat u commits kunt maken, door de geschiedenis kunt bladeren en takken kunt maken, zelfs zonder internetverbinding.

Git werkt met snapshots — elke commit slaat de status van alle projectbestanden op het moment van opslaan op. Als een bestand niet is gewijzigd, maakt Git een verwijzing naar de vorige versie, waardoor ruimte wordt bespaard. Volgens GitHub-analyse (2025) bevat de gemiddelde repository 1.200 commits en 15 takken.

Bij IT Sectr gebruiken we Git sinds 2017 in alle projecten. Onze ervaring leert dat een juiste Git-configuratie vanaf dag één het team tot 30% tijd bespaart bij het mergen en oplossen van conflicten. Git is de facto standaard geworden — het wordt ondersteund door alle moderne IDE's (Android Studio, Xcode, VS Code) en CI/CD-systemen.

# Basis Git-configuratie
git config --global user.name "Uw Naam"
git config --global user.email "uw@email.com"

# Een nieuwe repository maken
git init my-project
cd my-project

# Bestanden toevoegen en committen
git add README.md
git commit -m "Initial commit"

# Werken met een externe repository
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Bovenstaande code toont de basisvolgorde: een repository initialiseren, eerste commit en publiceren op een externe server. Het commando git init maakt een verborgen .git-map aan die de volledige projectgeschiedenis zal opslaan. Elke git commit creëert een herstelpunt waar u op elk moment naar terug kunt keren.

Basisconcepten: Repository, Branch, Commit

Het begrijpen van de drie basisconcepten — Repository, Branch en Commit — is essentieel voor het werken met elk versiebeheersysteem. Een repository is een container voor het hele project. Een commit is een opgeslagen toestand van bestanden. Een branch is een aparte ontwikkelingslijn.

Repository kan lokaal (op uw computer) of extern (op een GitHub-, GitLab-server) zijn. Elke ontwikkelaar kloont de externe repository naar zijn machine en werkt met een lokale kopie. Wijzigingen worden gesynchroniseerd via push (verzenden) en pull (ophalen). In gedistribueerd versiebeheer slaat elke ontwikkelaar een volledige kopie van de geschiedenis op.

Branch (tak) is een verwijzing naar een van de commits. Takken maken parallelle ontwikkeling mogelijk: de ene ontwikkelaar werkt aan een nieuwe functie (feature branch), een andere herstelt een bug (hotfix branch), een derde bereidt een release voor (release branch). Volgens GitLab Flow (2025) heeft het gemiddelde project 3–5 actieve takken tegelijkertijd.

Commit is een eenheid van wijziging. Elke commit bevat een unieke hash (SHA-1), een bericht, een auteur en een tijdstempel. Goede praktijk is om kleine betekenisvolle commits te maken met beschrijvende berichten — dit vereenvoudigt Code Review en het terugdraaien van wijzigingen. Versiebeheer via commits geeft u de volledige projectgeschiedenis.

Feature Branch

Feature Branch (functietak) is een tijdelijke tak die wordt gemaakt van develop of main voor het ontwikkelen van een specifieke taak. Na voltooiing van het werk wordt de tak terug samengevoegd via Pull Request en verwijderd. Deze praktijk maakt het mogelijk wijzigingen te isoleren zonder de stabiliteit van de hoofdcodebase te verstoren.

Typische workflow: maak tak feature/add-login → doe meerdere commits → maak Pull Request → doorloop Code Review → merge in develop. Bij IT Sectr gebruiken we precies deze aanpak: elke Jira-taak komt overeen met een aparte feature-tak. Dit vereenvoudigt het volgen van wijzigingen en terugdraaien indien nodig.

Rebase vs Merge

Merge maakt een merge-commit die twee takken combineert. Het behoudt de volledige geschiedenis, inclusief parallelle ontwikkelingslijnen. Rebase herschrijft de geschiedenis: het neemt commits van de ene tak en "past ze opnieuw toe" bovenop een andere, waardoor een lineaire geschiedenis ontstaat.

Merge is geschikter voor openbare takken en grote teams waar chronologie belangrijk is. Rebase is handig voor persoonlijke feature-takken voordat u een PR maakt — het maakt de geschiedenis schoner en begrijpelijker. Rebase mag echter nooit worden toegepast op takken waar andere ontwikkelaars aan werken, omdat het de geschiedenis herschrijft.

# Een feature-tak maken en ernaar overschakelen
git checkout -b feature/add-login main

# Werken in de tak
git add login-screen/
git commit -m "Add login screen layout"

# Rebase op nieuwste main voor PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push naar externe repository
git push origin feature/add-login

Dit voorbeeld toont een typische workflow: een feature-tak maken van main, meerdere commits en rebase om een schone lineaire geschiedenis te krijgen voordat deze ter beoordeling wordt verzonden. Deze aanpak minimaliseer merge-conflicten.

Git Flow vs Trunk-Based Development

Git Flow en Trunk-Based Development zijn twee belangrijkste versiebeheerstrategieën die bepalen hoe een team het werk met Git organiseert. De keuze hangt af van de teamgrootte, releasefrequentie en stabiliteitseisen.

Git Flow is een strikt model met meerdere permanente takken: main (releasecode), develop (huidige ontwikkeling), feature/* (nieuwe functies), release/* (releasevoorbereiding) en hotfix/* (dringende fixes). Dit model is goed voor projecten met duidelijke releasecycli (bijv. mobiele apps met versies 1.0, 2.0).

Trunk-Based Development is een aanpak met een enkele hoofdtak (trunk/main) waarin alle ontwikkelaars meerdere keren per dag wijzigingen mergen. Feature flags worden gebruikt om onvolledige functies te verbergen. Deze aanpak is populair in webontwikkeling en startups waar leversnelheid belangrijk is.

Git Flow

Git Flow, voorgesteld door Vincent Driessen in 2010, blijft een van de populairste modellen. Het belangrijkste voordeel is de strikte scheiding van code volgens levenscyclusfasen. De main-tak bevat alleen releasecode, develop bevat de huidige ontwikkeling en feature-takken isoleren nieuwe functies van elkaar.

Hotfix-takken worden gemaakt van main voor dringende fixes en worden na het mergen teruggezet naar zowel main als develop. Release-takken worden gemaakt van develop wanneer het team klaar is voor een release. Hieraan worden alleen bugfixes en metadata (versie, build) toegevoegd. Na de release wordt de release-tak gemerged in main en develop. Volgens een JetBrains-enquête (2024) gebruikt 37% van de teams Git Flow. Dit versiebeheermodel blijft de standaard voor projecten met vaste releases.

# Git Flow voorbeeld: beginnen met een release
git checkout -b release/1.2.0 develop

# Bugs in de release-tak oplossen
git commit -m "Fix login button crash"

# Release voltooien — mergen in main en develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# De release-tak verwijderen
git branch -d release/1.2.0

De code illustreert het maken van een release-tak, het stabiliseren ervan en het mergen in de hoofdtakken. De --no-ff-vlag garandeert een merge-commit, waarbij de informatie behouden blijft dat de wijzigingen uit de release-tak komen.

Pull Request en Code Review

Pull Request (PR) is een mechanisme waarmee een ontwikkelaar wijzigingen van zijn tak naar de hoofdtak voorstelt. PR is een sleutelonderdeel van versiebeheer in teamwerk — het is niet alleen een manier om code te mergen, maar een proces van discussie, beoordeling en kwaliteitscontrole. In GitLab wordt het vergelijkbare mechanisme Merge Request (MR) genoemd, maar de essentie is hetzelfde: het team op de hoogte stellen van wijzigingen en goedkeuring krijgen.

Een goede PR moet klein zijn (tot 300 regels code), gericht op één taak en een beschrijving bevatten van wat er is gedaan en waarom. Volgens een Google-onderzoek (2025) duren PR's van meer dan 400 regels twee keer zo lang om te beoordelen en neemt de kans op het detecteren van bugs af met 30%. Code Review is het controleren van code door een andere ontwikkelaar vóór het mergen.

Bij IT Sectr passen we verplichte Code Review toe voor elke PR. Dit verbetert niet alleen de codekwaliteit, maar helpt ook bij het verspreiden van kennis binnen het team. Code Review controleert: of de code architectuurprincipes volgt, of er bugs zijn, of er voldoende tests zijn, of variabelen correct zijn benoemd. Alle opmerkingen worden in de PR besproken tot het mergen.

Platformen: GitHub, GitLab, Bitbucket

Git is een protocol, maar voor samenwerking is een versiebeheerplatform nodig dat een webinterface, toegangsbeheer, CI/CD en beoordelingstools biedt. Drie platformen domineren de markt: GitHub, GitLab en Bitbucket.

GitHub is het grootste platform met meer dan 56 miljoen ontwikkelaars. Eigendom van Microsoft, biedt Actions (CI/CD), Pages (hosting), Discussions en Copilot. Het gratis abonnement omvat onbeperkte privé-repositories voor teams tot 3 personen. GitHub is populair in de open-sourcegemeenschap.

GitLab is een volledig DevOps-platform met geïntegreerde CI/CD, containerregister en infrastructuurbeheer. In tegenstelling tot GitHub kan GitLab op uw eigen server worden geïnstalleerd (Self-Managed). Bitbucket van Atlassian is nauw geïntegreerd met Jira en Confluence, wat het de keuze maakt voor teams die al het Atlassian-ecosysteem gebruiken.