105 lines
4.8 KiB
Markdown
Executable file
105 lines
4.8 KiB
Markdown
Executable file
# 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:
|
|
|
|
1. [Een issue aanmaken](#issues)
|
|
2. [Een branch maken](#workflow)
|
|
3. [Code schrijven](#coding-conventions)
|
|
4. [Werk committen](#commits)
|
|
5. [Een pull request maken](#pull-request)
|
|
|
|
## 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](.github/ISSUE_TEMPLATE) voorzien.
|
|
Gebruik deze om alle nodige informatie te verzamelen.
|
|
|
|
Gebruik de juiste [labels](https://github.com/SELab-2/Dwengo-1/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](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow).
|
|
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](https://github.com/SELab-2/Dwengo-1/wiki/Developmentstrategie-keuzes#gitflow) meer over de beslissing om Gitflow te gebruiken.
|
|
|
|
We hebben ervoor gekozen om `main` en `dev` te beschermen.
|
|
Zie ook [pull request](#pull-request).
|
|
|
|
## Coding conventions
|
|
|
|
Om de code consistent te houden, maken dit project gebruik van enkele tools:
|
|
|
|
- Formatting: [Prettier](https://prettier.io/), zorgt ervoor dat de code consistent geformatteerd is.
|
|
- Linting: [ESLint](https://typescript-eslint.io/), 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](https://git-scm.com/docs/githooks).
|
|
|
|
## Commits
|
|
|
|
**Conventionele commits**
|
|
|
|
Dit project maakt gebruik van [conventional commits](https://www.conventionalcommits.org/).
|
|
|
|
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](https://github.com/SELab-2/Dwengo-1/wiki/Developmentstrategie-keuzes#conventionele-commits) meer over de beslissing om conventionele commits te gebruiken.
|
|
|
|
**Andere tips**
|
|
|
|
Als je een commit 'fixt', gebruik dan [`git commit --fixup`](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---fixupamendrewordltcommitgt)
|
|
|
|
Als je een commit niet alleen hebt geschreven, maak dan een [commit met meerdere auteurs](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors).
|
|
|
|
## 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](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests)) pull requests maakt, zodat anderen kunnen meekijken en feedback kunnen geven.
|
|
|
|
Om je op weg te helpen is er een [template](.github/PULL_REQUEST_TEMPLATE.md) 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](https://docs.github.com/en/github/administering-a-repository/about-protected-branches) 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.
|
|
|
|
## Dankjewel!
|