Wat is GitHub? Uitleg voor ondernemers zonder technische kennis

In het kort: GitHub is de online bewaarplaats en werkplek voor de broncode van software en websites. Elke wijziging wordt bijgehouden: wie, wanneer en waarom. Voor jou als ondernemer is dat vooral een eigendomskwestie: staat de code van je website in een repository van jouw eigen organisatie, dan kun je altijd van leverancier wisselen. Staat hij op de laptop van je bouwer, dan niet. Een gratis account biedt onbeperkt privéprojecten en onbeperkt medewerkers.

Samenvatting in het kort

• Git is het gratis programma dat elke wijziging in een bestand bijhoudt. GitHub is de online dienst waar die geschiedenis bewaard wordt en waar mensen samenwerken. GitHub is eigendom van Microsoft.
• Een repository (repo) is de projectmap met alle bestanden plus de volledige geschiedenis. Een commit is een opgeslagen momentopname met uitleg erbij.
• De belangrijkste vraag is niet “moet ik GitHub gebruiken?” maar “waar staat de code van mijn bedrijf en op wiens naam?”
• GitHub Free kost 0 dollar en geeft onbeperkt privérepositories, onbeperkt medewerkers per repository en 2.000 Actions-minuten per maand.
• Team kost 4 dollar per gebruiker per maand (eerste 12 maanden), Enterprise 21 dollar per gebruiker per maand (eerste 12 maanden).
• Heb je alleen een WordPress-site die een bureau beheert? Dan hoef je GitHub niet zelf te gebruiken, maar je zou wel moeten vragen waar je code staat.
• In een repository horen geen klantgegevens. Wachtwoorden, API-sleutels en databasegegevens per ongeluk publiceren is de klassieke, dure fout.
• Dropbox bewaart bestanden. GitHub bewaart de reden waarom een bestand veranderde, en laat je terug naar elke eerdere versie.

Wat is GitHub in eenvoudige woorden?

GitHub is een online plek waar de bouwtekeningen van software worden bewaard, met een volledig logboek van elke aanpassing. Vergelijk het met een archief van je boekhouding: je ziet niet alleen de laatste versie, maar elke boeking, wie hem deed en waarom.

Voor het idee: stel dat je jaarrekening één Word-bestand was waar drie mensen tegelijk in typen, zonder versiebeheer. Chaos. Software werkt precies zo, maar met duizenden bestanden. Git en GitHub zijn de oplossing voor die chaos.

Vier woorden die je zult horen, in gewone taal:

Belangrijk onderscheid: Git is het gratis programma dat op een computer draait en wijzigingen bijhoudt. GitHub is de online dienst (van Microsoft) waar die geschiedenis staat en waar mensen samenwerken. Je kunt Git gebruiken zonder GitHub. In de praktijk kiezen bijna alle bouwers voor de combinatie.

Het is geen bestandsopslag met een programmeurslaagje eromtop. Het is een logboek waarin de reden van elke wijziging vastligt.

Wat is GitHub voor beginners: hoe ziet het er in de praktijk uit?

Voor een beginner ziet GitHub uit als een website met mappen, een lijst met wijzigingen en een discussiepaneel. Je hoeft niets te programmeren om mee te kijken.

Een concreet dagverloop bij een klein webbureau:

1. Een freelancer maakt een branch aan met de naam nieuwe-contactpagina.
2. Hij wijzigt drie bestanden en maakt een commit: “contactformulier met bedrijfsnaamveld”.
3. Hij opent een pull request. Een collega leest mee en zet een opmerking bij regel 40.
4. Na goedkeuring wordt het samengevoegd met de hoofdversie. De site wordt bijgewerkt.
5. Alles staat vast: datum, persoon, reden, en de mogelijkheid om het terug te draaien.

Wat je als eigenaar zelf kunt doen zonder één regel code te schrijven:

• De lijst met wijzigingen lezen (de tab “Commits”)
• Zien wie toegang heeft (de tab “Settings”, onderdeel “Collaborators”)
• Een taak of bug melden via Issues (dat is een simpel ticketsysteem)
• Een bestand met tekst, zoals een privacyverklaring, direct in de browser aanpassen

Veelgemaakte fout van beginners: denken dat je de code moet begrijpen om nut te hebben van het account. Onjuist. De waarde voor jou zit in eigendom en overzicht, niet in de inhoud van de bestanden.

Welk probleem lost GitHub eigenlijk op?

GitHub lost vier problemen op: verlies van eerdere versies, onduidelijkheid over wie wat wanneer wijzigde, mensen die elkaars werk overschrijven, en afhankelijkheid van één persoon die alles op zijn eigen computer bewaart.

Het vierde probleem is het duurste. Het scenario dat je in Nederland en België regelmatig ziet, ter illustratie: een bouwbedrijf laat een maatwerk-planningstool bouwen door een zelfstandige ontwikkelaar. Na een discussie over een factuur stopt de samenwerking. De code staat op zijn privélaptop en op zijn persoonlijke hostingaccount. Het bedrijf heeft een werkende website, maar geen bouwtekening. Een nieuwe bouwer moet praktisch opnieuw beginnen: werk en een factuur die niemand had begroot.

Dat is geen technisch probleem. Dat is een leveranciersrisico, net als een boekhouder die je grootboek niet wil overdragen.

Beslisregel: laat je iets op maat bouwen (een tool, een webshopkoppeling, een app, een thema van nul), dan hoort de code in een repository op naam van jouw bedrijf. Is je site standaardwerk met een gekocht thema en kant-en-klare plug-ins, dan is het risico veel kleiner.

Waar staat de code van jouw bedrijf, en waarom doet dat ertoe?

De code van je website of app is bedrijfseigendom, net als je klantenbestand en je merknaam. Waar die code staat en op wiens naam bepaalt of je vrij van leverancier kunt wisselen.

Hieronder de vier situaties die we in de praktijk tegenkomen bij kmo’s en zelfstandigen:

De cruciale nuance zit in dat laatste woord: jouw organisatie. Een repository op het persoonlijke account van je bouwer is qua eigendom nauwelijks beter dan zijn laptop. Een GitHub-organisatie is een bedrijfsaccount waar jij (of je bedrijf) de eigenaarsrol hebt en waar je medewerkers en leveranciers uitnodigt als gast.

Drie vragen die je vandaag aan je bouwer kunt stellen:

1. In welke repository staat de code van mijn site, en op welk account?
2. Kan die repository op naam van mijn bedrijf komen, met mij als eigenaar?
3. Wat gebeurt er met mijn website als jij morgen stopt?

Krijg je op vraag 3 een vaag antwoord, dan weet je genoeg.

Heb ik GitHub nodig voor mijn bedrijf, of niet?

Kort antwoord: de meeste ondernemers hoeven GitHub niet zelf te gebruiken, maar wel eigenaar te zijn van de repository waarin hun code staat. Zelf inloggen en werken is iets heel anders dan eigenaarschap regelen.

Wanneer je het waarschijnlijk niet nodig hebt:

• Je hebt een WordPress-site met een gekocht thema en plug-ins, beheerd door een bureau
• Je site is gebouwd in Wix, Squarespace, Shopify of een vergelijkbaar platform
• Er wordt niets op maat gebouwd; alle aanpassingen gaan via het beheerpaneel

Een voorbeeld: een loopbaancoach in Gent met een WordPress-site van vijf pagina’s, een contactformulier en een boekingsplug-in. Zij heeft geen enkele reden om een GitHub-account te openen. Haar tijd is beter besteed aan haar teksten. Wat ze wél doet: één keer per jaar vragen waar haar back-ups staan en of haar domeinnaam en hosting op haar eigen naam staan.

Wanneer je het waarschijnlijk wel nodig hebt (of minstens eigenaar moet zijn):

• Er wordt maatwerk gebouwd: een tool, een portaal, een app, een koppeling met je ERP
• Meerdere mensen of leveranciers werken aan hetzelfde project
• Je bouwt iets waarvan je bedrijf afhankelijk is qua omzet
• Er komt AI-automatisering bij kijken met eigen scripts of koppelingen
• Je verwacht dat je ooit van leverancier wisselt

Tweede voorbeeld: een marketingbureau in Utrecht met drie vaste freelancers voor klantensites. Voordat ze GitHub gebruikten, mailden ze bestanden en overschreven ze regelmatig elkaars werk. Na de overstap ging elke wijziging via een pull request. De winst zat niet in de techniek maar in het einde van de discussie “wie heeft dit veranderd?”.

Kunnen mensen zonder technische kennis GitHub gebruiken, of is het alleen voor programmeurs?

GitHub is niet alleen voor programmeurs, maar het is wel voor programmeurs gemaakt. Een niet-technische ondernemer kan de rol van eigenaar en meelezer prima aan; zelf code aanpassen is een ander verhaal.

Wat realistisch haalbaar is zonder technische kennis:

• Wel: een organisatie aanmaken, mensen toegang geven en afnemen, twee-stapsverificatie instellen, wijzigingen lezen, taken melden via Issues, een tekstbestand aanpassen in de browser
• Deels: begrijpen wat een pull request voorstelt (de omschrijving lezen kan iedereen; de code beoordelen niet)
• Niet: de code zelf beoordelen, conflicten oplossen, automatische publicatie instellen

De interface is Engels en de documentatie is grotendeels Engels. Dat is een echt nadeel voor wie liever alles in het Nederlands doet. Er bestaat geen volwaardige Nederlandse versie van GitHub.

Edge case: GitHub wordt ook gebruikt voor documenten, niet alleen code. Sommige organisaties beheren beleidsteksten of handleidingen in een repository, omdat de geschiedenis waterdicht is. Voor een kmo is dat meestal overkill, een gewone documentbeheeroplossing is dan handiger.

Wat kan GitHub dat Dropbox of Google Drive niet kan?

Dropbox en Google Drive bewaren bestanden. GitHub bewaart de redenering achter elke wijziging en maakt het veilig om met meerdere mensen tegelijk aan hetzelfde project te werken zonder elkaars werk te overschrijven.

De vijf echte verschillen:

1. Reden bij elke wijziging. Elke commit heeft een omschrijving. Bij Dropbox zie je “gewijzigd op 14:32”, niet waarom.
2. Wijzigingen per regel. GitHub laat exact zien welke regels zijn toegevoegd en verwijderd. Handig als één komma je webshop plat legt.
3. Parallel werken. Met branches kunnen drie mensen tegelijk aan verschillende onderdelen werken en pas samenvoegen als het klaar is.
4. Nakijken vóór het live gaat. Een pull request is een ingebouwde vier-ogen-controle.
5. Automatisch publiceren. GitHub kan bij elke goedgekeurde wijziging automatisch tests uitvoeren en de site bijwerken.

Andersom: voor je facturen, contracten, foto’s en presentaties is Dropbox of Drive gewoon beter. GitHub is niet bedoeld voor grote bestanden en is geen documentarchief.

Beslisregel: gaat het om bestanden die mensen openen en lezen, kies Drive of Dropbox. Gaat het om bestanden waaruit iets gebouwd of uitgevoerd wordt, kies GitHub.

Hoeveel kost GitHub en welk pakket heb je nodig?

GitHub Free kost 0 dollar en is voor de meeste kmo’s genoeg. Team kost 4 dollar per gebruiker per maand voor de eerste 12 maanden, Enterprise 21 dollar per gebruiker per maand voor de eerste 12 maanden. Alle prijzen zijn in dollars, gecontroleerd op github.com op 3 augustus 2026.

Bij openbare repositories zijn de standaard Actions-minuten en GitHub Pages gratis. GitHub Pages is gratis hosting voor eenvoudige, statische sites, geen webshop, geen inlogsysteem, maar prima voor een landingspagina of documentatie.

Over die Actions-minuten: “Actions” zijn automatische taken die draaien zodra er iets aan de code verandert, bijvoorbeeld automatisch testen of automatisch publiceren. Ben je door je gratis minuten heen, dan wordt het gebruik geblokkeerd als er geen geldig betaalmiddel is. Met een betaalmiddel reken je per minuut af:

• Linux: 0,006 dollar per minuut
• Windows: 0,010 dollar per minuut
• macOS: 0,062 dollar per minuut

Dat verschil is groot. Een team dat per ongeluk zware taken op macOS laat draaien, kan een tienvoudige rekening krijgen voor exact hetzelfde werk.

Beslisregel: begin met Free. Stap over naar Team zodra je verplichte controle vóór publicatie wilt (branchbeveiliging en verplichte reviewers), meestal als er drie of meer mensen aan hetzelfde project werken. Enterprise is voor organisaties met strenge eisen rond toegangsbeheer en auditing, niet voor een kmo van tien mensen.

Wat is GitHub vergeleken met GitLab, Bitbucket en andere alternatieven?

GitHub is de grootste en meest gebruikte dienst voor het bewaren van broncode, maar niet de enige. GitLab, Bitbucket en Azure DevOps doen in de kern hetzelfde: ze bewaren repositories en de bijhorende geschiedenis.

Praktische verschillen die voor een kmo tellen:

• GitLab biedt een variant die je op je eigen server (of een Europese server) kunt zetten. Interessant als je om compliance-redenen wilt dat alles binnen de EU blijft.
• Bitbucket (van Atlassian) is aantrekkelijk als je team al Jira en Confluence gebruikt.
• Azure DevOps (Microsoft) past bij organisaties die diep in het Microsoft-ecosysteem zitten. Merk op: Microsoft is ook eigenaar van GitHub.
• GitHub heeft het grootste aanbod aan bouwers die het al kennen. Dat maakt vervangen van je leverancier eenvoudiger.

Beslisregel: laat je bouwer kiezen, maar stel één harde eis, de repository staat op een organisatieaccount van jouw bedrijf, ongeacht het platform. Het platform is uitwisselbaar; eigendom niet. Overzetten van GitHub naar GitLab of omgekeerd is voor een ervaren bouwer een klus van uren, niet weken, omdat Git eronder hetzelfde blijft.

Veelgemaakte fout: platformen vergelijken op functielijstjes terwijl niemand nadenkt over wie de eigenaarsrol heeft. Dat is het equivalent van een kluis kiezen zonder te weten wie de sleutel houdt.

Hoe begin je met GitHub, stap voor stap?

Voor een ondernemer bestaat starten met GitHub uit vijf stappen die samen ongeveer een halfuur duren. Je hoeft niets te programmeren.

1. Maak een account aan op github.com met een e-mailadres van je bedrijf, niet je privémail. Kies Free.
2. Zet twee-stapsverificatie aan. GitHub verplicht dit voor accounts die code bijdragen. Doe het meteen goed en bewaar de herstelcodes veilig.
3. Maak een organisatie aan met de naam van je bedrijf. Dit is de stap die de meeste mensen overslaan en die het verschil maakt tussen eigenaarschap en afhankelijkheid.
4. Nodig je bouwer of freelancer uit als lid, niet als eigenaar. Jij houdt de eigenaarsrol. Bij vertrek verwijder je zijn toegang in twee klikken.
5. Vraag om de eerste repository in die organisatie, met een leesbaar README-bestand waarin staat wat het project is, hoe het gepubliceerd wordt en waar de wachtwoorden veilig bewaard zijn (níet in de repository zelf).

Checklist voor de overdracht van een bestaand project:

• De repository staat onder mijn organisatie, niet onder een persoonlijk account
• Ik heb de eigenaarsrol
• Ten minste twee mensen in mijn bedrijf hebben toegang (niet één sleutelhouder)
• Alle externe leveranciers staan als lid, met een einddatum in mijn agenda
• De repository is privé, tenzij er een goede reden is voor openbaar
• Er staan geen wachtwoorden, API-sleutels of databasegegevens in de bestanden

Wil je begrijpen hoe tools onderling verschillen voordat je kiest, gebruik dan onze vergelijker voor AI-tools en doe de gratis AI-scan om te zien welke processen bij jou de meeste tijd kosten.

Welke fouten maken ondernemers met GitHub, en wat betekent de AVG?

De duurste fout is per ongeluk wachtwoorden of API-sleutels publiceren in een openbare repository. De tweede is denken dat je iets geregeld hebt terwijl de repository op het persoonlijke account van je bouwer staat.

De vijf fouten die we het vaakst zien:

1. Geheimen in de code. Wachtwoorden, API-sleutels, databasegegevens en toegangstokens horen niet in een repository. Belangrijk: verwijderen is niet genoeg. Zodra iets in de geschiedenis staat, staat het er nog. De sleutel moet worden ingetrokken en vervangen.
2. Repository per ongeluk openbaar. Een verkeerd vinkje bij het aanmaken en je maatwerkcode staat voor iedereen leesbaar online.
3. Repository op een persoonlijk account. Geen organisatie = geen eigendom.
4. Eén sleutelhouder. Als alleen je bouwer eigenaar is en hij onbereikbaar wordt, sta je stil.
5. Actions-minuten uit de hand. Zware automatische taken op macOS (0,062 dollar per minuut) lopen snel op als niemand meekijkt.

Over privacy en AVG. In een repository horen normaal geen persoonsgegevens, alleen code en configuratie. Zolang dat zo blijft, is de AVG-vraag beperkt. Maar let op twee dingen:

• Databasedumps, exportbestanden of testgegevens met echte klantnamen in een repository zetten is een verwerking van persoonsgegevens. Dat is precies wat je niet wil.
• GitHub kan gegevens ook buiten de EU verwerken. Komen er wél persoonsgegevens in beeld, dan heb je een verwerkersovereenkomst nodig en moet je de doorgifte buiten de EU in je register vastleggen. Microsoft biedt hiervoor voorwaarden aan; laat die door je DPO of jurist beoordelen in plaats van er van uit te gaan dat het geregeld is.

De officiële voorwaarden en tarieven staan op github.com/pricing en in de GitHub-documentatie over facturatie van Actions.

Wanneer moet jouw bedrijf GitHub gaan gebruiken?

Het moment om zelf een GitHub-organisatie te openen is zodra iemand voor jouw bedrijf iets op maat bouwt waarvan je omzet of dienstverlening afhankelijk is. Wacht niet tot er een conflict is.

Drie duidelijke signalen:

• Je vraagt een maatwerkontwikkeling aan waarvan het bedrag serieus meetelt in je jaarbudget
• Er werken twee of meer mensen aan hetzelfde digitale product
• Je automatiseert processen met eigen scripts of koppelingen tussen systemen

En drie signalen dat je nog even kunt wachten:

• Alles loopt via standaardplatformen en plug-ins
• Er is één bouwer die alleen inhoudelijke aanpassingen doet in een beheerpaneel
• Je hebt geen enkel maatwerkonderdeel

Voor- en nadelen op een rij:

Voordelen: je bedrijf blijft eigenaar van zijn code, je kunt van leverancier wisselen, je hebt een volledig logboek van wijzigingen, samenwerken zonder overschrijven, en het gratis pakket is voor de meeste kmo’s ruim voldoende.

Nadelen: de interface en documentatie zijn Engels, er is een echte leercurve voor wie zelf wil meewerken, gegevens kunnen buiten de EU worden verwerkt, en het is volledig overkill als je alleen een standaardwebsite hebt.

Conclusie: wat doe je hier morgen mee?

Wat is GitHub voor jou als ondernemer? Niet zozeer een tool die je zelf moet leren, maar een antwoord op de vraag wie de bouwtekeningen van je digitale bezit in handen heeft. Je hoeft geen regel code te begrijpen om die vraag te stellen.

Drie concrete stappen, in deze volgorde:

1. Stuur vandaag één e-mail naar je webbouwer of bureau: “Waar staat de broncode van onze site of applicatie, op welk account, en kan die op naam van ons bedrijf komen?”
2. Heb je maatwerk? Maak een gratis GitHub-organisatie aan op de naam van je bedrijf, zet twee-stapsverificatie aan en nodig je bouwer uit als lid, niet als eigenaar.
3. Heb je alleen een standaardwebsite? Doe niets met GitHub. Controleer in plaats daarvan of je domeinnaam, hosting en back-ups op je eigen naam staan. Dat levert je meer op.

Verder lezen op AI voor Bedrijven: wat is Vercel legt uit waar die code vervolgens gehost wordt, wat is Supabase behandelt de database eronder, en Claude Code skills laat zien hoe AI je bij zulk werk kan helpen. Wil je zien welke taken in jouw bedrijf zich lenen voor automatisering, doe dan de gratis AI-scan of blader door de toolcatalogus.

Bronnen

• GitHub Pricing, geraadpleegd 3 augustus 2026
• GitHub Docs: About billing for GitHub Actions, geraadpleegd 3 augustus 2026
• GitHub Pages documentatie, geraadpleegd 3 augustus 2026