Repository in Git: wat is het, welke types zijn er en hoe werken ze

Wat is een repository in Git

Git-repository — is een gegevensstructuur waarin het versiebeheersysteem metadata en objecten opslaat die de wijzigingsgeschiedenis van projectbestanden beschrijven. Wanneer een ontwikkelaar een repository initialiseert met het commando git init, maakt Git een verborgen map .git in de hoofdmap van het project.

In deze map bevinden zich alle objecten, verwijzingen en configuratiebestanden die nodig zijn voor het functioneren van het systeem. De repository is niet gebonden aan een specifieke locatie — de ontwikkelaar kan deze lokaal aanmaken en vervolgens verbinden met een externe server.

Git gebruikt het model van een gedistribueerde repository: elke deelnemer aan het project heeft een volledige kopie van de geschiedenis op zijn eigen computer. Dit betekent dat de meeste bewerkingen — commit, geschiedenis bekijken, branches aanmaken — lokaal worden uitgevoerd zonder de server te raadplegen.

Volgens de Git-documentatie maakt de gedistribueerde architectuur het systeem bestand tegen storingen: als de server uitvalt, kan elke lokale repository als bron dienen voor het herstellen van de volledige projectgeschiedenis.

Lokale en externe repository

Lokale repository — is een kopie van het project op de computer van de ontwikkelaar. Het bevat de volledige geschiedenis van commits, branches en tags en maakt het mogelijk om commit-, branch-, merge- en rebase-bewerkingen uit te voeren zonder netwerkverbinding.

Externe repository wordt gehost op een server en dient als synchronisatiepunt voor alle teamleden. Ontwikkelaars sturen hun wijzigingen met het commando git push en halen wijzigingen van anderen op met het commando git pull.

De verbinding tussen de lokale en externe repository wordt geconfigureerd via remote origin — de server-URL die in de Git-configuratie wordt opgeslagen. Eén lokale repository kan met meerdere externe repositories worden verbonden, wat handig is bij het werken met forks.

Het belangrijkste voordeel van dit model is dat de ontwikkelaar offline aan code kan werken en wijzigingen pas synchroniseert wanneer hij klaar is om het resultaat te verzenden.

Verschillen tussen lokale en externe repository

Hoe Git gegevens opslaat in de repository

Git's opslagmodel verschilt fundamenteel van andere versiebeheersystemen. In plaats van een lijst met wijzigingen (delta's) tussen versies op te slaan, slaat Git volledige snapshots op van alle projectbestanden op het moment van elke commit.

Elk object in de repository wordt geïdentificeerd door een unieke SHA-1-hash van 40 tekens. Als de inhoud van een bestand niet is veranderd tussen commits, maakt Git geen nieuw object aan maar hergebruikt het bestaande — dit bespaart ruimte.

Git gebruikt vier objecttypen: blob (bestandsinhoud), tree (mapstructuur), commit (snapshot met metadata) en tag (benoemde verwijzing naar een commit). Alle objecten worden opgeslagen in de map .git/objects.

Volgens Git Internals zorgt Git's objectmodel voor gegevensintegriteit: elke wijziging van de bestandsinhoud leidt tot een nieuwe hash, waardoor onopgemerkte wijziging van de geschiedenis onmogelijk wordt.

Structuur van de .git-map

De .git-map — is het hart van de repository. Zonder deze map kan Git geen wijzigingen bijhouden en blijft een gewone map slechts een verzameling bestanden. Inzicht in de structuur van deze map helpt bij het diagnosticeren van problemen met de repository.

• objects/ — alle objecten van de repository: blobs, trees, commits, tags. Opgeslagen in gecomprimeerde vorm.
• refs/ — verwijzingen naar commits: heads (branches), tags (labels), remotes (externe branches).
• HEAD — bestand dat naar de huidige actieve branch of commit verwijst.
• config — repository-instellingen: externe URL, gebruikersnaam, e-mail en andere parameters.
• index — staging area (index), waar Git informatie opslaat over bestanden die zijn voorbereid voor een commit.
• logs/ — logboeken van verwijzingsupdates (reflog), die de geschiedenis van HEAD- en branch-verplaatsingen opslaan.

Het HEAD-bestand verdient speciale aandacht. In normale toestand bevat het een symbolische verwijzing naar een branch, bijvoorbeeld ref: refs/heads/main. In de detached HEAD-toestand verwijst het rechtstreeks naar een commit — dit betekent dat nieuwe commits aan geen enkele branch worden gekoppeld.

Belangrijkste bewerkingen met de repository

Werken met een Git-repository omvat een reeks basisbewerkingen die een ontwikkelaar dagelijks uitvoert. Elke bewerking verandert de staat van de repository door nieuwe objecten toe te voegen of verwijzingen te verplaatsen.

• git init — maakt een nieuwe lege repository aan in de huidige map. Git maakt de .git-map met de beginstructuur.
• git clone — kopieert een bestaande externe repository naar de lokale machine met de volledige commitgeschiedenis.
• git add — voegt bestandswijzigingen toe aan de staging area (index) en bereidt ze voor op een commit.
• git commit — maakt een snapshot van het project op basis van gegevens uit de index en slaat deze op als een nieuw commit-object.
• git push — stuurt nieuwe commits van de lokale repository naar de externe repository en werkt branches op de server bij.
• git pull — haalt nieuwe commits uit de externe repository en voegt ze samen met de huidige lokale branch.

De bewerkingen push en pull — zijn de enige die een verbinding met de externe server vereisen. Alle andere bewerkingen worden volledig lokaal uitgevoerd, wat een hoge werksnelheid garandeert, zelfs bij een grote geschiedenis.

Levenscyclus van een bestand in de repository

Elk bestand in de repository doorloopt vier toestanden: untracked (niet bijgehouden), modified (gewijzigd), staged (voorbereid) en committed (gecommit). Git houdt alleen bestanden bij die expliciet zijn toegevoegd via git add of al in de commitgeschiedenis staan.

Inzicht in dit model — de sleutel tot efficiënt werken met Git. De ontwikkelaar kan selectief slechts een deel van de gewijzigde bestanden voorbereiden voor een commit, waardoor logisch complete commits met duidelijke beschrijvingen ontstaan.

Populaire platforms voor het hosten van repositories

Externe repositories worden meestal gehost op gespecialiseerde platforms die een webinterface, toegangsbeheersysteem en extra tools voor gezamenlijke ontwikkeling bieden.

• GitHub — het grootste platform met meer dan 100 miljoen repositories. Biedt Actions, Pull Requests, Issues en Wiki. Gratis voor openbare projecten.
• GitLab — platform met geïntegreerde CI/CD, Container Registry en ingebouwde DevOps-pipeline. Beschikbaar als SaaS en self-hosted versie.
• Bitbucket — oplossing van Atlassian met integratie van Jira en Trello. Populair in de zakelijke omgeving vanwege flexibele toegangsinstellingen.

De keuze van het platform hangt af van de teamgrootte, privacyvereisten en benodigde integraties. Voor mobiele ontwikkeling wordt vaak GitHub gekozen vanwege de brede community-ondersteuning en integratie met CI/CD-tools voor iOS en Android.

Voorbeelden van commando's voor het werken met een repository

Laten we een praktisch scenario bekijken: een ontwikkelaar cloneert een bestaande repository, maakt een nieuwe branch aan, voert wijzigingen door en stuurt ze naar de server. Elk commando demonstreert het werken met verschillende componenten van de repository.

# Het klonen van een externe repository
git clone https://github.com/user/mobile-app.git

# Naar de projectdirectory gaan
cd mobile-app

# Een nieuwe feature-branch aanmaken en ernaar overschakelen
git checkout -b feature/auth

# De status van gewijzigde bestanden controleren
git status

# Alle wijzigingen toevoegen aan de staging area
git add .

# Een commit met beschrijving aanmaken
git commit -m "Add authentication module"

# Wijzigingen naar de externe repository sturen
git push origin feature/auth

Het commando git status — een van de nuttigste in het dagelijkse werk. Het toont welke bestanden zijn gewijzigd, welke zijn voorbereid voor een commit en welke helemaal niet door Git worden bijgehouden.

Commitgeschiedenis bekijken

Voor het analyseren van de repositorygeschiedenis wordt het commando git log gebruikt met verschillende opmaakvlaggen. Het toont de chronologie van commits, hun auteurs, datums en SHA-1-identificaties.

# Geschiedenis bekijken met visualisatie van de branch-graaf
git log --oneline --graph --all

# Wijzigingen in een specifieke commit bekijken
git show a1b2c3d

# Huidige status vergelijken met de laatste commit
git diff HEAD

# Geschiedenis van een specifiek bestand bekijken
git log --follow src/MainActivity.kt

De vlag --graph toont een ASCII-graaf van vertakkingen, wat vooral nuttig is in repositories met actief werk in meerdere branches. Voor mobiele projecten met frequente releases helpt de visuele graaf om de ontwikkelingsstructuur snel te beoordelen.