Git en GitHub voor mensen die geen developer zijn

Waarom heb je dit nodig als een AI voor je bouwt?

Omdat een AI die code schrijft veel tegelijk verandert, en jij alleen ziet wat het scherm doet. Zonder versiebeheer weet je na een wijziging dat het anders werkt, maar niet wat er anders is, en als het na drie wijzigingen misgaat, weet je niet welke van de drie het deed. Met versiebeheer heeft elke wijziging een voor en een na, en kun je die naast elkaar zien: deze regels zijn erbij gekomen, deze zijn weg.

Het is ook de basis van eigendom. Een project dat alleen in je bouwtool bestaat, bestaat alleen zolang de tool en je abonnement bestaan. Een project in een repository die van jou is, kun je meenemen naar elke andere tool en elke host. Dat is de eerste stap over de klif, en de meeste bouwtools hebben er een knop voor.

En het is de manier om te leren zonder te programmeren. Wie na elke wijziging het overzicht van wat er veranderde bekijkt, en de AI vraagt het in gewone taal uit te leggen, begrijpt na een maand meer van zijn project dan hij dacht te kunnen. Het artikel over vibe coding noemt dat het tweede spoor.

• Zien wat de AI veranderde, niet alleen dat het anders werkt.
• Terug kunnen naar een versie die werkte.
• Eigendom: een project dat je overal mee naartoe kunt nemen.

Wat is een repository?

Een map met alles wat bij je project hoort, plus de complete geschiedenis van die map. GitHub omschrijft het als een map die verwante dingen bevat, zoals bestanden, afbeeldingen en andere mappen, en die meestal alles van één project groepeert. Het verschil met een gewone map is de geschiedenis: een repository onthoudt elke versie van elk bestand, en wie wat wanneer veranderde en waarom.

Een repository staat op twee plekken: lokaal, op je eigen computer, en op afstand, bij een dienst als GitHub. De twee houd je gelijk door wijzigingen te versturen (push) en op te halen (pull). Voor wie met een bouwtool werkt, doet de tool dat meestal: hij schrijft naar de repository op GitHub, en jij kunt hem daar bekijken of naar je eigen computer halen.

Maak de repository zelf aan, op je eigen GitHub-account, en koppel de tool eraan. Dan is de repository van jou. Andersom, een repository die de tool voor je aanmaakt onder haar eigen account, is van de tool. Dat verschil merk je pas als je weg wilt.

• Een map met je hele project en zijn hele geschiedenis.
• Lokaal en op afstand, gelijk gehouden met push en pull.
• Op jouw account aanmaken, dan koppelen; niet andersom.

Wat is een commit?

Een opgeslagen moment. GitHub definieert het als een bewaarde wijziging aan bestanden in een repository, met een boodschap erbij die uitlegt wat er is veranderd en waarom. Een commit is dus geen bestand maar een foto van het hele project op één moment, met een onderschrift. De reeks commits is de geschiedenis van je project, en elke commit kun je later terughalen.

De boodschap is het belangrijkste deel voor een niet-programmeur. Een commit met de boodschap “aanmeldformulier toegevoegd, met controle op het e-mailadres” is over drie maanden nog te begrijpen; een commit met “fix” is dat niet. Laat je AI de boodschap schrijven in gewone taal, en lees hem voordat je akkoord geeft. Als je de boodschap niet begrijpt, begrijp je de wijziging niet, en dat is het moment om te vragen.

Maak commits klein. Eén verandering, één commit. Dan is de geschiedenis leesbaar en kun je één stap terug zonder alles te verliezen. Bouwtools maken vaak per opdracht een commit, en dat is een goede maat.

• Een foto van het hele project op één moment, met een onderschrift.
• De boodschap in gewone taal, en lezen voordat je akkoord geeft.
• Klein: één verandering per commit.

Wat is een branch?

Een aparte versie van je repository waarin je kunt werken zonder de hoofdversie te raken. GitHub legt uit dat de standaardbranch main heet, en dat je extra branches maakt om te experimenteren zonder de hoofdcode te beïnvloeden. Op een branch maak je commits zoals altijd; pas als je tevreden bent, breng je ze terug naar de hoofdlijn.

Voor wie met een AI bouwt is een branch de veilige plek voor een grote verandering. Laat de AI een nieuw onderdeel bouwen op een eigen branch, bekijk het resultaat, en beslis dan of het naar de hoofdlijn mag. Gaat het mis, dan gooi je de branch weg en is de hoofdlijn onaangeroerd. Dat is goedkoper dan een wijziging terugdraaien die al in de hoofdlijn zat.

De hoofdlijn is wat live staat, of wat live kan. Houd die regel aan: op main staat alleen wat werkt. Alles wat je nog niet vertrouwt, staat op een branch.

• Een aparte versie om in te werken zonder de hoofdlijn te raken.
• Grote veranderingen door de AI: op een eigen branch, eerst kijken, dan beslissen.
• Op main staat alleen wat werkt.

Wat zijn een pull request en een merge?

Een pull request is een voorstel om de wijzigingen van een branch in een andere branch op te nemen, meestal in de hoofdlijn. GitHub omschrijft het als een voorstelmechanisme dat de verschillen tussen de twee branches toont en dat anderen laat bekijken, becommentariëren en verbeteren voordat de wijziging wordt overgenomen. Een merge is het overnemen zelf: de wijzigingen van de ene branch worden in de andere gevoegd.

Ook als je alleen werkt, is een pull request nuttig, juist met een AI. Het is het moment waarop je alle wijzigingen van een branch bij elkaar ziet, regel voor regel, met de mogelijkheid om de AI te vragen wat een stuk doet voordat het in de hoofdlijn komt. Veel bouwtools en agents kunnen zelf een pull request openen; jij hoeft alleen te lezen en op de knop te drukken, of niet.

Na de merge kan de branch weg; de commits zitten nu in de hoofdlijn en de geschiedenis is compleet. Dat is de kringloop: branch, commits, pull request, merge, en de hoofdlijn is een stap verder zonder dat hij ooit onderweg kapot was.

• Pull request: het voorstel, met alle verschillen zichtbaar.
• Merge: het overnemen in de hoofdlijn.
• Ook alleen: het moment om te lezen voordat het live kan.

Wat is het verschil tussen Git en GitHub?

Git is het programma dat de geschiedenis bijhoudt; het draait op je eigen computer en heeft geen internet nodig. GitHub is een dienst van een bedrijf die repositories bewaart op internet, met een website eromheen voor pull requests, opmerkingen en samenwerking. Je kunt Git gebruiken zonder GitHub; je kunt GitHub niet gebruiken zonder Git, ook al zie je Git daar nooit rechtstreeks.

Er zijn ook andere diensten die hetzelfde doen als GitHub, met andere namen. Het principe is gelijk: een plek op afstand waar je repository staat, op jouw account, met de mogelijkheid om anderen toegang te geven. Kies er een, maak een account met een wachtwoord uit je wachtwoordbeheerder en de tweede stap aan, en zet je repository er neer.

Wat je op GitHub zet, is zichtbaar voor wie je toegang geeft, en bij een openbare repository voor iedereen. Zet dus nooit sleutels of wachtwoorden in een repository, ook niet in een privé-exemplaar; de veiligheidschecklist heeft er een controle voor. Versiebeheer vergeet niets, en dat is zijn kracht en zijn risico.

• Git: het programma op je computer. GitHub: de dienst op internet.
• Andere diensten doen hetzelfde; kies er een en zet de tweede stap aan.
• Nooit sleutels in een repository; versiebeheer vergeet niets.

Welke drie gewoontes zijn genoeg?

De eerste: na elke opdracht aan de AI, lees het overzicht van wat er veranderde. Niet de code zelf als je die niet kunt lezen, maar de lijst van bestanden en de boodschap, en vraag de AI om in drie zinnen uit te leggen wat er gebeurde. Klopt de uitleg niet met wat je vroeg, dan is er iets veranderd wat je niet wilde.

De tweede: grote dingen op een branch. Een nieuw onderdeel, een verandering aan de database, een andere manier van inloggen: eerst op een branch, bekijken, dan een pull request en pas dan de merge. Kleine dingen mogen direct, zolang de hoofdlijn blijft werken.

De derde: haal je repository een keer per maand naar je eigen computer en controleer dat hij compleet is en start. Dat is je back-up van de code, en het is de test dat je zonder de tool kunt. Wie deze drie gewoontes heeft, is geen developer geworden, maar hij heeft wel de controle die een developer heeft over wat er in zijn project gebeurt.

• Na elke opdracht: het overzicht lezen en de uitleg vragen.
• Grote dingen op een branch, met een pull request.
• Maandelijks ophalen en controleren dat het start.

Bronnen

Nagelopen op 5 september 2026. De definities van repository, branch, commit, pull request en merge komen uit de Hello World-handleiding van GitHub; de gewoontes zijn werkwijze.

• GitHub Docs, Hello World

Verder lezen

Drie plekken die hierop aansluiten.