Ga naar hoofdinhoud

🔀 Pull Requests

📌 Overzicht​

Pull Requests (PR's) zijn de kern van onze code‑reviewproces bij Brixion. Ze zorgen voor kwaliteitscontrole, kennisuitwisseling en transparantie in onze ontwikkelingsprocessen. Deze pagina beschrijft hoe je effectieve PR's opstelt die bijdragen aan de kwaliteit van onze codebase.

🏷️ PR Titel​

Gitmoji gebruiken​

We gebruiken gitmoji in onze PR titels om snel visueel te begrijpen wat voor type wijziging het betreft.

Goede voorbeelden:

  • ✨ Added email validation in user repository
  • 🐛 Fixed image orientation in upload service
  • 🔧 Changed configuration for Nuxt ESLint
  • ♻️ Refactored authentication middleware
  • 📝 Updated API documentation for user endpoints
  • 🔒 Secured API endpoints with rate limiting
  • 📦 Updated dependencies in package.json
  • 🔥 Removed unused functions in User Entity
  • 💄 Improved UI styling for dashboard components

Titel format​

Alle PR titels volgen het format: [GITMOJI] [ACTION] [WHAT] in/for [SUBJECT]

Acties:

  • Added - Nieuwe functionaliteit
  • Changed - Wijzigingen aan bestaande code
  • Fixed - Bug fixes
  • Removed - Verwijderde code
  • Updated - Updates aan bestaande features
  • Refactored - Code herstructurering
  • Improved - Verbeteringen

Voorbeelden van goede PR titels:

  • ✨ Added email validation in user repository
  • 🔧 Changed configuration for Nuxt ESLint
  • 🔥 Removed unused functions in User Entity
  • 🐛 Fixed image orientation in upload service

Voorbeelden van slechte PR titels:

  • ❌ Fix stuff (te vaag, geen gitmoji)
  • ❌ 🚧 WIP (work in progress hoort niet in main branch)
  • ❌ 🐛 Bug fix (welke bug?)
  • ❌ ✨ New feature (welke feature?)
  • ❌ 🚧 Test (wat wordt er getest?)
  • ❌ 🧹 Cleanup code (wat wordt er opgeruimd?)
  • ❌ 🚑 Temporary fix (waarom tijdelijk?)
  • ❌ 🚑 Quick fix (suggereert haastwerk)

Taal​

PR titels worden altijd in het Engels geschreven omdat ze na het squashen de commit message worden in de main branch. Dit zorgt voor consistente en professionele commitgeschiedenis.

📝 PR Beschrijving​

Doel​

De PR beschrijving heeft als doel om:

  • Snel terug te kunnen lezen wat er is aangepast
  • De aanleiding van de wijziging te begrijpen
  • Te begrijpen waarom het is aangepast
  • Te zien wat er daadwerkelijk is opgelost

Taal en structuur​

PR beschrijvingen worden in het Nederlands geschreven en volgen onze standaard template.

Template richtlijnen​

  • Wees kort en duidelijk
  • Het Eerste kopje is altijd "🔍 Samenvatting" en de eerste zin begint altijd met de woorden "Deze PR ...". Schrijf in maximaal 3 zinnen wat het doel is van deze PR.
  • Begin al je subkopjes met een passende emoji.
  • Haal de kopjes weg die niet relevant zijn in deze PR
  • Gebruik backticks (`) voor het benoemen van bestandsnamen, code‑verwijzingen, enz.
  • Schrijf je PR bij voorkeur zelf zodat het voor jezelf helder is wat je gedaan hebt en of het klopt
  • Markeer je PR als Draft als deze nog niet klaar is voor review en vermijd "WIP" in titels.
  • Link issues die je oplost met bijvoorbeeld Closes #123.
  • Voeg screenshots of screen recordings toe voor UI‑wijzigingen.

Voorbeeld template​

## 🔍 Samenvatting

Deze PR ...

## 📝 Beschrijving

-
-
-

## 🧪 Testinstructies (optioneel)

1.
2.
3.

## 📌 Openstaande punten (optioneel)

- [ ]

## 💬 Extra informatie

## ✅ Checklist

- [ ] Code is lokaal getest
- [ ] Tests zijn toegevoegd/aangepast
- [ ] Documentatie bijgewerkt (indien nodig)

📏 Regels & richtlijnen​

Stelregels​

  • Alleen de auteur merged de PR (na goedkeuring).
  • Voor kleine PR's: stel auto-merge in om het proces te versnellen.
  • Loop alle CodeRabbit-opmerkingen langs (ook nitpicks) en los op of motiveer.

Focus per PR​

Een PR bevat altijd maar één wijziging. Combineer nooit meerdere aanpassingen in één PR. Dit voorkomt onduidelijkheid en maakt het reviewproces overzichtelijker. De verleiding is soms groot om dingen samen te voegen voor de snelheid, maar leer jezelf aan om de tijd te nemen voor een goede, gefocuste PR. Zelfs als je wijziging maar 1 regel code is.

PR‑grootte​

  • Kleine PR's: 1-200 regels wijziging
  • Middelgrote PR's: 200-500 regels wijziging
  • Grote PR's: >500 regels (overweeg opsplitsing)

Heb je een PR met meer dan 1000 gewijzigde regels? Dat is te groot om goed te reviewen. Doe dit alleen als het echt niet anders kan, bijvoorbeeld bij:

  • Grote refactor
  • Automatische codegeneratie (bijv. .lock‑files)
  • Code style of lint aanpassingen

Overleg altijd vooraf met je team. Iedereen moet akkoord zijn.

Zorg voor een duidelijke uitleg: wat is er veranderd, waarom zo groot, waar moet op gelet worden? Voeg een korte "Changes overview" met bullets toe en geef aan welke onderdelen prioriteit hebben voor review.

Neem ruim de tijd voor de review. Je team moet zich prettig voelen bij zo'n grote wijziging.

📄 PR Templates​

Organization-wide templates​

Alle repositories in onze organisatie gebruiken standaard PR templates die centraal beheerd worden in de brixion/.github repository.

Locatie: .github/PULL_REQUEST_TEMPLATE/

Templates aanpassen​

Wil je een bestaande template wijzigen of een nieuwe template toevoegen?

  1. Ga naar de brixion/.github repository
  2. Navigeer naar de .github/PULL_REQUEST_TEMPLATE/ map
  3. Maak een PR aan met je wijzigingen
  4. Na merge worden de templates automatisch beschikbaar in alle repositories

Nieuwe templates toevoegen​

Heb je behoefte aan een specifieke template voor een bepaald type PR? Voeg deze toe aan de organization-wide repository zodat alle teams er gebruik van kunnen maken.

✅ Voordelen​

Kwaliteitscontrole​

Elke wijziging wordt door minimaal één collega beoordeeld op functionaliteit, leesbaarheid, veiligheid en performance. Dit verkleint de kans op regressies en verhoogt de betrouwbaarheid van onze software in productie.

Kennisuitwisseling​

Reviews zorgen voor kruisbestuiving tussen teamleden. Door elkaars code te lezen ontstaan gedeelde inzichten over domeinlogica, architectuurkeuzes en best practices, waardoor busfactor wordt verlaagd en het team als geheel groeit.

Transparantie en traceerbaarheid​

PR's vormen een helder audit trail van wie wat heeft veranderd, waarom en wanneer. Dit maakt het makkelijker om beslissingen te herleiden, incidenten te onderzoeken en compliance-eisen te ondersteunen.

Betere documentatie van wijzigingen​

Een goede PR-beschrijving legt context vast (aanleiding, aanpak, impact). Dit fungeert als levend naslagwerk voor toekomstige wijzigingen, onboarding van nieuwe collega's en het snel begrijpen van historische keuzes.

Samenwerking en alignment​

Discussies in PR's helpen om vroegtijdig feedback te verzamelen, alternatieven te overwegen en consensus te bereiken. Dit leidt tot consistentere implementaties en voorkomt dure herwerkingen later in het proces.

Snellere feedbackloop​

Door kleine, gefocuste PR's te maken en auto-merge voor kleine wijzigingen te gebruiken, verkorten we de doorlooptijd van idee naar productie en houden we momentum in het team hoog.

Verbeterde testdekking en kwaliteit​

Het reviewproces stimuleert het toevoegen of verbeteren van tests en het naleven van onze kwaliteitsstandaarden (linting, typechecks, security). Hierdoor stijgt de algehele codekwaliteit.