Git workflow voor WordPress: complete gids voor veilig ontwikkelen en deployen

Een Git workflow voor WordPress is een vaste werkwijze om wijzigingen aan je theme, maatwerkplugin en configuratie gecontroleerd te ontwikkelen, te beoordelen, te testen en pas daarna te publiceren. Je werkt niet rechtstreeks op de live website: elke wijziging krijgt een eigen branch, wordt via een pull request gecontroleerd en gaat via staging naar productie. Zo zijn wijzigingen traceerbaar en kun je fouten eenvoudiger terugdraaien.

Wat is Git en waarom gebruik je het voor WordPress?

Git is versiebeheer voor bestanden. Het legt vast welke wijziging is gedaan, door wie en waarom. Daardoor kun je samenwerken zonder elkaars werk te overschrijven en kun je terug naar een eerdere werkende versie van de code.

Voor een WordPress-site is Git vooral waardevol voor maatwerk: een eigen theme, child theme, block theme, plugin of eigen functionaliteit. De WordPress Theme Handbook beschrijft de basis voor themeontwikkeling, waaronder de verschillen tussen classic en block themes.

Git is niet hetzelfde als GitHub. Git is het versiebeheersysteem op je computer en server. GitHub is een platform waar je Git-repository kan staan en waar je bijvoorbeeld pull requests en reviews organiseert. GitHub Actions kan vervolgens geautomatiseerde controles of deployments uitvoeren. Ook dat is iets anders dan de hostingomgeving waar je WordPress draait.

Wat zet je wel en niet in Git?

De belangrijkste grens is eenvoudig: code en reproduceerbare configuratie horen doorgaans in Git. Content, uploads en gegevens uit de database vragen om een aparte aanpak.

Onderdeel	In Git?	Praktische werkwijze	Waarom
Eigen theme of child theme	Ja	Beheer alle bronbestanden, templates, styles, scripts en theme.json in één repository.	Dit is de code die je ontwikkelt en uitrolt.
Maatwerkplugin	Ja	Gebruik een eigen repository of neem de plugin als duidelijke map in het project op.	Functionaliteit blijft controleerbaar en overdraagbaar.
Buildconfiguratie	Ja	Commit bijvoorbeeld package-configuratie, bronbestanden en scripts voor builds.	Een teamlid of deploymentproces moet dezelfde build kunnen maken.
Gebouwde bestanden	Beslis bewust	Leg vast of productie-assets uit de build worden gegenereerd tijdens deployment of mee worden gecommit.	Voorkom dat lokaal en live verschillende assets gebruiken.
WordPress-core	Meestal niet	Beheer core via je hosting, een vaste installatieprocedure of een afhankelijkhedenbeheerder.	Core is geen eigen maatwerk en krijgt eigen updates.
Plugins van derden	Meestal niet	Registreer welke plugins nodig zijn en update ze via een beheerd proces.	Voorkomt grote repositories en onduidelijk eigenaarschap.
Database	Nee	Gebruik aparte database-back-ups, exports en een gecontroleerd proces voor migraties.	Berichten, instellingen en gebruikersdata zijn geen broncode.
Uploads in wp-content/uploads	Nee	Maak reguliere back-ups en synchroniseer media alleen via een bewust gekozen migratieproces.	Media verandert vaak en maakt een repository onnodig zwaar.
Wachtwoorden en API-sleutels	Nee	Bewaar geheimen in omgevingsvariabelen of de beveiligde geheimenopslag van je deploymentplatform.	Geheimen in een repository vormen een veiligheidsrisico.

De precieze themestructuur verschilt per project. WordPress beschrijft welke bestanden en mappen bij een theme kunnen horen, inclusief projectbestanden zoals .gitattributes, in de documentatie over theme structure.

Een praktische Git workflow voor WordPress opzetten

Voor de meeste kleine teams is een eenvoudige branch-gebaseerde aanpak het meest werkbaar. De hoofdbranch bevat alleen code die klaar is voor release. Nieuwe wijzigingen worden geïsoleerd ontwikkeld in een tijdelijke feature branch. Dit sluit aan op GitHub Flow, waarin branches en pull requests centraal staan.

1. Kies wat je beheert. Begin met het maatwerktheme en eventuele maatwerkplugins. Maak een .gitignore die uploads, caches, tijdelijke bestanden, lokale configuratie en geheimen uitsluit.
2. Maak een centrale repository. Plaats de repository op een platform waar de juiste personen toegang hebben. Beperk schrijfrechten tot mensen die wijzigingen mogen samenvoegen of uitrollen.
3. Leg de hoofdbranch vast. Gebruik bijvoorbeeld main als versie die naar productie mag. Bescherm deze branch: wijzigingen komen er alleen in via een pull request.
4. Werk lokaal in een aparte omgeving. Maak voor iedere taak een branch, bijvoorbeeld feature/contactformulier-validatie of fix/mobile-menu. Pas de code lokaal aan en controleer de wijziging in een lokale WordPress-installatie.
5. Commit kleine, begrijpelijke stappen. Een commit beschrijft één logisch onderdeel, zoals “Voeg validatie toe aan formulier”. Vermijd verzamelcommits met ongerelateerde aanpassingen.
6. Push de branch en open een pull request. Beschrijf wat er verandert, waarom dit nodig is, hoe je hebt getest en welke risico’s er zijn. Een pull request maakt vergelijking, bespreking en review mogelijk.
7. Laat controleren en test geautomatiseerd waar mogelijk. Controleer functionaliteit, toegankelijkheid, responsive gedrag, foutmeldingen en beveiligingsgevoelige code. GitHub beschrijft pull requests als een plek om wijzigingen te vergelijken, te bespreken en samen te voegen.
8. Deploy naar staging. Zet de goedgekeurde code eerst op een afgeschermde testomgeving die zoveel mogelijk op productie lijkt. Controleer daar de volledige gebruikersroute en relevante WordPress-functionaliteit.
9. Merge en deploy naar productie. Voeg pas samen als de stagingcontrole is afgerond. Leg vast wie live mag zetten, hoe je controleert na deployment en hoe je terugrolt bij een probleem.
10. Documenteer uitzonderingen. Noteer bijvoorbeeld vereiste pluginupdates, databasehandelingen, cache-clears en handmatige instellingen. Zo blijft het proces overdraagbaar.

Pull requests en automatische controles

Een pull request is meer dan een verzoek om code samen te voegen. Het is een controlemoment vóór een wijziging op staging of productie belandt. Gebruik een vaste beschrijving met: doel van de wijziging, betrokken bestanden, teststappen, eventuele database-impact en terugrolactie.

Automatische controles kunnen helpen om dezelfde basischecks bij elke wijziging uit te voeren. GitHub Actions werkt met workflows die gebeurtenissen in een repository kunnen afhandelen, zoals een pull request of een merge. Welke tests zinvol zijn, hangt af van het project. Begin liever met een betrouwbare, beperkte set controles dan met complexe automatisering die niemand onderhoudt.

Git, staging en productie: houd verantwoordelijkheden gescheiden

Git beheert codehistorie. Staging is een omgeving om code te testen. Productie is de live omgeving voor bezoekers. Deze onderdelen versterken elkaar, maar vervangen elkaar niet.

Maak daarom expliciete afspraken over deployments. Deploy je alleen het custom theme en de maatwerkplugins, dan is de kans kleiner dat een release onbedoeld WordPress-core, uploads of instellingen overschrijft. Houd daarnaast reguliere back-ups van bestanden en database beschikbaar. Een Git-repository is geen volledige back-up van je WordPress-website.

Let extra goed op redirects bij een release waarin URL’s, contentstructuur of templates veranderen. Controleer na publicatie of belangrijke oude URL’s correct reageren. Onze gids over 404- en soft-404-fouten oplossen helpt je daarbij.

WordPress-specifieke aandachtspunten

Block themes en theme.json

Bij block themes zitten templates, template parts, styles en instellingen grotendeels in themebestanden. Daardoor passen ze goed in Git. theme.json verdient bijzondere aandacht: wijzigingen kunnen invloed hebben op editorinstellingen, stijlen en beschikbare ontwerpopties.

Wijzigingen die een redacteur alleen in de Site Editor doet, zijn niet automatisch hetzelfde als wijzigingen in bestanden van je theme. Maak daarom vooraf een keuze: welke ontwerpwijzigingen horen in het theme en welke blijven redactionele instellingen in WordPress? WordPress beschrijft ook een werkwijze waarin wijzigingen aan block themes via WordPress Playground en GitHub naar een pull request kunnen worden gebracht. Leg binnen je team vast wie deze synchronisatie beheert.

Lees voor de bredere technische en redactionele context ook de geplande gids over block themes en Full Site Editing zodra die beschikbaar is. Vermijd intussen dat live ontwerpwijzigingen zonder review ongemerkt de vaste basis van je theme worden.

Buildprocessen

Gebruik je moderne JavaScript of blokken met een buildstap, beheer dan de bronbestanden en buildconfiguratie zorgvuldig. De WordPress-documentatie over het build process behandelt onder meer tooling rond @wordpress/scripts. Bepaal vooraf waar de build plaatsvindt: lokaal vóór een commit, in een geautomatiseerde workflow of tijdens deployment. Kies één duidelijke werkwijze en documenteer die.

Database en configuratie

WordPress bewaart veel gegevens in de database: berichten, pagina’s, gebruikers, instellingen en vaak ook instellingen van plugins. Git beheert die data niet automatisch. Plan databasewijzigingen daarom apart. Denk aan een gecontroleerde export-import, een migratiescript of handmatige stappen die je tijdens een release afvinkt.

Scheid bovendien omgevingsspecifieke gegevens van de code. Een lokaal e-mailadres voor testmails of een productie-API-sleutel hoort niet in dezelfde openbare configuratie als je themecode.

GitHub Flow of Git Flow voor een klein WordPress-team?

Voor een klein team of een mkb-website met regelmatige, overzichtelijke wijzigingen is GitHub Flow meestal een logische start: één hoofdbranch, korte feature branches en pull requests vóór samenvoegen. Het proces is eenvoudig uit te leggen aan een website-eigenaar en beperkt de beheerlast.

Een uitgebreidere Git Flow-aanpak met aparte release- en hotfixbranches kan passend zijn wanneer releases strak gepland zijn, meerdere versies tegelijk worden onderhouden of er veel ontwikkelaars samenwerken. Voor een reguliere zakelijke WordPress-site voegt die extra structuur vaak pas waarde toe als de complexiteit daar echt om vraagt.

Veelgemaakte fouten

• Rechtstreeks live wijzigen: een snelle aanpassing in de Theme File Editor of via FTP is moeilijk te reviewen en reproduceerbaar te maken.
• Database als bijzaak behandelen: code kan goed zijn, terwijl ontbrekende instellingen of content de release alsnog laten mislukken.
• Geheimen committen: wachtwoorden, tokens en privésleutels horen niet in de repository of commitgeschiedenis.
• Een onduidelijke buildstrategie: als niemand weet of gebouwde assets moeten worden meegestuurd, ontstaan verschillen tussen lokaal, staging en productie.
• Te grote pull requests: grote gemengde wijzigingen zijn lastiger te beoordelen, testen en terugdraaien.
• Geen rollback voorbereiden: bepaal vóór een deployment welke vorige versie je kunt herstellen en wie dat doet.

Snelle checklist vóór je eerste release

• Het maatwerktheme en maatwerkplugins staan in een centrale repository.
• Uploads, caches, lokale configuratie en geheimen zijn uitgesloten via .gitignore.
• De hoofdbranch is beschermd en wijzigingen lopen via pull requests.
• Iedere wijziging is lokaal getest en daarna op staging gecontroleerd.
• Database- en configuratiestappen staan in de releasebeschrijving.
• Er is een actuele back-up en een duidelijke rollbackprocedure.
• Na livegang controleer je de belangrijkste pagina’s, formulieren, tracking en URL’s.

Wanneer schakel je WordPress development ondersteuning in?

Een Git workflow vraagt vooral om heldere keuzes: wat hoort in versiebeheer, hoe test je, wie keurt goed en hoe deploy je veilig? Wordt je site uitgebreid met maatwerkblokken, koppelingen, complexe formulieren of meerdere betrokkenen, dan is het verstandig om deze werkwijze vroeg in het project in te richten.

LYNX Media helpt bedrijven met websites die technisch beheersbaar blijven en aansluiten op commerciële doelen. Bekijk onze aanpak voor strategisch creatief webdesign of ontdek alle webdesign-, SEO- en online marketingdiensten. Wil je je ontwikkelproces, WordPress-site of groeikansen bespreken? Neem contact op met LYNX Media.