De belangrijkste Git-commando's die je als developer moet kennen

Wie met software werkt, komt vroeg of laat bij Git uit. Het is de stille motor achter versiebeheer, samenwerking en het veilig uitproberen van wijzigingen. Toch gebruiken veel developers maar een klein deel van de mogelijkheden, terwijl een paar basiscommando's al genoeg zijn om veel rust en overzicht te krijgen. Wie Git goed beheerst, werkt sneller, maakt minder fouten en durft makkelijker te experimenteren.

Git voelt in het begin soms alsof je een extra laag administratie toevoegt aan je werk. In de praktijk doet het precies het tegenovergestelde. Het helpt je om wijzigingen stap voor stap vast te leggen, terug te draaien als dat nodig is en samen te werken zonder elkaars werk te overschrijven. Voor wie naast Git ook breder wil groeien als developer, helpt het om het totaalplaatje te zien, bijvoorbeeld via Tips en Productiviteit.

Waarom Git zo belangrijk is

Git is een versiebeheersysteem. Dat betekent dat het veranderingen in je code bijhoudt, zodat je later kunt zien wat er is aangepast, door wie en waarom. Dat is handig voor solo-projecten, maar onmisbaar in teams. Je kunt fouten herstellen, experimenten apart houden en tegelijk aan meerdere onderdelen werken zonder chaos.

Het grote voordeel van Git is dat het lokaal werkt. Je hebt niet voor elke handeling direct een server nodig. Daardoor kun je commando's uitvoeren, geschiedenis bekijken en wijzigingen voorbereiden voordat je ze deelt met anderen. Dat maakt Git snel, flexibel en betrouwbaar.

Veel beginners denken dat Git hetzelfde is als GitHub, maar dat klopt niet. Git is de techniek, GitHub is een dienst om repositories online te bewaren en samen te werken. Je kunt Git dus prima gebruiken zonder GitHub, al maken online platforms samenwerken wel veel makkelijker.

De basis van een Git-workflow

De meeste dagelijkse Git-taken draaien om een eenvoudige cyclus. Je bekijkt wat er is veranderd, kiest welke aanpassingen je wilt bewaren, zet die klaar, legt ze vast en deelt ze eventueel met een centrale opslag.

1. Controleer de status van je project.
2. Bekijk de verschillen met de vorige versie.
3. Voeg relevante wijzigingen toe aan de stage area.
4. Maak een commit met een duidelijke boodschap.
5. Haal updates op van de centrale repository of stuur jouw werk naar buiten.

Als je deze cyclus begrijpt, worden de meeste commando's logisch. De rest is vooral oefening en routine.

De commando's die je elke week gebruikt

git status, je belangrijkste gewoonte

git status is het commando dat je het vaakst zou moeten gebruiken. Het geeft aan of er wijzigingen zijn, of bestanden al klaarstaan voor een commit en of je branch voor of achterloopt op de remote. Zonder dit commando werk je sneller op gevoel dan op feiten.

Veel Git-problemen ontstaan simpelweg doordat iemand niet eerst heeft gekeken wat er eigenlijk aan de hand is. Een statuscontrole kost seconden en voorkomt verwarring. Zie het als een snelle inspectie van je werkruimte.

git add, bewust selecteren wat je bewaart

Met git add kies je welke wijzigingen in de volgende commit komen. Dat klinkt klein, maar het is een van de sterkste gewoontes in goed versiebeheer. Je hoeft niet alles in één keer vast te leggen. Je kunt eerst alleen de relevante stukken toevoegen.

Dat is vooral nuttig als je meerdere dingen tegelijk hebt aangepast. Bijvoorbeeld een bugfix en een kleine stijlwijziging. Door die apart te committen blijft je geschiedenis schoner en later beter te begrijpen.

git commit, de momentopname met betekenis

Een commit is meer dan een technische opslag, het is een inhoudelijke mijlpaal. Een goede commit beschrijft wat er is veranderd en liefst ook waarom. De boodschap moet later nog begrijpelijk zijn, voor jezelf en voor anderen.

Een slechte gewoonte is om grote, vage commits te maken zoals update of fix. Beter is het om kort en concreet te zijn, bijvoorbeeld formulier validatie toegevoegd of caching aangepast voor snellere laadtijd. Dat maakt terugzoeken veel eenvoudiger.

git pull en git push, samenwerken zonder handmatig kopiëren

git pull haal je uit de centrale repository op. git push stuur je jouw eigen commits naar die centrale plek. Samen zorgen ze ervoor dat iedereen met dezelfde codebasis werkt, zonder bestanden heen en weer te mailen of handmatig te kopiëren.

Toch moet je bij beide commando's opletten. Een pull kan samenvoegconflicten veroorzaken als jij en iemand anders dezelfde regels hebben aangepast. Een push kan worden geweigerd als iemand anders al nieuwe commits heeft gedeeld. Dat is geen fout van Git, maar een beveiliging om werkverlies te voorkomen.

Handige commando's om verschillen te bekijken

Git is niet alleen bedoeld om wijzigingen op te slaan, maar ook om ze te begrijpen. Vooral bij bugs of onduidelijke aanpassingen is het belangrijk dat je precies ziet wat er is veranderd.

git diff, de inhoudelijke vergelijking

Met git diff bekijk je het verschil tussen twee versies. Dat kan tussen je werkmap en de stage area zijn, of tussen commits onderling. Het commando laat je zien welke regels zijn toegevoegd, verwijderd of aangepast.

Dit is nuttig als je wilt controleren of een wijziging echt klopt voordat je deze vastlegt. Het helpt ook bij code reviews, omdat je beter kunt beoordelen wat een wijziging inhoudt zonder direct door hele bestanden te bladeren.

git log, de geschiedenis lezen

git log laat zien welke commits er eerder zijn gemaakt. Je ziet meestal de commit-id, de auteur, de datum en de boodschap. Daarmee kun je snel achterhalen wanneer iets is veranderd.

Als je een bug zoekt, is de log vaak het startpunt. Je kunt terugzien welke wijziging mogelijk relevant is en zo stap voor stap de oorzaak vinden. Dat is veel effectiever dan willekeurig dingen aanpassen.

git show, één wijziging in detail

Met git show bekijk je de inhoud van een specifieke commit. Dat is handig als je alleen de details van één wijziging wilt zien, zonder de hele geschiedenis door te spitten. Het commando is vooral nuttig als je een oudere aanpassing opnieuw wilt begrijpen.

Werken met branches

Branches zijn een van de krachtigste onderdelen van Git. Ze maken het mogelijk om los van de hoofdversie te werken aan een nieuwe functie, een bugfix of een experiment. Zo blijft de stabiele code beschermd terwijl jij iets nieuws probeert.

Een branch is geen kopie van je hele project in de letterlijke zin. Het is eerder een verwijzing naar een andere lijn in de geschiedenis. Daardoor is het maken en wisselen van branches snel en licht. Dat is een belangrijk ontwerpkeuze van Git, omdat het experimenteren laagdrempelig maakt.

git branch en git switch

Met git branch bekijk je welke branches er bestaan. Met git switch ga je naar een andere branch. Samen zorgen ze ervoor dat je gecontroleerd kunt werken aan verschillende taken.

Voor veel teams is dit de standaardaanpak. Je maakt een branch voor een taak, werkt daarin door totdat het af is en voegt het daarna samen met de hoofdbranch. Dat voorkomt dat onvolledig werk direct in de hoofdcode terechtkomt.

git merge, werk samenvoegen

Als een taak klaar is, gebruik je vaak git merge om een branch samen te voegen met een andere branch. Git probeert de verschillen automatisch te combineren. Dat lukt meestal als verschillende mensen aan verschillende bestanden of regels hebben gewerkt.

Een mergeconflict ontstaat wanneer Git niet veilig kan bepalen welke wijziging moet blijven staan. Dat vraagt om handmatige controle. Het is niet prettig, maar wel logisch, want Git weigert dan bewust om te gokken.

Wanneer branches echt helpen

Branches zijn vooral handig als je:

• een nieuwe functie wilt bouwen zonder de hoofdversie te breken
• een bug wilt oplossen terwijl ander werk doorgaat
• een idee wilt testen dat misschien weer verdwijnt
• met meerdere mensen aan dezelfde code werkt

Werk je alleen en klein, dan kun je ver komen met weinig branches. Maar zodra een project groeit, maken branches je werk overzichtelijker en veiliger.

Veelgebruikte herstelcommando's

Iedere developer maakt fouten, en Git is juist sterk in herstel. Belangrijk is wel dat je begrijpt wat een commando doet voordat je het gebruikt. Niet elk herstel is hetzelfde, en sommige ingrepen hebben meer impact dan je denkt.

git restore, wijzigingen terugdraaien in je werkmap

Met git restore maak je lokale, nog niet vastgelegde wijzigingen ongedaan. Dat is handig als je in een bestand iets hebt geprobeerd dat niet goed werkt. Je haalt dan de versie terug die Git eerder kende.

Gebruik dit voorzichtig. Alles wat nog niet gecommit is, kan hiermee verdwijnen. Controleer dus eerst met git status wat je precies gaat terugzetten.

git reset, een stap verder terug

git reset is krachtiger. Je kunt er bijvoorbeeld een commit van de stage area halen of, in bepaalde vormen, commits in je lokale geschiedenis terugdraaien. Dat maakt het een nuttig maar ook gevoelig commando.

Het belangrijkste verschil is dat reset de geschiedenis kan aanpassen. Dat is prima op een lokale branch waar niemand anders op vertrouwt, maar riskant op gedeelde branches. Daar is voorzichtigheid essentieel.

git revert, veilig terugdraaien met een nieuwe commit

Als je een commit wilt ongedaan maken zonder de geschiedenis te herschrijven, gebruik je vaak git revert. Git maakt dan een nieuwe commit die de eerdere wijziging opheft. Dat is meestal veiliger voor gedeelde branches.

Dit is een goed voorbeeld van waarom Git meerdere herstelopties heeft. Soms wil je alleen lokaal iets corrigeren, soms wil je een fout uit de gedeelde geschiedenis terugdraaien. De juiste keuze hangt af van de situatie.

Commando's die je helpen als het misgaat

Zelfs ervaren developers lopen regelmatig tegen lastige situaties aan. Een branch is verdwenen, een merge loopt vast of je weet niet meer wat de laatste goede versie was. Dan helpt het als je een paar extra commando's kent.

git stash, tijdelijk opruimen

git stash zet onvoltooide wijzigingen tijdelijk aan de kant. Dat is handig als je plots iets anders moet doen, bijvoorbeeld een hotfix of een snelle pull. Later haal je je werk weer terug.

Het voordeel is dat je werkmap schoon wordt zonder dat je half werk hoeft te committen. Het nadeel is dat je moet onthouden wat je in de stash hebt gezet. Gebruik het dus als tijdelijke parkeerplek, niet als archief.

git remote -v, weten waar je mee praat

Met git remote -v zie je welke externe repository aan je lokale project gekoppeld is. Dat is nuttig als je meerdere omgevingen hebt of wilt controleren waar je push en pull precies naartoe gaan.

Dit voorkomt ongelukken, vooral wanneer een project meerdere remotes heeft. Je wilt niet per ongeluk code naar de verkeerde omgeving sturen.

git fetch, eerst ophalen zonder samenvoegen

Met git fetch haal je de nieuwste informatie op van de remote, zonder direct samen te voegen met je lokale branch. Dat geeft je tijd om eerst te kijken wat er nieuw is voordat je iets in je eigen werk mengt.

Dat maakt fetch veiliger en overzichtelijker dan meteen pullen, vooral in teams waar veel tegelijk gebeurt. Je ziet eerst wat er op afstand is veranderd, daarna beslis je pas hoe je verdergaat.

Een praktische volgorde voor dagelijks gebruik

Als je Git simpel wilt houden, is deze volgorde vaak genoeg voor alledaagse taken:

1. Controleer met git status wat er speelt.
2. Bekijk met git diff wat er precies is aangepast.
3. Selecteer met git add alleen de juiste wijzigingen.
4. Leg vast met git commit en schrijf een duidelijke boodschap.
5. Haal updates op met git pull of bekijk eerst met git fetch.
6. Stuur je werk op met git push.

Deze volgorde is niet de enige manier, maar wel een solide basis. Wie deze routine beheerst, kan in de meeste projecten goed uit de voeten. Daarna kun je uitbreiden met branches, reverts en stashes.

Veelgemaakte fouten en hoe je ze voorkomt

Git wordt vaak onnodig ingewikkeld doordat mensen te snel werken of te weinig controleren. Met een paar gewoontes voorkom je veel frustratie.

• Commit niet te groot, houd wijzigingen logisch bij elkaar.
• Gebruik duidelijke commitberichten, niet alleen fix of update.
• Check altijd eerst git status.
• Werk op een branch voor nieuwe functies of experimenten.
• Gebruik git fetch als je eerst wilt kijken wat er op afstand is veranderd.
• Gebruik git revert op gedeelde branches, als je iets veilig wilt terugdraaien.

Een goede Git-werkwijze is vooral een gewoonte. Niet elk commando hoeft dagelijks, maar de basis moet zo vertrouwd zijn dat je er niet meer over hoeft na te denken. Wie die routine opbouwt, werkt rustiger en maakt makkelijker overzichtelijke keuzes.

Wil je je kennis verder verdiepen, dan is het logisch om Git te combineren met bredere kennis over samenwerken, tooling en werkprocessen. Daar sluit ook de rest van Tips en Productiviteit goed op aan.

Welke Git-commando's je als eerste moet leren

Als je nog maar een kleine set wilt onthouden, begin dan hier: git status, git add, git commit, git pull, git push, git diff, git log, git branch, git switch en git merge. Met die tien kun je al verrassend veel dagelijkse situaties oplossen.

De rest komt vanzelf zodra je vaker met echte projecten werkt. Git leer je niet door alle opties uit het hoofd te stampen, maar door een paar kerncommando's vaak en bewust te gebruiken.