# Git Workflow

## Gitflow Workflow

Wij werken met de [Gitflow Workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) van Atlassian. Wij maken onderscheid tussen een `feature`, `docs`, `development`, `release` en `main` branch.

Naar `development` is 1 approval nodig en naar `main` zijn er drie nodig. Hierdoor wordt de kwaliteit van de code gewaarborgd.&#x20;

![](https://1559388126-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Mac7UhNdHbwLV2TKZ4O%2F-Mc9qeLzMF58xDr-LG8I%2F-Mc9rEs5f2sK-I8DQRGB%2Fimage.png?alt=media\&token=ef8ef90a-f9ad-430a-8074-aad74603dff6)

## GitHub

### Projects

Binnen het project hebben wij vier borden:

1. Bugs en Hotfixes
2. Taken (taken vanuit stories)
3. Documentatie en Workflow
4. Features (stories)

Elk issue wordt gekoppeld aan het projectbord waar het bij hoort. Op het moment dat iemand ergens mee bezig is, wordt de issue naar _Doing_ gezet, zodat iedereen weet wie waar mee bezig is.

### Templates

Om alles consistent en duidelijk te houden, zijn er templates gemaakt voor de [issues](https://github.com/iSirThijs/jungle-gym/tree/development/.github/ISSUE_TEMPLATE) en [pull request](https://github.com/iSirThijs/jungle-gym/blob/development/.github/PULL_REQUEST_TEMPLATE.md). Hierdoor hoef je niet meer na te denken over wat er precies in een pull request moet komen, maar staat dit er al automatisch.

Daarnaast worden er automatisch deploy previews door Netlify gemaakt. Hierdoor heeft elk pull request haar eigen deploy preview. De reviewer kan hierdoor snel zien wat er is aangepast en hier feedback over geven.

### Issues

Er worden issues gemaakt voor zowel de stories, als de taken die daarbij horen. Wij maken gebruik van labels, waardoor het duidelijk is wat voor soort issue het is.&#x20;

Door alles via Issues te doen, is het mogelijk om het in het projectbord te gooien, zodat iedereen elkaars voortgang ziet.

### Actions

GitHub Actions is een manier om code te controleren. Zelf hebben wij drie workflows: een voor alle branches, een voor `development` en een voor `main` .

Wat zij in feite alle drie doen, is een `npm run lint` en checken hierdoor of de code overeen komt met onze[ code style.](https://github.com/iSirThijs/jungle-gym/blob/development/.eslintrc.cjs) Is dit het geval, dan kan een PR gemerged worden. Anders niet. Door dit te doen, blijft onze code consistent.

In de workflow op `development` en `main` wordt dit ook gedaan, maar wordt er ook nog gecheckt of de app werkt op Node 12, 14 en 16. In onze `.nvmrc` staat `lts/fermium` wat dus betekent dat ons project op Node 14 draait. Om deze reden is het wellicht overbodig om dit nog extra te checken, maar het kan nooit kwaad.
