Git strategy

Waarom git?

Voor onze samenwerking gaan we gebruik maken van Git in combinatie met de website GitHub.com. Het gebruik van Git in een teamverband is extreem handing, vandaar dat wij het gaan gebruiken. Voor deze samenwerking hebben we een aantal guidelines opgesteld waardoor dit zo soepel mogelijk zal verlopen. Hiervoor gaan we voornamelijk gebruik maken van branches. Met behulp van branches kan iedereen op zijn eigen tak van de code werken. Op deze manier kan de code van iemand de code van de andere teamgenoten niet beïnvloeden. Zodra iemand klaar is met zijn branch kan deze tak weer met main worden gemerged. Git voegt de code dan samen tot een geheel.

Onze strategy

Onze strategie is onder te verdelen in drie onderdelen namelijk branches, commits en pull requests / mergen. Hoe wij deze gaan aanpakken staat hieronder in detail uitgelegd.

Branches

Zoals ik net al had uitgelegd zijn branches extreem handig bij het samenwerken in GitHub. Iedereen kan op zijn eigen branch werken aan zijn eigen features. Hierdoor zal de code van de rest van het team niet worden aangetast. We gaan de branches voor een aantal verschillende doeleinden gebruiken namelijk:

• Main. De main branch zal de laatste complete versie van onze code bevatten. Alle individuele branches zullen dus hierin gemerged worden. Normaliter staat op main de huidige versie van de code die ook online te vinden is. Voor de development branch wordt normaal de branch dev gebruikt. Omdat DogeMeet echter nog geen draaiende live versie heeft hebben we er voor gekozen om de dev branch voor nu niet in te schakelen.
• features. Voor al de features die moeten worden geïmplementeerd zullen we aparte branches aanmaken. Zo zal er bijvoorbeeld een aparte branch komen voor de matchings en chat feature. Zodra iemand klaar is met zijn feature en branch kan hij middels een pull request met main worden gemerged. We zullen na deze merge de branch niet verwijderen zodat we er later altijd nog op terug kunnen kijken.
• hotfixes. Voor kleine bugs in features die al met main zijn gemerged zullen we aparte branches aanmaken. Dit doen we omdat we ze dan snel kunnen fixen om ze hierna direct met main te kunnen mergen.

Commits

Een belangrijk deel van de commits zijn de bijbehorende messages. Deze berichten moeten aan een aantal criteria voldoen, namelijk:

• Ze mogen niet lang zijn,
• Ze moeten goed uitleggen wat er in de commit is veranderd.
• Ze moeten voor de andere teamgenoten makkelijk zijn om te begrijpen.

Als deze regels worden nageleefd kan iedereen makkelijk elkaars commit messages lezen en begrijpen. We gaan proberen om zoveel mogelijk commits te maken als mogelijk is in onze branches. Op deze manier kunnen we makkelijk naar een oude versie terugdraaien zodat we met een gerust hart door kunnen gaan met onze features.

Pull requests en mergen

Zodra iemand klaar is met zijn branch kan hij hiervoor een pull request aanmaken. Deze pull requests mogen alleen met main worden gemerged nadat ze door minimaal 1 persoon zijn nagekeken. Ook moet de pull request een beschrijving hebben van wat er precies is veranderd na het uitvoeren van de request. Op deze manier voorkomen we dat er code in main komt die nog niet klaar is om gemerged te worden. Deze persoon moet ook middels een comment feedback achterlaten op de pull requests. Mochten er tijdens een pull request een merge conflict ontstaan dan moet de persoon van de pull request even samen met een ander kijken hoe het opgelost moet worden.