Wat is GitHub?

GitHub is een online plek waar programmeurs hun code bewaren, wijzigingen bijhouden en samenwerken. Het is het grootste platform in zijn soort en sinds 2018 eigendom van Microsoft.

Onder de motorkap zit git, het versiebeheersysteem dat het werk doet. Dat onderscheid is nuttig om vast te houden, want git kun je ook zonder GitHub gebruiken.

Git is het versiebeheer, GitHub is de plek

Git is een programma dat je op je eigen computer draait. Het houdt van elke map met bestanden bij wat er wanneer is veranderd en door wie. Linus Torvalds bedacht het in 2005 voor de ontwikkeling van de Linux-kernel, nadat het systeem dat het team daarvoor gebruikte niet langer gratis beschikbaar was.

GitHub is een dienst die daar een website omheen heeft gebouwd: een plek om je repository online te zetten, met knoppen om te bespreken, te beoordelen en samen te werken. Het bedrijf begon in 2008 en is sinds 2018 onderdeel van Microsoft.

Het praktische gevolg: git is de techniek en die verandert nauwelijks. GitHub is een dienst die je afneemt en die verandert wel. Stap je ooit over naar een andere aanbieder, dan neem je je hele geschiedenis gewoon mee, want die zit in git en niet in GitHub.

Wat versiebeheer je oplevert

Dit is het deel dat nuttig is voor iedereen die met bestanden werkt, ook als je zelf nooit een regel code schrijft.

Bij versiebeheer wordt elke wijziging vastgelegd: welke regels er veranderden, wanneer, door wie, en met een korte uitleg waarom. Je kunt op elk moment terug naar een eerdere versie, en je kunt van elke regel opvragen wie hem heeft aangepast en in welke wijziging.

Dat betekent het einde van bestandsnamen als definitief-versie3-echt-definitief. Er is één bestand, met een volledige geschiedenis erachter.

De winst die je pas merkt als het misgaat: je hebt iets aangepast, de site doet raar, en je weet niet meer precies wat je hebt gedaan. Met versiebeheer kijk je naar de laatste wijziging, draai je hem terug, en ben je binnen een minuut weer waar je was. Zonder versiebeheer zit je in een back-up van vannacht te graven en ben je ook je andere werk kwijt.

De begrippen op een rij

• Repository. De map met je project en de hele geschiedenis erin. Meestal repo genoemd.
• Commit. Eén vastgelegde wijziging, met een korte omschrijving erbij. Een moment waar je naar terug kunt.
• Branch. Een aftakking waarin je iets kunt proberen zonder de werkende versie aan te raken.
• Merge. Een aftakking terugbrengen in de hoofdlijn.
• Pull request. Een voorstel om je aftakking op te nemen, zodat iemand anders er eerst naar kan kijken.
• Issue. Een melding bij het project: een fout, een wens, een vraag.
• Fork. Een eigen kopie van andermans project, om zelf mee verder te gaan.
• Clone. Een repository binnenhalen op je eigen computer, met geschiedenis en al.

Let op dat een clone volledig is. Iedereen die je repository heeft binnengehaald heeft de complete geschiedenis, inclusief alles wat je ooit hebt vastgelegd en later hebt weggehaald. Onthoud dat, want verderop wordt het pijnlijk.

Hoe een werkdag met git eruitziet

De kern is een kleine kringloop die je de hele dag herhaalt.

Je haalt binnen wat anderen hebben veranderd. Je past iets aan. Je selecteert welke wijzigingen bij elkaar horen en legt ze vast als één commit met een omschrijving. Daarna stuur je die commits naar GitHub, zodat de rest ze heeft.

Over die omschrijving: schrijf op wat er verandert en waarom, niet dat je iets hebt aangepast. "Bugfix" zegt over een jaar niets. "Contactformulier stuurde geen bevestiging bij lege achternaam" zegt alles. Je schrijft die regel voor jezelf over zes maanden.

Houd commits klein. Eén onderwerp per commit is de regel. Een commit waarin je tegelijk een fout hebt opgelost, de opmaak hebt veranderd en drie bestanden hebt hernoemd, kun je later niet meer los terugdraaien.

Je hoeft hiervoor niet in een zwart scherm te werken. GitHub Desktop, de git-vensters in Visual Studio Code, PhpStorm en Sublime Merge doen precies hetzelfde met knoppen. De begrippen blijven gelijk, dus wat je hier leest geldt ook daar.

Branches en pull requests

Een branch is een aftakking. Je zegt: vanaf hier ga ik iets proberen, en de werkende versie blijft ondertussen gewoon staan.

Dat is de reden dat branches bestaan. Je bouwt een nieuwe pagina in een aftakking, er belt een klant met een spoedfout, je springt terug naar de hoofdlijn, lost die fout op, zet hem live, en gaat daarna verder waar je gebleven was. Zonder aftakking zou je half werk moeten meesturen.

De hoofdlijn heette lange tijd master. GitHub maakte in oktober 2020 main de standaardnaam voor nieuwe repository's. Beide namen kom je nog steeds tegen en technisch verschillen ze niet.

Een pull request is het voorstel om je aftakking terug te brengen in de hoofdlijn. Op GitHub is dat een pagina waar iedereen precies ziet welke regels er veranderen, waar je opmerkingen kunt plaatsen bij een specifieke regel, en waar tests automatisch kunnen meedraaien. Bij een team is dit het moment waarop een tweede paar ogen meekijkt voordat er iets live gaat.

Werk je alleen, dan zijn pull requests vaak overdreven. Aftakkingen zelf zijn dat niet. Ik gebruik ze ook in mijn eentje, juist omdat er altijd iets tussendoor komt.

Wat er misgaat: conflicten en losse kopieën

Het klassieke ongeluk is een conflict. Twee mensen hebben dezelfde regels in hetzelfde bestand veranderd, en git kan niet bepalen welke versie moet blijven. Je krijgt dan een bestand terug waarin beide versies onder elkaar staan met markeringen ertussen. Je kiest, haalt de markeringen weg, en legt het resultaat vast.

Vervelend, geen ramp, en te voorkomen door vaak binnen te halen wat anderen hebben gedaan. Conflicten groeien met de tijd dat je aftakking los blijft staan.

Het echte probleem is een ander. Iemand past iets rechtstreeks op de server aan, buiten git om, omdat het snel moest. Vanaf dat moment klopt je repository niet meer met de werkelijkheid, en de eerstvolgende keer dat je iets uitrolt gooi je die reparatie eruit. Daar is geen technische oplossing voor. Er is alleen de afspraak dat wijzigingen via git gaan.

Git bij een WordPress-thema of plugin

Je zet niet je hele WordPress-installatie in git. Dat is grotendeels code van anderen die je via updates binnenhaalt, en daar heb je geen geschiedenis van nodig.

Wat er meestal wel in gaat: je eigen thema of childthema, je eigen plugins, en eventueel een bestand met je serverinstellingen. Wat er nooit in gaat: de map met geüploade afbeeldingen, en wp-config.php met je databasewachtwoord erin. Die uitsluitingen zet je in een bestand met de naam .gitignore in de hoofdmap van je repository.

De database hoort er ook niet in. Git is gemaakt voor tekstbestanden en gaat slecht om met grote binaire bestanden. GitHub waarschuwt vanaf 50 MB per bestand en weigert bestanden boven de 100 MB. Voor je database gebruik je gewoon een back-up bij je hostingpartij.

Uitrollen kan automatisch. Met GitHub Actions laat je bij elke wijziging in de hoofdlijn je bestanden naar de server kopiëren, eventueel nadat een controle is geslaagd. Dat scheelt handmatig geklungel met FTP en het scheelt vooral de fout waarbij je één bestand vergeet.

Bouw je een plugin die in de map van WordPress.org komt, dan is het aardig om te weten dat WordPress zelf geen git gebruikt voor die map maar Subversion. Er bestaan kant-en-klare Actions die je release vanuit GitHub naar die omgeving doorzetten, zodat jij in git kunt blijven werken. Hoe die verhouding tussen de software en de gehoste dienst zit staat in het artikel over het verschil tussen WordPress.com en WordPress.org.

Wat je nooit in een repository zet

Dit is de meest gemaakte fout en de duurste. Zet nooit wachtwoorden, API-sleutels, tokens of certificaten in een repository, ook niet in een privérepository.

De reden zit in hoe git werkt. Een sleutel die je vastlegt en in een latere commit weghaalt, staat nog steeds in de geschiedenis. Iedereen die de repository ooit heeft binnengehaald heeft die geschiedenis op zijn computer. Weghalen uit het huidige bestand doet dus niets.

De juiste reactie als het toch gebeurt: trek de sleutel in en maak een nieuwe aan. Meteen, voordat je iets anders doet. Pas daarna ga je nadenken over het opschonen van je geschiedenis, wat kan met een programma als git-filter-repo, maar wat je nooit als eerste stap moet zien. Een ingetrokken sleutel is waardeloos voor een aanvaller, een verwijderde sleutel die nog geldig is niet.

Waar sleutels dan wel horen: in omgevingsvariabelen op de server, of in een .env-bestand dat je in .gitignore zet. Voor GitHub Actions gebruik je de ingebouwde secrets, die versleuteld worden opgeslagen en niet in logbestanden verschijnen.

GitHub helpt een handje. Openbare repository's worden gecontroleerd op bekende soorten sleutels, en wordt er een gevonden van bijvoorbeeld een betaaldienst, dan krijgt die leverancier een seintje en trekt hij de sleutel meestal binnen enkele minuten in. Prettig, en geen reden om erop te leunen. Meer over dit soort gewoonten staat in het artikel over het beveiligen van een WordPress-website.

Wat GitHub er verder omheen bouwt

Issues. Een lijst met meldingen en wensen per project, waar je labels en verantwoordelijken aan hangt. Voor een klein project vervangt dit prima een takenlijst.

Actions. Sinds 2019 kun je bij elke wijziging automatisch dingen laten gebeuren: tests draaien, code controleren, uitrollen naar je server. Je beschrijft dat in een bestand in je repository.

Pages. Gratis een statische website publiceren vanuit een repository, met een eigen domein en een certificaat. Handig voor documentatie of een projectsite.

Dependabot. Waarschuwt wanneer een van de bibliotheken die je gebruikt een lek blijkt te hebben, en kan zelf een voorstel maken om te updaten. Voor projecten die op pakketten van anderen leunen, zoals veel Node.js-projecten, is dit het nuttigste onderdeel.

Releases. Een gemarkeerd punt in de geschiedenis met een versienummer en een pakket dat mensen kunnen downloaden. Zo verspreiden de meeste plugins hun versies.

Wat het kost

Gratis voor onbeperkt veel openbare en privérepository's, ook met meerdere mensen. Betaalde pakketten voegen vooral beheer over teams, extra beveiligingscontroles en meer rekentijd voor Actions toe.

Voor een zelfstandige of een klein bedrijf is de gratis versie ruim voldoende. Ik heb nog nooit een klant met vijf man gehad die tegen de grenzen aan liep.

Twee dingen die veranderd zijn en waar mensen tegenaan lopen. Sinds 13 augustus 2021 kun je bij het versturen van code niet meer je gewone wachtwoord gebruiken: je hebt een persoonlijk toegangstoken of een SSH-sleutel nodig. En sinds 2023 is tweestapsverificatie verplicht voor iedereen die op GitHub.com code bijdraagt. Beide zijn goede maatregelen die bij oude handleidingen voor verwarring zorgen.

Licenties: wat je mag hergebruiken

Code die op GitHub staat is niet automatisch vrij te gebruiken. Dat is de misvatting die de meeste schade aanricht.

Staat er geen licentiebestand bij, dan geldt gewoon het auteursrecht en mag je het niet zomaar in je eigen project verwerken. Openbaar zichtbaar is iets anders dan vrij van rechten. Wat de begrippen eromheen betekenen staat in het artikel over open source.

Staat er wel een licentie, lees dan welke. MIT en Apache zijn ruim: je mag vrijwel alles, mits je de vermelding laat staan. GPL vraagt dat wat je ermee bouwt en verspreidt onder dezelfde voorwaarden beschikbaar komt.

Voor WordPress is dat laatste direct van belang. WordPress zelf staat onder de GPL, en thema's en plugins die op WordPress voortbouwen worden daar in de praktijk onder gerekend. Dat verklaart waarom je betaalde plugins mag aanpassen en waarom leveranciers hun geld verdienen aan updates en ondersteuning in plaats van aan de code zelf.

Waar je code staat en wat de AVG ermee te maken heeft

GitHub is een Amerikaans bedrijf. Voor gewone projectcode is dat zelden een bezwaar. Het wordt een vraag zodra er persoonsgegevens in beeld komen.

Dat gebeurt eerder dan je denkt. In issues plakken mensen foutmeldingen met klantgegevens erin. In testbestanden staan echte adressen omdat dat sneller was. En elke commit bevat de naam en het e-mailadres van de maker, wat bij een openbare repository voor iedereen zichtbaar is. GitHub biedt daarvoor een noreply-adres dat je in je instellingen kunt aanzetten, en dat is een kleine moeite.

Ga je klantgegevens in een repository zetten, dan gelden de gewone regels: een grondslag, een verwerkersovereenkomst met je leverancier, en helderheid over waar de gegevens staan. Mijn advies is simpeler: zet er geen persoonsgegevens in. Testdata verzin je maar.

Voor wie software als product levert, is er nog iets aan te komen. De Europese Cyber Resilience Act is op 10 december 2024 in werking getreden en stelt eisen aan producten met digitale elementen. De meldplicht voor actief misbruikte kwetsbaarheden gaat gelden per 11 september 2026, en de rest van de verplichtingen per 11 december 2027. Voor een ondernemer die een website laat bouwen speelt dat niet, voor wie een plugin verkoopt op termijn wel.

Ook nuttig buiten programmeren

Versiebeheer werkt voor alles wat uit tekst bestaat, en dat is meer dan code.

Documentatie, handleidingen, configuratiebestanden en zelfs boeken worden zo bijgehouden. Je ziet per zin wie wat wanneer veranderde, en met welke reden. Ook Nederlandse overheidsorganisaties publiceren broncode en standaarden op deze manier, zodat iedereen wijzigingen kan volgen en erop kan reageren.

Voor een websitebeheerder is de praktische winst dit: je serverinstellingen, je maatwerkcode en je thema-aanpassingen staan ergens veilig, met een geschiedenis erbij. Sloopt een wijziging iets, dan ben je in dertig seconden terug bij de werkende versie.

De alternatieven

GitLab en Bitbucket doen ongeveer hetzelfde. GitLab kun je ook op je eigen server draaien, wat interessant is als je code het pand niet uit mag of als je opdrachtgever daarop staat.

In Europa is Codeberg een aardige optie: een Duitse vereniging zonder winstoogmerk die draait op vrije software, met de servers in Duitsland. Kleiner en rustiger dan GitHub, en genoeg voor de meeste projecten. Wil je alles zelf beheren, dan installeer je Forgejo of Gitea op een eigen server, wat op een lichte machine prima draait.

Het onderliggende git is overal hetzelfde, dus overstappen kost weinig. Wat niet meeverhuist zijn je issues, je pull requests en je Actions, want dat is de laag die per aanbieder verschilt.

Waar ik zou beginnen

Begin klein en met iets van jezelf. Maak één repository voor je childthema of voor je maatwerkplugin, leg de huidige stand vast, en werk een maand zo verder.

Gebruik een programma met knoppen als de opdrachtregel je afschrikt. Het gaat niet om de commando's, het gaat om de gewoonte van vastleggen.

Spreek daarna af dat wijzigingen op de server altijd uit de repository komen en nooit rechtstreeks in een editor bij je hostingpartij. Dat is de afspraak waar alle winst vandaan komt, en de eerste die sneuvelt als het druk wordt. Werk je met een externe bouwer, leg dan vast dat je toegang krijgt tot de repository, want anders zit je maatwerk straks bij iemand anders op de laptop.

Veelgestelde vragen over GitHub

Wat is het verschil tussen git en GitHub?

Git is het versiebeheersysteem dat op je eigen computer draait en de geschiedenis bijhoudt. GitHub is een dienst die je repository online bewaart en er samenwerking omheen bouwt. Je kunt git prima gebruiken zonder GitHub.

Is GitHub gratis?

Ja, voor onbeperkt veel openbare en privérepository's, ook met meerdere mensen. Betaalde pakketten voegen beheer, extra beveiligingscontroles en meer rekentijd toe. Voor een zelfstandige of een klein bedrijf volstaat de gratis versie.

Wat is een commit?

Eén vastgelegde wijziging, met een korte omschrijving erbij en een tijdstip en auteur. Het is een moment waar je later naar terug kunt springen. Houd commits klein en beschrijf wat er verandert en waarom.

Wat is een repository?

De map met je project plus de volledige geschiedenis van alle wijzigingen. Iedereen die hem binnenhaalt krijgt die geschiedenis mee.

Waarvoor gebruik je een branch?

Om iets te bouwen of te proberen zonder de werkende versie aan te raken. Komt er iets tussendoor, dan spring je terug naar de hoofdlijn, lost dat op, en gaat daarna verder in je aftakking.

Wat is een pull request?

Een voorstel om je aftakking op te nemen in de hoofdlijn, waarbij anderen eerst regel voor regel kunnen meekijken en opmerkingen kunnen plaatsen. Bij een team is dit het beoordelingsmoment voor iets live gaat. Werk je alleen, dan is het vaak overbodig.

Kan ik GitHub gebruiken voor mijn WordPress-website?

Ja, en dan voor je eigen thema en je eigen plugins. Je hele WordPress-installatie erin zetten heeft weinig zin, want dat is grotendeels code die je via updates binnenhaalt. Laat de uploadsmap en wp-config.php er altijd buiten.

Wat gebeurt er als ik per ongeluk een wachtwoord in een repository zet?

Trek de sleutel of het wachtwoord onmiddellijk in en maak een nieuwe aan. Dat is de enige stap die echt helpt. Verwijderen uit het bestand lost niets op, want de waarde blijft in de geschiedenis staan en op de computer van iedereen die de repository heeft binnengehaald.

Is een privérepository veilig genoeg voor gevoelige gegevens?

Voor code van jezelf die niemand hoeft te zien is een privérepository prima. Voor wachtwoorden, sleutels en persoonsgegevens niet. Die horen in omgevingsvariabelen of een wachtwoordkluis, ongeacht of de repository openbaar is.

Mag ik code van GitHub in mijn eigen project gebruiken?

Alleen als de licentie dat toestaat. Staat er geen licentiebestand bij, dan geldt het gewone auteursrecht en mag het niet. MIT en Apache zijn ruim, GPL vraagt dat je eigen werk onder dezelfde voorwaarden beschikbaar komt als je het verspreidt.

Wat is een fork?

Een eigen kopie van andermans repository, waarin je zelf verder kunt werken. Je gebruikt het om een verbetering voor te stellen aan het oorspronkelijke project, of om een project over te nemen dat door de maker is losgelaten.

Heb ik de opdrachtregel nodig om git te gebruiken?

Nee. GitHub Desktop, Visual Studio Code, PhpStorm en Sublime Merge doen hetzelfde met knoppen. De begrippen blijven gelijk. Wie er dagelijks mee werkt gaat vanzelf een deel op de opdrachtregel doen omdat het sneller is.

Wat zijn GitHub Actions?

Taken die automatisch draaien bij een gebeurtenis in je repository, bijvoorbeeld bij elke wijziging in de hoofdlijn. Denk aan tests draaien, code controleren of bestanden naar je server kopiëren. Je beschrijft ze in een bestand dat je meelevert, zodat de afspraak zichtbaar is voor iedereen.

Waarom heet de hoofdlijn soms master en soms main?

GitHub maakte main in oktober 2020 de standaardnaam voor nieuwe repository's. Oudere projecten gebruiken vaak nog master. Technisch is er geen verschil, het is alleen een naam.

Kan ik GitHub gebruiken voor iets anders dan code?

Ja, voor alles wat uit tekstbestanden bestaat. Documentatie, handleidingen, standaarden en configuratiebestanden worden er veel op bijgehouden. Voor afbeeldingen, video en databases is git minder geschikt, want die groeien slecht mee in de geschiedenis.

Wat is het alternatief als mijn code niet in de Verenigde Staten mag staan?

GitLab kun je op je eigen server draaien, en Forgejo of Gitea zijn lichte varianten die op een kleine machine passen. Codeberg is een Duitse vereniging zonder winstoogmerk met servers in Duitsland. Het onderliggende git is overal hetzelfde, dus je geschiedenis verhuist zonder verlies mee.