Wat is GitHub? Versiebeheer voor niet-ontwikkelaars

GitHub is een website die de code van softwareprojecten opslaat, samen met de volledige geschiedenis, zodat je elke wijziging kunt zien, fouten ongedaan kunt maken en met anderen aan hetzelfde project kunt werken. Het is gebouwd op Git, gratis software die snapshots van de bestanden van een project door de tijd heen vastlegt. Git is het hulpmiddel dat de geschiedenis bijhoudt; GitHub is de online plek waar die geschiedenis wordt gedeeld, geback-upt en besproken.

Als je met AI bouwt, gaat GitHub vooral over twee dingen: een eigen kopie van je code bezitten buiten de tool waarin je die hebt gebouwd, en de code aan een ontwikkelaar overdragen in het formaat dat die al gebruikt.

Waarom het ertoe doet als je met AI bouwt

Een AI-appbouwer schrijft en wijzigt snel veel code, en niet elke wijziging is een verbetering. Versiebeheer helpt je dat veilig te houden.

• Met vertrouwen ongedaan maken. Elke opgeslagen wijziging is een snapshot. Als de AI iets kapotmaakt, ga je terug naar de laatste goede versie.
• Eigendom. Code in je eigen GitHub-account blijft van jou als je van tool wisselt, stopt met betalen voor een tool of een second opinion wilt.
• Samenwerken met ontwikkelaars. Bijna elke ontwikkelaar gebruikt Git dagelijks. Een repository laat hen bekijken wat de AI heeft geschreven, het repareren en wijzigingen terugsturen.
• Elders deployen. Veel hostingplatforms kunnen rechtstreeks vanuit een GitHub-repository deployen.

Een dagelijkse vergelijking: wijzigingen bijhouden plus een gedeelde schijf

Denk aan een document met wijzigingen bijhouden ingeschakeld, opgeslagen op een gedeelde schijf.

• Git is het bijhouden van wijzigingen: elke bewerking wordt vastgelegd, met wie die deed, wanneer en waarom, en je kunt terug naar elke versie.
• GitHub is de gedeelde schijf: het document staat online, anderen kunnen een kopie krijgen en er is een plek om te reageren en goed te keuren.
• Een branch is als een kopie opslaan met de naam „concept — nieuwe prijssectie”, zodat je kunt experimenteren zonder de versie aan te raken waar iedereen op vertrouwt. Als het experiment werkt, voeg je het weer samen met de hoofdversie.

Het verschil met een document zit in de schaal. Een app bestaat uit honderden bestanden, en Git houdt ze allemaal samen bij, dus een snapshot is de toestand van het hele project tegelijk.

Git- en GitHub-termen die je tegenkomt

Twee punten zijn het onderstrepen waard. Ten eerste is Git-geschiedenis van ontwerp permanent: als een wachtwoord is gecommit en gepusht, haalt het verwijderen ervan in een latere commit het niet uit de geschiedenis. Ten tweede is een commit maar zo nuttig als het bericht erbij. „Fix dubbele boeking als twee mensen tegelijk boeken” helpt je later; „update” niet.

Een uitgewerkt voorbeeld: een met AI gebouwde app overdragen aan een freelancer

Je hebt met een AI-appbouwer een klantenportaal gebouwd. Het werkt, maar je wilt dat een freelance ontwikkelaar een lastige koppeling met je boekhoudsoftware toevoegt.

1. Koppel het project aan een nieuwe privé-GitHub-repository en push. De repo bevat nu de code en de geschiedenis.
2. Controleer wat erin staat. Open de repo op GitHub. Er zou geen .env-bestand moeten zijn en geen API-sleutels in de code. Geheimen blijven in de instellingen van je platform en worden apart, indien nodig, met de freelancer gedeeld — zie omgevingsvariabelen en geheimen.
3. Nodig de freelancer uit als medewerker, alleen voor die repository.
4. Die werkt op een branch, bijvoorbeeld boekhoud-sync, commit onderweg en opent een pull request als hij klaar is.
5. Jij beoordeelt de pull request. Ook zonder code te lezen kun je de beschrijving lezen, zien welke bestanden zijn veranderd en vragen stellen in de reacties.
6. Voeg samen als je tevreden bent, en pull daarna de wijzigingen terug in je appbouwer, zodat jij en de AI verder werken vanaf de nieuwe versie.

Onderweg zie je precies wat er is veranderd en kun je dat zo nodig ongedaan maken. Dat is in één werkstroom de hele waarde van versiebeheer. Als je nog overweegt of je überhaupt een ontwikkelaar inschakelt, lees dan een ontwikkelaar inhuren of met AI bouwen.

Veelgemaakte fouten en misverstanden

• „GitHub en Git zijn hetzelfde.” Git werkt zonder GitHub; alternatieven zoals GitLab en Bitbucket hosten ook Git-repositories.
• „GitHub draait mijn app.” GitHub bewaart code. Die voor het publiek laten draaien is webhosting, een aparte dienst (al deployen sommige hosts vanuit GitHub).
• Geheimen committen. De meest schadelijke en meest voorkomende fout. Gebruik .gitignore voor .env-bestanden, en vervang elke sleutel die ooit is gepusht.
• Alleen één branch en geen berichten. Prima voor solo-experimenten, maar geef commits duidelijke berichten en gebruik branches voor alles wat riskant is.
• Op twee plekken tegelijk bewerken. Als je code wijzigt in GitHub en in je AI-appbouwer zonder ertussen te pullen, ontstaan conflicten. Kies per keer één plek om te bewerken en synchroniseer voordat je wisselt.
• Denken dat een privérepo een back-up van alles is. Die bevat code, geen databasegegevens of geüploade bestanden. Die hebben hun eigen back-ups nodig.

Wat je aan je AI-appbouwer kunt vragen

• „Voeg een .gitignore toe die .env, afhankelijkheidsmappen en buildoutput uitsluit.”
• „Schrijf een README die uitlegt hoe je installeert, welke omgevingsvariabelen nodig zijn (alleen de namen) en hoe je de app draait.”
• „Voeg een .env.example toe met elke variabelenaam en zonder echte waarden.”
• „Gebruik duidelijke, beschrijvende commit-berichten voor elke wijziging.”

Met die vier verzoeken krijg je een repository die een ontwikkelaar in enkele minuten kan oppakken. Om de app naar je eigen servers te verplaatsen, zie hoe je een met AI gebouwde app exporteert en zelf hostt, en voor het verstevigen voordat echte gebruikers erbij komen, een AI-prototype naar productie brengen.

GitHub en Mythex

Mythex bewaart de geschiedenis voor je op elk abonnement: na elke geslaagde agentbeurt slaat het een checkpoint op, een Git-snapshot waarnaar je kunt terugkeren. Op Pro kun je GitHub koppelen en het project naar je eigen repository pushen of ervandaan pullen, of het hele project als archief downloaden; geheimen en geïnstalleerde afhankelijkheden worden bij exports uitgesloten. GitHub dient hier om code te synchroniseren, niet om in te loggen bij Mythex. Zie GitHub, export en import in de documentatie, en de prijspagina voor wat elk abonnement bevat.

Veelgestelde vragen