Motivatie versiebheer keuzes

Developmentstrategie-keuzes.md

@@ -0,0 +1,20 @@
+## Versiebeheer
+
+### Gitflow
+
+Dit project maakt gebruik van de [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) workflow voor versiebeheer. De keuze voor Gitflow is gemaakt om de volgende redenen:
+
+- :white_check_mark: **Duidelijke beschrijving van de functie van iedere branche:** Gitflow definieert specifieke branches voor verschillende doeleinden, zoals `main`, `dev`, feature branches, release branches en hotfix branches.
+- :white_check_mark: **Eenvoudiger werken met een duidelijke releasecyclus:** Gitflow beschrijft een georganiseerde aanpak voor het uitrollen van nieuwe versies, inclusief het beheren van hotfixes en het voorbereiden van releases. Dit komt van nature overeen met de aard van het project.
+
+Hoewel Gitflow het moeilijker maakt :negative_squared_cross_mark: om met meerdere ontwikkelaars aan dezelfde feature of bugfix te werken - vooral als ze afhankelijk zijn van dezelfde branches - is dit waarschijnlijk om efficiëntieredenen niet de bedoeling en wordt dit zo gedemotiveerd.
+
+### Conventionele commits
+
+Voor onze commitberichten volgen we de [conventionele commit](https://www.conventionalcommits.org/) conventie. Deze keuze werd om de volgende redenen gemaakt:
+
+- :white_check_mark: **Stimuleert atomaire commits:** De structuur van conventionele commits moedigt onwikkelaars aan om kleine, gerichte commits te maken, in plaats van grote.
+- :white_check_mark: **Overzicht:** Gestandaardiseerde commitberichten bieden een helder overzicht van de aangebrachte wijzigingen, zowel in een release beschrijving als in bv. `git log`.
+- :white_check_mark: **Vereenvoudigt code-reviews:** Duidelijke en consistente commitberichten helpen reviewers om snel de context van wijzigingen te begrijpen.
+
+Desondanks dat conventionele commits een kleine leercurve vragen, wegen de voordelen meer door.