Hoe bijdragen aan Dwengo-1?

Bedankt dat je wil bijdragen aan Dwengo-1! Hieronder vind je enkele richtlijnen om je op weg te helpen.

Over het algemeen bestaat de workflow uit de volgende stappen:

Een issue aanmaken
Een branch maken
Code schrijven
Werk committen
Een pull request maken

Issues

Als je een issue aanmaakt is het belangrijk om zo veel mogelijk (relevante) informatie te geven. Om je op weg te helpen zijn er templates voorzien. Gebruik deze om alle nodige informatie te verzamelen.

Gebruik de juiste labels om te helpen een onderscheid te maken tussen verschillende categorieën issues.

Ken jezelf toe aan een issue als je eraan werkt, zodat er beter een overzicht bewaard kan worden. Op die manier vermijd je onnodig werk.

Workflow

Dit project maakt gebruik van (een minder strenge versie van) Gitflow. Dat betekent dat verschillende branches een verschillende rol hebben. Nieuwe branches worden aangemaakt vanuit dev en worden gemerged naar dev.

Een overzicht:

main: Hier worden enkel de releases gemerged. Elke merge naar main moet een release zijn, aangeduid met een tag (v1.2.3).
dev: Jouw branch hoort hiervan af te takken.
- feat/my-feat: Voor features die uit geen of meer dan 1 issue bestaan
- feat/this-#x: Voor features die aan een issue gelinkt kunnen worden
- fix/something-#x: Voor (minder dringende) bug fixes. Bug fixes worden aan een issue gelinkt.
release/x.y.z: Voorbereidingen voor een release. Hier worden enkel bug fixes en hotfixes gemerged.

Lees hier meer over de beslissing om Gitflow te gebruiken.

We hebben ervoor gekozen om main en dev te beschermen. Zie ook pull request.

Coding conventions

Om de code consistent te houden, maken dit project gebruik van enkele tools:

Formatting: Prettier, zorgt ervoor dat de code consistent geformatteerd is.
Linting: ESLint, zorgt er o.a. voor dat de code geen "slechte" constructies bevat.

Je kan ze handmatig uitvoeren met npm run lint en npm run format.

Deze tools worden niet standaard automatisch uitgevoerd bij een commit. Automatisch uitvoeren bij een commit kan met git hooks.

Commits

Conventionele commits

Dit project maakt gebruik van conventional commits.

Dit betekent dat elke commit een duidelijke boodschap moet hebben, die volgens een bepaald formaat is opgesteld. In het kort ziet dat er zo uit:

<type>(<optional scope>): <description>

type options:
    feat, fix, refactor, test, docs, build, ci, chore, ...

Lees hier meer over de beslissing om conventionele commits te gebruiken.

Andere tips

Als je een commit 'fixt', gebruik dan git commit --fixup

Als je een commit niet alleen hebt geschreven, maak dan een commit met meerdere auteurs.

Pull request

Eens je code hebt geschreven en gecommit, is het tijd om een pull request te maken. Het is fijn als je meteen (draft) pull requests maakt, zodat anderen kunnen meekijken en feedback kunnen geven.

Om je op weg te helpen is er een template voorzien. Door deze in te vullen, zorg je ervoor dat de reviewer een duidelijk beeld heeft van wat je hebt gedaan.

Als je aan visuele features werkt, voeg dan een screenshot van de omgeving van de feature toe, voor en na dat de feature geïmplementeerd werd.

Branch protection

Je zult merken dat sommige branches beschermd zijn. Dit betekent dat je niet zomaar kan mergen naar deze branches:

main: kan enkel vanuit release/x.y.z
dev: wordt nagekeken alvorens te mergen

Elders kan je vrij mergen.

Het zou kunnen dat je code bepaalde checks moet doorstaan alvorens te mergen. Dit kan gaan van een simpele lint check tot een volledige test suite die moet slagen. Tag gerust een maintainer als je denkt dat je code klaar is om gemerged te worden.

4.8 KiB Executable file Raw Blame History