Platformen

Over het algemeen gebruiken wij GitLab voor repositories waarvan de code beschermd is (zoals alle projecten voor klanten) en gebruiken wij GitHub voor repositories waarvan de broncode publiek is, zoals onze opensourceprojecten. Wij hebben echter ook ervaring met andere platformen als Bitbucket en Planio, voor het geval u al ergens een repository heeft draaien. Indien wenselijk, kunnen repositories ook tussen platformen worden verhuisd of gespiegeld.

Branches

main

Dit is de basis-branch met actuele code. Deze zou gelijk moeten zijn met wat op de productie-omgeving draait. Vroeger heette deze branch master, maar op een gegeven moment kwam er bezwaar vanuit de opensourcegemeenschap dat dit associaties opriep met slavernij. Sindsdien hanteren we voor nieuwe repositories de naam main en passen wij oude repositories hiernaar aan als we ze tegenkomen.

develop

Omdat wij doorgaans niet naar de main-branch willen committeren om merge-conflicten op productiecode te voorkomen, kan worden ontwikkeld op de develop-branch. Vroeger hadden we deze branch vrijwel altijd, maar tegenwoordig gebruiken we steeds vaker een van onderstaande patronen omdat deze een hogere specificiteit hebben en een algemene aftakking van de main-branch maar beperkt voordelen biedt.

dev/{username}

Om ontwikkelaars de mogelijkheid te geven om naar een branch te commiteren waarvan zij zeker weten dat er in de tussentijd niet een andere ontwikkelaar naar heeft gecommiteerd (en er zo mogelijk merge-confliceten ontstaan die moeten worden opgelost), zijn zij vrij op een eigen branch te commiteren die een relatie heeft tot hun gebruikersnaam binnen het platform waarop gewerkt wordt.

feature/{slug}

Als er een nieuw — redelijk goed te isoleren — onderdeel moet worden ontwikkeld, zoals een nieuw component of een nieuwe widget binnen een grotere applicatie, kan hier middels dit patroon een specifieke branch voor worden gemaakt. Deze hoeft alleen een korte beschrijvende naam als slug te hebben.

issue/{id}_{slug}

Als een aanpassing een directe relatie heeft tot een support-ticket, zoals een bug die is gevonden, of een suggestie van een klant, kan deze met het ticket-id én een korte beschrijving als slug naar een eigen branch worden gecommiteerd. Commits binnen deze branch kunnen middels het sleutelwoord refs in de beschrijving automatisch worden gekoppeld aan het ticket.

milestone/{id}_{slug}

Soms hebben we een serie tickets die onderdeel uitmaken van een groter project. Dit is vergelijkbaar met een feature, maar iets gestructeerder door een koppeling met een ticketsysteem. In zulke gevallen wordt er meestal gecommiteerd naar issue-branches, om deze vervolgens te mergen met een milestone-branch. Pas als alle tickets van de milestone zijn opgepakt, wordt de milestone-branch doorgezet naar bijvoorbeeld main.

archive

Als een project een volledige redesign en/of refactoring krijgt, kan het zijn dat we daarvoor een archief willen parkeren op de archieven. In dat geval kunnen we de main-branch kopieren naar de archive-branch.