Git — wat is het, werkingsprincipes en commando's

Wat is Git?

Git — is een gedistribueerd versiebeheersysteem (VCS) dat wijzigingen in bestanden bijhoudt en meerdere ontwikkelaars in staat stelt tegelijkertijd aan hetzelfde project te werken. In tegenstelling tot gecentraliseerde systemen heeft in Git elke ontwikkelaar een volledige kopie van de repository, inclusief de volledige wijzigingsgeschiedenis, wat het systeem bestand maakt tegen gegevensverlies en geen constante verbinding met de centrale server vereist.

De geschiedenis van Git begon in 2005, toen Linus Torvalds een nieuwe VCS creëerde nadat BitKeeper de gratis licentie voor zijn systeem voor Linux-kernelontwikkelaars introk. Doelen waren: snelheid, architectuureenvoud, ondersteuning voor niet-lineaire ontwikkeling via vertakking en volledige distributie. In 3 maanden schreef Torvalds de kern van Git, en na een jaar ging het project over op zelfbeheer onder leiding van Junio Hamano.

Volgens de Stack Overflow-enquête (2024) gebruikt 93,9% van de professionele ontwikkelaars Git, wat het het dominante versiebeheersysteem in de industrie maakt. De dichtstbijzijnde concurrent — Subversion (SVN) — wordt slechts in 5,2% van de projecten gebruikt, voornamelijk in grote bedrijfsomgevingen met gecentraliseerde processen.

Hoe werkt Git: repository en commits

Git-repository — is een directory waarin Git wijzigingen van alle bestanden bijhoudt. Binnen de directory bevindt zich een verborgen map .git, waar alle objecten van het systeem worden opgeslagen: commits, bomen, blobs en verwijzingen. Wanneer een ontwikkelaar een commit maakt, kopieert Git niet de volledige bestanden — het maakt een snapshot van de status en slaat een verwijzing ernaar op.

Elke commit bevat: een unieke SHA-1 hash (40 tekens), een verwijzing naar de vorige commit (parent), auteur, datum, commitbericht en een verwijzing naar de boom (tree) die de bestandsstatus op het moment van de commit beschrijft. De keten van commits vormt een gerichte acyclische graaf, waarbij elke commit naar een of meerdere ouders verwijst.

# Repository initialiseren
git init my-project
cd my-project

# Commit maken
echo "Hello, Git" > README.md
git add README.md
git commit -m "Initial commit"

# Geschiedenis bekijken
git log --oneline --graph --all

Git gebruikt drie hoofdgebieden: working directory (bestanden op schijf), staging area (index waar voorbereide bestanden terechtkomen) en repository (commitgeschiedenis). Het commando git add verplaatst wijzigingen van de werkdirectory naar staging, en git commit legt de staging-inhoud vast in de repository. Deze scheiding stelt de ontwikkelaar in staat om een samenhangende commit uit een reeks wijzigingen samen te stellen, zonder elke aanpassing afzonderlijk vast te leggen.

Basis Git-commando's

De basis Git-commando's dekken 90% van de dagelijkse handelingen van een ontwikkelaar. Het commando git clone maakt een lokale kopie van een externe repository, git pull haalt wijzigingen van de server op en voegt ze samen met de huidige branch, en git push stuurt lokale commits naar de server. Deze drie commando's vormen de basiscyclus van het werken met Git.

Voor statusweergave wordt git status gebruikt — het laat zien welke bestanden zijn gewijzigd, welke aan staging zijn toegevoegd en welke niet worden gevolgd. git diff toont concrete wijzigingen in bestanden voordat ze aan staging worden toegevoegd. Hieronder staat een tabel met de meest gebruikte commando's:

Voor het ongedaan maken van wijzigingen biedt Git verschillende opties. git reset verplaatst de branchwijzer naar een opgegeven commit en kan staging of de werkdirectory resetten. git revert maakt een nieuwe commit die de wijzigingen van de opgegeven commit ongedaan maakt — dit is een veilige manier van ongedaan maken voor gedeelde branches, omdat de geschiedenis niet wordt herschreven.

Vertakking in Git: main, feature en release

Branches in Git — zijn lichte verplaatsbare wijzers naar een specifieke commit. Het maken van een nieuwe branch kopieert geen bestanden, maar creëert alleen een nieuwe wijzer, wat vertakking praktisch onmiddellijk maakt. De main-branch (voorheen master) — de hoofdbranch van het project, die stabiele, release-ready code bevat.

Standaardpraktijk is het gebruik van Git Flow of GitHub Flow. In Git Flow worden branches gebruikt: main (releasecode), develop (integratiebranch), feature/* (nieuwe functies), release/* (releasevoorbereiding) en hotfix/* (spoedreparaties). GitHub Flow is eenvoudiger: alleen main en feature-branches, en alle wijzigingen worden geleverd via Pull Request.

# Branch maken en overschakelen
git branch feature-auth
git checkout feature-auth
# of met één commando:
git checkout -b feature-auth

# Lijst van branches
git branch --list
git branch -a  # alle branches, inclusief verwijderde

# Branch verwijderen
git branch -d feature-auth

Een belangrijke eigenschap van vertakking in Git — de mogelijkheid van cherry-pick: het overbrengen van een individuele commit van de ene branch naar de andere met het commando git cherry-pick <hash>. Dit is handig wanneer je een bugfix van een feature-branch naar release moet overbrengen zonder de hele branch samen te voegen. Git ondersteunt ook rebasen en interactief rebasen (git rebase -i) voor het plakken, herordenen en bewerken van commits.

Samenvoegen: Merge en Rebase

Merge (samenvoegen) maakt een speciale merge-commit met twee ouders. Deze commit registreert het feit van het samenvoegen van twee branches en behoudt de volledige geschiedenis — het is zichtbaar waar en wanneer de samenvoeging plaatsvond. Merge behoudt de geschiedenis in de vorm waarin deze is gemaakt, wat auditing vereenvoudigt, maar de commitgraaf complexer maakt.

Rebase (herbaseren) verplaatst in plaats van het maken van een merge-commit de commits van de huidige branch naar de top van de doelbranch. De geschiedenis wordt lineair — het wekt de indruk dat de ontwikkeling sequentieel heeft plaatsgevonden. Rebase herschrijft echter de geschiedenis, waarbij SHA-1 hashes van commits veranderen, wat het gevaarlijk maakt voor gedeelde branches waar andere ontwikkelaars toegang toe hebben.

Aanbeveling voor keuze: gebruik merge voor publieke branches waar de geschiedenis door andere ontwikkelaars wordt gezien (feature → develop), en rebase voor lokaal werk wanneer je verse wijzigingen uit main in je feature-branch moet toepassen voordat je een Pull Request maakt. De regel is eenvoudig: als een commit al naar de server is gestuurd — herbasis hem dan niet.

Conflicten oplossen

Samenvoegconflict ontstaat wanneer Git wijzigingen in één bestand niet automatisch kan combineren. Git markeert conflicterende delen in het bestand met speciale markers: <<<<<<< (onze wijzigingen), ======= (scheidingsteken), >>>>>>> (hun wijzigingen). De ontwikkelaar bewerkt het bestand handmatig, kiest de gewenste optie of combineert beide, en voltooit de samenvoeging met een commit.

Werken met externe repositories

Externe repository (remote) — een kopie van de Git-repository die op een server staat. GitHub, GitLab en Bitbucket zijn de populairste platforms voor het hosten van externe repositories. Ze bieden een webinterface voor het bekijken van code, toegangsbeheer, code review en integratie met CI/CD-systemen.

In Git kunnen meerdere externe repositories voor één project worden geconfigureerd. Standaard heet de belangrijkste remote origin. Het commando git remote add voegt een nieuwe remote toe, git fetch haalt wijzigingen op zonder samenvoegen, en git pull is een verkorte vorm voor git fetch + git merge. Voor het werken met code via Pull Request maakt de ontwikkelaar een fork van de repository, kloont deze, werkt in een feature-branch en stuurt een samenvoegverzoek naar de originele repository.

# Externe repository toevoegen
git remote add origin https://github.com/user/repo.git

# Externe repositories bekijken
git remote -v

# Branch naar server sturen
git push -u origin feature-auth

# Wijzigingen van externe branch ophalen
git pull origin main

Externe repositories ondersteunen tagging voor het markeren van releaseversies. Tags kunnen licht zijn (gewoon een wijzer naar een commit) en geannoteerd (bevatten metadata: auteur, datum, bericht). Geannoteerde tags worden aanbevolen voor releaseversies, omdat ze volledige informatie over de versie overdragen en kunnen worden ondertekend met een GPG-sleutel voor verificatie van het auteurschap.

Git Worktree voor parallel werk

Git Worktree maakt het mogelijk om gelijktijdig met meerdere branches in verschillende directories te werken zonder ertussen te schakelen. Het commando git worktree add ../feature-auth feature-auth maakt een nieuwe werkdirectory feature-auth aan, waar code kan worden geschreven zonder de branch in de hoofddirectory te wijzigen. Worktree is handig voor snelle fixes in de release-branch wanneer de hoofddirectory bezet is met langdurige ontwikkeling.

Git Submodules voor afhankelijkheden

Git Submodules — een mechanisme om de ene Git-repository in de andere op te nemen. Een submodule slaat een verwijzing naar een vaste commit van een externe repository op, wat reproduceerbaarheid van de build garandeert. Het commando git submodule add https://github.com/example/lib.git voegt een externe bibliotheek toe als submodule. Bij het klonen van een project met submodules moet git submodule update --init --recursive worden uitgevoerd om alle afhankelijkheden te laden.