Bij het realiseren van de verschillende deelproducten is gebruik gemaakt van de interne Gitlab. Er zijn vanuit het bedrijf niet per sé eisen gesteld over hoe de git omgeving eruit moest komen te zien. Daarom is de volgende git flow aangehouden:

Branches

• master: Hiernaar kan alleen gemerged worden vanuit de develop branch. Dit wordt alleen maar gedaan als een (deel)product volledig af is (bijvoorbeeld de prototypes of de eerste les).
• develop: Bevat alle nieuwe features voor de volgende 'release' (in de context van dit project de volgende milestone). Er mag niet direct gewerkt worden op deze branch.
• feature/[name]: Voor elke 'feature' wordt een nieuwe branch aangemaakt. Bijvoorbeeld de feature 'laserpointer' of 'spatial understanding'. Ook worden featurebranches aangemaakt voor grote bugs waar veel tijd in kan gaan zitten (bijvoorbeeld het herschrijven van een stuk code, omdat er iets niet klopt in de structuur). Feature branches worden gemerged naar develop zodra de feature af is en worden daarna verwijderd.

Namen van branches worden altijd geschreven in kleine letters. Dit voorkomt verwarring.

Merge requests

Nadat een feature af is wordt de feature branch gemerged naar de develop. Dit gebeurd aan de hand van een merge request. Merge requests zijn voornamelijk handig als je met meerdere personen aan hetzelfde project werkt. Hoewel dat hier niet het geval is, wordt er hier alsnog voor gekozen niet direct te mergen. Dit omdat de merge requests zichtbaar blijven in Gitlab. Dit is een manier om bij te houden welke features allemaal geïmplementeerd zijn en wat er precies gemerged is.

Commits

Bij het opstellen van commits worden de volgende regels aangehouden:

• Commits worden in het engels geschreven. Op die manier kan iedereen begrijpen wat er is veranderd. Ook als er in de toekomst een niet nederlandssprekende persoon het project oppakt.
• Commits worden in gebiedende wijs geschreven. Bijv. "Add new textures for UI buttons" in plaats van "Added new textures for UI buttons". Dit zorgt ervoor dat de commit leesbaarder en meer 'to-the-point' is.
• Commits beginnen met een hoofdletter. Net zoals met een normale zin.
• Commits kunnen meerdere regels bevatten.  In de eerste regel van een commit wordt beschreven wat er veranderd wordt (max 50 tekens). Optioneel kan dan na een witregel beschreven worden waarom bepaalde keuzes zijn genomen. In Gitlab worden deze regels ook apart als titel en omschrijving weergegeven (zie figuur 1).
• Commits moeten niet te groot zijn. Een commit moet niet een heleboel verschillende onderdelen aanpassen. Dit kan opgesplitst worden in meerdere commits. Bijvoorbeeld: implementeer eerst de GUI, los dan de bug op die je ondertussen bent tegengekomen in een nieuwe commit (tenzij je niet verder kan werken door de bug) en begin dan aan het toevoegen van 3d modellen.
• Het product moet altijd compilen na een commit. Het kan zijn dat bepaalde features nog niet of niet meer werken na een commit, maar het moet nooit voorkomen dat er compiling errors voorkomen na een commit. Deze moeten opgelost worden voordat er gecommit wordt.

^{Figuur 1. Mutliline commit in Gitlab}

Onderzoeksmethoden

De git flow is ontstaan in verschillende iteraties. Origineel zijn de regels gebaseerd op de beschrijving van Vincent Driessen. Na zijn model meerdere keren toe te passen, elke keer een klein beetje aan te passen en door nieuwe regels toe te voegen zijn deze regels ontstaan.

Foto's

Rubrics