Leerpad
Git is een onmisbare tool in de gereedschapskist van moderne developers, bekend om zijn krachtige versiebeheermogelijkheden. Git werd in 2005 door Linus Torvalds gemaakt ter ondersteuning van de ontwikkeling van de Linux-kernel en is sindsdien de ruggengraat geworden van talloze softwareprojecten wereldwijd. De efficiëntie en flexibiliteit in het beheren van projectversies, in combinatie met robuuste ondersteuning voor samenwerking, maken het onmisbaar voor teams van elke omvang.
Dit artikel helpt je voorbereiden op technische interviews door de top 20 Git-sollicitatievragen te behandelen, van beginner tot gevorderd. Of je nu nieuw bent met Git of je kennis wilt verdiepen, met deze vragen en antwoorden kun je je vaardigheden laten zien en je interview succesvol afronden.
Basis Git-sollicitatievragen
Als je relatief nieuw bent met Git, zullen sommige basisvragen in interviews waarschijnlijk gaan over beginnerconcepten en -gebruik. Als je dit wilt opfrissen, bekijk dan zeker DataCamp’s cursus Introduction to Git.
Wat is een Git-repository?
Een Git-repository slaat de bestanden en revisiegeschiedenis van een project op en faciliteert versiebeheer door wijzigingen in de tijd bij te houden. Deze kan lokaal in een map op je apparaat staan of op een online platform zoals GitHub. Dit stelt gebruikers in staat samen te werken, terug te keren naar eerdere versies en de projectontwikkeling efficiënt te beheren met commando’s als commit, push en pull.
Hoe werkt Git?
Git werkt door wijzigingen in bestanden en mappen van een project vast te leggen en zo momentopnames van de evoluerende toestand te maken. Gebruikers kunnen veranderingen beheren, branches maken voor parallelle ontwikkeling, branches mergen en indien nodig terugkeren naar eerdere staten. Het bevordert samenwerking en zorgt voor effectief versiebeheer in softwareontwikkeling.
Wat is git add?
Het commando git add wordt in Git gebruikt om wijzigingen te stagen voor opname in de volgende commit. Het bereidt aanpassingen, toevoegingen of verwijderingen in de working directory voor en markeert ze om te worden opgenomen in de komende commit-snapshot. Let op: dit commando maakt de commit niet; het bereidt de wijzigingen alleen voor op staging.
Wat is git push?
Het commando git push wordt in Git gebruikt om de inhoud van een lokale repository te uploaden naar een remote repository. Het verplaatst gecommitte wijzigingen van de lokale repository naar een remote, meestal op een server zoals GitHub of GitLab. Dit commando maakt samenwerking mogelijk doordat gebruikers hun wijzigingen kunnen delen met anderen die aan hetzelfde project werken.
Je kunt meer leren over Git push en pull in onze aparte tutorial.
Wat is git status?
Het commando git status toont de huidige staat van de repository in Git. Het geeft informatie over welke bestanden zijn gewijzigd, welke zijn gestaged voor de volgende commit en welke ongetrackt zijn. Het helpt gebruikers hun voortgang bij te houden en te zien welke veranderingen nog gecommit of gestaged moeten worden.
Wat is een commit in Git?
Een commit vertegenwoordigt een momentopname van de wijzigingen die op een bepaald moment in de repositorybestanden zijn aangebracht. Wanneer je wijzigingen commit in Git, sla je feitelijk de huidige staat van je bestanden op en kun je een beschrijvende boodschap meegeven die uitlegt welke wijzigingen zijn gedaan (aanbevolen).
Elke commit krijgt een unieke identifier, zodat je de geschiedenis van wijzigingen in de repository kunt volgen. Commits spelen een cruciale rol in versiebeheer, omdat ze een manier bieden om terug te keren naar eerdere toestanden van het project, de geschiedenis te bekijken en samen te werken door updates te delen.

Bekijk de Git-spiekbrief van DataCamp om je voor te bereiden op je interview
Wat is branching in Git?
Branching verwijst naar het afsplitsen van de hoofdontwikkellijn (meestal de branch main, voorheen master genoemd) om te werken aan nieuwe features, fixes of experimenten zonder de hoofdbasis te beïnvloeden. Het maakt meerdere parallelle ontwikkellijnen binnen dezelfde repository mogelijk.
Elke branch vertegenwoordigt een aparte ontwikkellijn met een eigen set commits, waardoor developers gelijktijdig aan verschillende features of fixes kunnen werken. Branching faciliteert samenwerking, experimentatie en structuur binnen een project, omdat wijzigingen in een branch kunnen worden teruggemerged in de hoofdcode zodra ze klaar en getest zijn.
Wat is een conflict in Git?
Conflicten ontstaan wanneer tegenstrijdige wijzigingen aan hetzelfde deel van een bestand of bestanden door verschillende bijdragers worden gemaakt, meestal tijdens een merge- of rebase-actie. Git kan deze conflicterende wijzigingen niet automatisch oplossen, waardoor handmatig ingrijpen nodig is om de verschillen te verhelpen.
Om een conflict op te lossen, open je het betreffende bestand — Git markeert de conflicterende secties met de markeringen <<<<<<<, ======= en >>>>>>>. Bewerk het bestand om de juiste versie te behouden, verwijder de markeringen en voer daarna uit:
git add <resolved-file>
git commit
git mergetool kunnen dit proces visueel maken en makkelijker te doorlopen.Wat is merge in Git?
Mergen is een fundamentele bewerking in Git die samenwerking en de integratie van wijzigingen tussen verschillende branches in een project mogelijk maakt. Een merge is het proces waarbij wijzigingen uit verschillende branches worden samengevoegd in één branch, meestal de hoofdbranch (bijv. master of main).
Een merge integreert de veranderingen uit de ene branch met een andere en resulteert in een nieuwe commit die de geschiedenissen van beide branches combineert. Je kunt meer leren over hoe je merge-conflicten in Git oplost in onze aparte tutorial.
Intermediaire Git-sollicitatievragen
Wat is een remote in Git?
Een remote is een repository die gehost wordt op een server of een andere computer voor samenwerking en het delen van code met anderen. Het fungeert als een gecentraliseerde locatie waar developers hun lokale wijzigingen naartoe kunnen pushen en wijzigingen van anderen kunnen pullen.
Remotes worden doorgaans ingesteld op hostingplatforms zoals GitHub, GitLab of Bitbucket. Ze maken gedistribueerde ontwikkeling mogelijk en bevorderen teamwork door een gemeenschappelijke locatie te bieden voor het opslaan en synchroniseren van projectcode tussen meerdere bijdragers.
Hoe draai je een commit terug die al gepusht en openbaar is gemaakt?
Het commando git revert <commit-hash> kan worden gebruikt om een commit terug te draaien die al is gepusht en openbaar is gemaakt.
Het stapsgewijze proces is als volgt:
1. Identificeer de commit waarnaar je wilt terugdraaien door de commit-hash te vinden. Dit kan met het commando git log om de geschiedenis te bekijken en de gewenste commit-hash te vinden.
2. Gebruik, zodra je de commit-hash hebt, het commando git revert gevolgd door de commit-hash om een nieuwe commit te maken die de door de opgegeven commit geïntroduceerde wijzigingen ongedaan maakt. Bijvoorbeeld:
git revert <commit-hash>
3. Git opent een teksteditor om een commitboodschap voor de revert te maken. Je kunt de boodschap aanpassen indien nodig en vervolgens de editor opslaan en sluiten.
4. Na het opslaan van de commitboodschap maakt Git een nieuwe commit die de wijzigingen van de opgegeven commit effectief ongedaan maakt. Deze nieuwe commit wordt aan de geschiedenis toegevoegd en draait de oorspronkelijke wijzigingen terug.
5. Push tot slot de nieuwe commit naar de remote repository om de revert openbaar te maken met het volgende commando:
git push origin <branch-name>
Door git revert te gebruiken maak je een nieuwe commit die de wijzigingen van de oorspronkelijke commit ongedaan maakt, zonder de geschiedenis te wijzigen. Deze aanpak is veiliger dan git reset of git amend, die de geschiedenis kunnen veranderen en problemen kunnen veroorzaken voor collega’s die de wijzigingen al hebben gepulld.
Wat is git stash?
git stash is een Git-commando dat tijdelijk wijzigingen in de working directory opslaat die nog niet klaar zijn om te committen. Het stelt developers in staat hun aanpassingen te bewaren zonder ze te committen naar de repository.
Stashen is handig wanneer je van branch wisselt, maar je je wijzigingen niet wilt committen of verliezen. Later kun je de gestashte wijzigingen toepassen op je working directory of ze van de stash-stack poppen om er weer aan te werken.
Wat is git reflog?
git reflog is een Git-commando om de referentielogs te bekijken, die wijzigingen in de HEAD-pointer en de geschiedenis van gecheckte commits in de repository vastleggen. Het geeft een chronologische lijst van recente acties in de repository, waaronder commits, checkouts, merges en resets.
De reflog is nuttig om verloren commits of branches terug te vinden en om de volgorde van acties in de repository te begrijpen.
Hoe laat je een bestaande Git-branch een remote branch tracken?
Om een bestaande Git-branch een remote branch te laten tracken, kun je het commando git branch gebruiken met de optie --set-upstream-to of -u, gevolgd door de naam van de remote branch.
De syntax ziet er als volgt uit:
git branch --set-upstream-to=<remote-name>/<branch-name>
of
git branch -u <remote-name>/<branch-name>
Geavanceerde Git-sollicitatievragen
Hoe beheer je meerdere configuraties voor verschillende projecten in Git?
Gebruik voor verschillende configuraties het commando git config samen met de vlaggen --global, --system of --local om instellingen op verschillende niveaus aan te passen. Of gebruik includeIf in de Git-configuratie om specifieke setups op te nemen op basis van het pad van de repository.
Hoe ga je om met grote bestanden in Git?
Werken met grote bestanden in Git kan een uitdaging zijn vanwege de impact op de grootte en prestaties van de repository. Gebruik Git LFS om grote bestanden buiten de Git-repository op te slaan, terwijl er lichte pointers naar die bestanden in de repository blijven. Dit verkleint de repository en verbetert de prestaties. Git LFS ondersteunt diverse opslagproviders en integreert naadloos met Git-workflows.
Waarvoor gebruik je git submodule en hoe update je er een?
Het commando git submodule beheert externe afhankelijkheden binnen een Git-repository. Het stelt je in staat externe repositories als submodules op te nemen binnen je hoofdrepository. Dit is handig wanneer je code van externe bronnen wilt opnemen en toch gescheiden wilt houden van de codebasis van je hoofdproject.
Om een submodule in Git te updaten, kun je de volgende stappen volgen:
-
Navigeer naar de map van de submodule binnen je hoofdrepository.
-
Gebruik
git fetchom de laatste wijzigingen van de remote repository van de submodule op te halen. -
Als je wilt updaten naar de laatste commit op de branch die door de submodule wordt getrackt, kun je
git pullgebruiken. -
Als je in plaats daarvan naar een specifieke commit of branch wilt updaten, gebruik dan
git checkoutgevolgd door de gewenste commit-hash of branchnaam. -
Als je de submodule naar de gewenste staat hebt bijgewerkt, moet je de wijzigingen in de hoofdrepository committen om de geüpdatete submodulestatus vast te leggen.
Wat is git cherry-pick en wanneer gebruik je het?
git cherry-pick laat je een specifieke commit van de ene branch toepassen op een andere, zonder de hele branch te mergen.
git cherry-pick <commit-hash>
main-branch, maar je die fix ook nodig hebt in een release-branch — je kunt dan alleen die commit cherry-picken in plaats van heel main te mergen in release.Het is ook handig wanneer per ongeluk een commit op de verkeerde branch is gemaakt: cherry-pick die commit naar de juiste branch en revert hem vervolgens op de plek waar hij niet hoort.
Wat is git bisect en waarvoor gebruik je het?
git bisect is een debuggingtool die binaire zoekopdrachten gebruikt om de specifieke commit te vinden die een bug heeft geïntroduceerd. In plaats van handmatig commits één voor één te checken, vertel je Git welke commit "goed" (bugvrij) is en welke "slecht" (bevat de bug) is. Git zal dan commits daartussen uitchecken en telkens het zoekgebied halveren totdat de boosdoener gevonden is.
git bisect start
git bisect bad # huidige commit bevat de bug
git bisect good <commit-hash> # deze oudere commit was in orde
# Git checkt een commit ertussen uit; je test hem, daarna:
git bisect good # of git bisect bad
# herhaal totdat Git de eerste slechte commit identificeert
git bisect reset # keer terug naar de oorspronkelijke staat wanneer je klaar bent
Dit is veel sneller dan handmatig zoeken in grote repositories met honderden commits.
Wat zijn Git hooks en hoe worden ze gebruikt?
Git hooks zijn scripts die automatisch draaien op specifieke momenten in de Git-workflow. Ze staan in de map .git/hooks/ van een repository en kunnen in elke scripttaal geschreven zijn.
Er zijn twee types:
-
Client-side hooks draaien op je lokale machine — bijvoorbeeld
pre-commit(draait voordat een commit wordt gemaakt) ofcommit-msg(valideert het commitbericht-formaat). -
Server-side hooks draaien op de remote server — bijvoorbeeld
pre-receive(draait voordat gepushte commits worden geaccepteerd).
Een veelgebruikte toepassing is een pre-commit-hook gebruiken om automatisch een linter of test suite te draaien voordat een commit wordt toegestaan. Dit handhaaft codekwaliteitsstandaarden binnen het team.
Let op dat hooks niet worden gekopieerd wanneer je een repository clonet, dus teams die erop vertrouwen, delen ze meestal via een apart script of een tool zoals pre-commit (het Python-pakket).
Vragen over vaak verwarde Git-concepten
Wat is het verschil tussen git fetch en git pull?
Het belangrijkste verschil tussen git fetch en git pull zit in wat ze doen en hoe ze de lokale repository bijwerken.
Het commando git fetch haalt wijzigingen op uit een remote repository naar de lokale repository. Het werkt de remote-tracking branches (bijv. origin/master) in de lokale repository bij zodat ze de staat van de remote weerspiegelen, maar het werkt de working directory niet bij en merge’t geen wijzigingen in de huidige branch. Na een fetch kun je de wijzigingen in de remote bekijken zonder je lokale werk te beïnvloeden.
Het commando git pull haalt ook wijzigingen op uit een remote repository, maar gaat een stap verder door veranderingen te fetchen en ze in één stap te mergen in de huidige branch. Het voert in feite een git fetch gevolgd door een git merge uit om de wijzigingen van de remote in de huidige branch op te nemen.
Wat doet git reset?
Het commando git reset zet de huidige HEAD terug naar een opgegeven staat. Dit betekent dat het kan worden gebruikt om wijzigingen ongedaan te maken, bestanden te unstage’n of de HEAD-pointer naar een andere commit te verplaatsen. Let op: er zijn drie hoofdmodi van git reset:
--soft: Zet de HEAD-pointer terug naar een specifieke commit en houdt wijzigingen gestaged. Bestanden blijven aangepast in de working directory, zodat je ze opnieuw kunt committen.
--mixed: Zet de HEAD-pointer terug naar een specifieke commit en unstage’t wijzigingen. Bestanden blijven aangepast in de working directory, maar wijzigingen zijn niet gestaged voor commit.
--hard: Zet de HEAD-pointer terug naar een specifieke commit en gooit alle wijzigingen in de working directory en staging area weg. Gebruik met voorzichtigheid, want dit verwijdert niet-gecommitte wijzigingen permanent.
Belangrijk: Gebruik nooit git reset --hard op commits die al naar een gedeelde remote branch zijn gepusht. Het herschrijft geschiedenis en veroorzaakt serieuze problemen voor teamgenoten die die commits al hebben gepulld. Gebruik in plaats daarvan git revert voor publieke commits.
Wat is het belang van git push --force-with-lease ten opzichte van git push --force?
git push --force-with-lease is een voorzichtiger manier om wijzigingen geforceerd naar een remote repository te pushen dan git push --force, omdat het voorkomt dat je per ongeluk wijzigingen van anderen op de remote overschrijft.
Wanneer je git push --force gebruikt, forceer je je push naar de remote repository, ongeacht of anderen deze sinds je laatste fetch hebben bijgewerkt. Dit kan leiden tot onbedoeld verlies van werk van andere developers.
Daarentegen is git push --force-with-lease een veiliger alternatief. Het controleert of de remote branch waarnaar je pusht sinds je laatste fetch is bijgewerkt door anderen. Als de remote branch is bijgewerkt, wordt de push geweigerd, zodat je niet per ongeluk werk van anderen overschrijft.
Wat is git rebase en hoe verschilt het van git merge?
Zowel git rebase als git merge integreren wijzigingen van de ene branch in een andere, maar doen dat op verschillende manieren.
-
git mergecombineert de geschiedenissen van twee branches door een nieuwe "merge commit" te maken. Dit behoudt de volledige geschiedenis van wanneer branches uiteengingen en weer samenkwamen, wat nuttig is voor audittrails en transparantie binnen het team. -
git rebaseverplaatst of herhaalt commits van de ene branch boven op een andere, wat resulteert in een schone, lineaire geschiedenis zonder merge commits. Dit maakt de log leesbaarder, maar herschrijft de geschiedenis. Daarom is de gouden regel van rebasen: rebase nooit een branch waar anderen aan werken.
Wat is het verschil tussen git clone en git fork?
Clonen maakt een lokale kopie van een remote repository op je machine. Je blijft verbonden met dezelfde repository en kunt wijzigingen terug pushen (als je rechten hebt).
git clone https://github.com/user/repo.git
Forken is de standaardworkflow voor bijdragen aan open-sourceprojecten waar je geen directe schrijfrechten hebt op de originele repo.
Voorbereiden op een Git-interview
Je Git-kennis en -ervaring goed presenteren tijdens interviews is cruciaal om je vaardigheid in versiebeheer en samenwerking binnen softwareteams te laten zien.
Laten we enkele tips bekijken die je kunt volgen bij de voorbereiding op je technische interview om je Git-vaardigheden effectief over te brengen:
Begrijp de Git-basis
Zorg dat je een stevige basis hebt in Git-fundamenten, waaronder repositories, branching, mergen, commits en basiscommando’s zoals pull, push, clone en commit. Deze basiskennis vormt het fundament van je gesprek tijdens het interview. Het helpt ook als je de kernprincipes van versiebeheer goed begrijpt en de verschillen tussen Git en andere versiebeheersystemen kunt duiden.
Maak je ten slotte vertrouwd met verschillende Git-methodologieën, zoals Git Flow, GitHub Flow en GitLab Flow. Beoordeel de voor- en nadelen van elk en herken de situaties waarin ze het meest geschikt zijn.
Onze complete gids voor Git is een goed startpunt om je de basis eigen te maken.
Doe praktische ervaring op
Hoe meer je Git gebruikt, hoe beter je kennis beklijft. Regelmatige oefening vergroot je vertrouwdheid met verschillende commando’s en procedures. Probeer Git in je dagelijkse workflow op te nemen om meer ervaring op te doen. Experimenteer met het maken van branches, het mergen ervan en het oplossen van conflicten.
Als je niet weet aan welke projecten je kunt werken om hands-on ervaring met Git op te doen, is meedoen aan open-sourceprojecten via platforms zoals GitHub een uitstekende manier om directe ervaring op te doen met branchstandaard tools en workflows voor samenwerking.
Leer veelvoorkomende problemen en hoe je ze oplost
Je zult onvermijdelijk problemen tegenkomen bij het gebruik van Git. Veelvoorkomende issues zijn merge-conflicten, detached HEAD-states, wijzigingen terugdraaien en verloren commits herstellen. Het diagnosticeren van Git-problemen scherpt je troubleshootingvaardigheden en verdiept je begrip van de onderliggende mechanismen van Git.
Door actief te troubleshooten en foutmeldingen te analyseren, krijg je inzicht in de interne werking van Git en ontwikkel je vaardigheid in het efficiënt identificeren en oplossen van problemen. Deze proactieve aanpak verkleint risico’s en bouwt effectief aan zelfvertrouwen en expertise in het beheren van versiebeheerworkflows.
Oefen met proefinterviews
Door proefinterviews te doen, kunnen kandidaten zwakke punten in hun Git-kennis en communicatievaardigheden identificeren, zodat ze hun voorbereiding gericht kunnen aanscherpen.
Bovendien bieden proefinterviews waardevolle kansen om probleemoplossend vermogen te verfijnen door realistische Git-scenario’s en codeeroefeningen aan te pakken. Deze praktijk helpt kandidaten vertrouwen te krijgen in hun Git-vaardigheden en verbetert hun vermogen om tijdens het interview helder te formuleren.
Conclusie
Git is een krachtig versiebeheersysteem dat veel wordt gebruikt in softwareontwikkeling om codewijzigingen te beheren, samen te werken en projectgeschiedenis te behouden. Vertrouwd zijn met Git is essentieel in technische interviews, omdat het aantoont dat je over de belangrijkste ontwikkeltools en -workflows beschikt, samenwerkingsvaardigheden laat zien en benadrukt dat je code effectief kunt beheren in teamomgevingen.
Daarnaast stelt begrip van Git-concepten en -commando’s je in staat om efficiënt versiebeheer toe te passen, wat zorgt voor code-integriteit, projectcontinuïteit en gestroomlijnde ontwikkelprocessen. Kennis van Git is dus van onschatbare waarde voor aanstaande software engineers en developers die technische interviews doorlopen en een succesvolle carrière nastreven.
Voor verder leren, bekijk de volgende bronnen:

