Met meerdere developers samenwerken aan een grote applicatie die binnen WordPress opgezet moet worden. De eerste kreet die dan bij je opkomt is versie beheer. Ja, dat gaan we doen. Vervolgens hoor je gebruik te gaan maken van een 3 staps raket die in de volksmond ook wel dev-stage-live wordt genoemd. Maar hoe past een en ander nu in de praktijk bij elkaar?

Git gebruiken voor een WordPress site

In het begin is het enigszins overweldigend: zoveel verschillende dingen waar je rekening mee moet houden dat je soms weer liever terug wil naar de ouderwetse tijd van cowboy coding: gewoon direct via de FTP de site aanpassen. Maar nee, we gingen het nu eens een keer goed aanpakken. Geduld dus, en rustig aan doen. We beginnen met het lokaal opzetten van een standaard WordPress installatie, in mijn geval via MAMP. Dit zijn een paar simpele stappen: het aanmaken van een database, het downloaden van de laatste WordPress versie, het aanpassen van het wp-config.php bestand en tenslotte het draaien van de famous 5 minutes install.

Starten met Git voor WordPress

Dan gaan we de Git omgeving opzetten. Ik neem hier gemakshalve even aan dat Git geïnstalleerd is op je systeem en dat we Git commando’s via de command line gaan invoeren. Er zijn ook GUI programma’s voor, maar ik vond het werken via de command line het meest duidelijk. Navigeer dus naar de map waar je WordPress hebt geïnstalleerd en initialiseer een git repository met

git init

Het mooie aan Git vind ik dat de meldingen die je terugkrijgt (over het algemeen) heel duidelijk en beschrijvend zijn. Na bovenstaand commando krijg je dan ook de melding terug:

Initialized empty Git repository in <WordPress directory>

Voordat je nu halsoverkop bestanden aan de repo gaat toevoegen is het verstandig om te bedenken welke bestanden je wellicht niet onder versie beheer wilt bewaren. Als voorbeeld noem ik de wp-config.php file. Daarin staan namelijk de database gegevens en aangenomen dat we straks ook deze site op een stage en live omgeving willen zetten, zullen deze installaties een andere wp-config content hebben. Op GitHub staat voor WordPress (en een boele andere CMS-en) voorbeelden van zogenaamde .gitignore files. Doe er je voordeel mee!

We bouwen dus de .gitignore file op en voegen deze toe aan de git repo. Het is over het algemeen ook gebruikelijk een README file aan te maken waarin je het doel van het project zet. Nu is het tijd om deze bestanden toe te voegen aan de repo. Trouwens, ook de andere bestanden in de map. Git zal automatisch de bestanden die in .gitignore staan niet toevoegen.

De eerste Git commit

Git werkt met een 2 staps raket om bestanden die je hebt aangepast toe te voegen voor de commit en vervolgens de commit zelf. Je kunt deze ook in een keer doen. Voor de volledigheid doen we ze apart:

git add .
git commit -m 'Initial commit of the project.'

Het argument -m is verplicht en je kunt daarachter je commit message typen.

Branches in Git

Nu we de eerste commit hebben gedaan is het tijd om de workflow op te zetten. We volgen hier de Git workflow van Vincent Driessen. We passen deze toe op onze huidige repo. De eerste stap is dus het aanmaken van een develop branch en van een release branch. De inhoud van die branches kopieren we (dit gaat automatisch) van de huidige branch (master). Dat gaat zo:

git checkout -b develop master
git checkout -b release master

We wijken hier al iets af van het beschreven model. Dat heeft te maken met de manier waarop we Git gebruiken voor WordPress en dat beschrijven we volgende keer in meer detail. Wat belangrijk is om te onthouden is dat lokaal op je computer in de map waar je WordPress hebt geïnstalleerd de bestanden wijzigen wanneer je van de ene naar de andere branch gaat. Op dit moment zijn alle branches op hetzelfde punt: alle code is gelijk en dus gebeurt er niks met de bestanden als je van de ene naar de andere branch springt. Maar stel je voor dat je lekker aan het werk gaat (typisch in de develop branch) en hier een aantal commits doet. Vervolgens switch je naar de release of master branch. Dan worden de bestanden in de map door het Git systeem aangepast zodat ze kloppen met die branch. Verder kun je in die map zelf niet zien in welke branch je zit. Dat zie je alleen door de status op te vragen met git of door op te vragen welke branches er zijn:

git status
git branch

Het eerste commando geeft iets terug in de trant van:

On branch develop
Your branch is up-to-date with 'origin/develop'.

De ander:

* develop
  master 
  release

Wanneer je na een aantal commits het gevoel hebt dat de site die je bouwt in een stabiele versie begint te veranderen, is het wellicht tijd om deze veranderingen ook te delen met je klant. Daarvoor hebben we de dev-stage-live omgeving. Op dit moment is het belangrijk om te weten hoe je de aanpassingen in de develop branch ook kan doorvoeren in de andere branches. Dat gaat met een merge. De eenvoudigste merge is de fast forward. Dit betekent in feite dat alle wijzigingen in de develop branch zonder conflict kunnen worden doorgevoerd. Om zo’n merge te doen ga je eerst naar de branch waarin je wilt mergen (bijv. release) en dan merge je de develop branch erin:

git checkout release
git merge develop

Het is ook mogelijk dat de merge niet direct succesvol gaat. Dan is er een conflict. Wat Git dan heel handig doet is in de bestanden die een conflict hebben beide stukken code (waarvan Git niet kan weten welke de correcte is) onder elkaar zetten. Je moet dan zelf even de juiste implementatie kiezen. Opslaan en weer committen en het conflict is opgelost.

Volgende keer

Om dit blogbericht niet al te veel uit de kluiten te laten groeien stop ik er nu mee. Volgende keer meer over het daadwerkelijk deployen van de site vanaf de lokale omgeving naar de stage en live omgevingen. In die post komt dan direct ook het volgende issue ter sprake: hoe houd je de database in sync wanneer je tegelijkertijd met meerdere developers aan de site aan het werk bent?