Aan de slag

Werken met Pull-Requests en Commits op dcr-components

Als developer binnen ons team is het belangrijk dat je de juiste conventies en workflows volgt bij het maken van pull-requests (PR's) en commits. Hier volgt een uitgebreide uitleg over hoe je dit doet op ons platform voor dcr-components, waarbij we conventionele commits gebruiken en onze Git-repository hosten op Azure DevOps.

1. Gebruik van Conventional Commits

We werken met Conventional Commits voor al onze commit-berichten. Dit zorgt voor consistentie en helpt bij het automatisch genereren van changelogs.

De basis voor een Conventional Commit

Een Conventional Commit bestaat uit 3 of 4 delen en moet voldoen aan de volgende regels:

Basis Conventional Commit: type(scope): {entiteit} bericht

1. Type:

   • feat: Een nieuw component of nieuwe functionaliteit
   • fix: Een probleem is opgelost
   • docs: Documentatie is toegevoegd of aangepast
   • style: De stijl van een component is aangepast
   • refactor: De code is herwerkt
   • perf: Performantie aanpassingen zijn gemaakt
   • test: Testen zijn toegevoegd of aangepast
   • build Project bouwprocess is aangepast

2. Scope:

   • De scope geeft aan welk NX project is betrokken. Je kan de NX projecten bekijken door het commando nx show projects te gebruiken.
   • Bijvoorbeeld: dcr-components, cds-docs, cds-tokens

3. Entiteit (optioneel):

   • De betrokken entiteit geeft aan welk component of bestand is betrokken.
   • Bijvoorbeeld: {dcr-card}, {dcr-icon-service}, {storybook}

4. Bericht:

   • Een korte samenvatting van de wijziging volgens de afgesproken stijlregels.

Enkele voorbeelden:

• feat(dcr-components): {dcr-card} voeg nieuwe knop toe voor gebruikersinteractie
• fix(dcr-components): {dcr-icon-service} los bug op bij het laden van de data
• docs(cds-docs): {storybook} update README met installatie instructies
• style(dcr-components): {dcr-divider} pas opmaak aan in component CSS

Stijlregels voor Commit Berichten

Voor onze commit berichten volgen we deze stijlregels:

• Voorzie een scope: Voeg het NX project toe als de scope van de conventional commit.

  • ✅ Goed: feat(dcr-components): {dcr-button} voeg de dcr-button toe
  • ❌ Fout: feat(dcr-button): {dcr-button} voeg de dcr-button toe
  • ❌ Fout: feat(): {dcr-button} voeg de dcr-button toe

• Voorzie een entiteit wanneer verwacht: Voeg het entiteit toe wanneer nodig.

  • ✅ Goed: feat(dcr-components): {dcr-button} voeg de dcr-button toe
  • ✅ Goed: docs(cds-docs): {storybook} voeg documentatie toe voor storybook
  • ❌ Fout: feat(dcr-components): voeg de dcr-button toe

• Gebruik imperatieve tegenwoordige tijd: Schrijf je commit berichten alsof je een commando of instructie geeft.

  • ✅ Goed: fix: los probleem op met navigatie
  • ❌ Fout: fix: probleem met navigatie opgelost
  • ❌ Fout: fix: lost probleem op met navigatie

• Begin met een werkwoord: Start je beschrijving met een actiewerkwoord.

  • ✅ Goed: feat: voeg dark mode toe
  • ❌ Fout: feat: dark mode toevoeging

• Wees specifiek maar beknopt: Geef voldoende context zonder te lang te worden.

  • ✅ Goed: fix: voorkom crash bij het sluiten van venster
  • ❌ Fout: fix: bug

• Gebruik geen punt aan het einde: Eindig je commit beschrijving niet met een punt.

  • ✅ Goed: docs: update installatie instructies
  • ❌ Fout: docs: update installatie instructies.

Commit Message Tips

• Korte en duidelijke samenvatting: Beperk de eerste regel van je commit tot maximaal 50 tekens.

• Beschrijving (optioneel): Beschrijf in detail wat je hebt aangepast als je meer uitleg nodig hebt. Markdown is hier voorzien en gebruik het volgende patroon:

  * Toegevoegde functionaliteiten:
    * Registreer logo's centraal voor consistente integratie
    * Extra toevoegen op het ticket (#1234) (!5161) met deze commit
    * Maak vierkante logo's op voor consistente weergave in de platformen.
    * ...

• Ticketreferenties: Verwijs naar relevante tickets in Azure DevOps door het ticketnummer op te nemen, bijvoorbeeld: feat: verbeter login validatie (#1234).

• Pull request referenties: Verwijs naar relevante pull requests in Azure DevOps door het pull request nummer op te nemen, bijvoorbeeld: feat: verbeter login validatie (!5161).

2. Werken met Branches en Pull-Requests

Nooit rechtstreeks op de main branch (develop)

We werken nooit rechtstreeks op de main branch (develop). Maak altijd een feature branch aan voor je werk. Dit houdt de ontwikkeling overzichtelijk en voorkomt potentiële conflicten.

Stappenplan voor het maken van een pull-request

1. Nieuwe branch aanmaken:
   Maak een nieuwe branch op basis van develop. Bijvoorbeeld:

   git checkout develop
   git pull
   git checkout -b feature/jouw-onderwerp

2. Commit je wijzigingen:
   Niet elke commit in je werkstroom hoeft een conventional commit te zijn. Tijdens het ontwikkelen kun je tussentijdse commits maken met eenvoudige berichten. Zorg er echter voor dat de belangrijke mijlpalen en functionele wijzigingen gemarkeerd worden met conventional commits, zodat deze correct in de changelogs kunnen worden opgenomen.

   Bijvoorbeeld:

   • Tussentijdse commits: WIP: formulier validatie, Fix typo, Refactor code
   • Belangrijke commits die in changelogs moeten komen: feat(scope): {entity} voeg wachtwoord reset functionaliteit toe, fix(scope): {entity} los layout probleem op in mobiele weergave

   Bij het squashen of rebasen van je branch voor de PR, zorg ervoor dat de uiteindelijke commits die worden behouden de conventional commit standaard volgen.

3. Push je branch:
   Push je branch naar de remote repository:

   git push origin feature/jouw-onderwerp

4. Open een pull-request in Azure DevOps:
   Ga naar de Azure DevOps repo en open een nieuwe pull-request van je branch naar develop. Vergeet niet om:

   • Een duidelijke titel en beschrijving te geven.
   • IT tickets (bijvoorbeeld #1234) en gerelateerde PR's te refereren zodat ze automatisch worden mee gelinkt in de changelogs.

3. Release Flow

Na de merge van je pull-request kun je een release maken via het interactieve script:

./tools/src/release-branch.sh

Dit script:

1. Detecteert welke projecten wijzigingen hebben ten opzichte van hun release branch
2. Voert nx release uit voor de affected projects
3. Pusht de release commit en tags naar develop
4. Merged naar de corresponderende release branches

Alternatief: Direct Nx Release

Je kunt ook direct nx release aanroepen:

# Release voor specifieke projecten
npx nx release --projects=dcr-components

# Release voor alle affected projects
npx nx release

Automatische Version Bump

Nx Release bepaalt automatisch de versie op basis van je commits:

Commit Type	Version Bump	Changelog Sectie
feat	minor (1.2.3 → 1.3.0)	🚀 New Features
fix	patch (1.2.3 → 1.2.4)	🐛 Bug Fixes
docs	patch	📝 Documentation
style	patch	💅 Style Changes
refactor	patch	🔨 Refactoring
perf	patch	⚡ Performance Improvements
test	patch	✅ Tests
build	patch	🏗 Build Changes
ci	patch	🤖 Continuous Integration

Changelog Voorbeeld

De changelog wordt automatisch gegenereerd met emoji headers en Azure DevOps links:

## 0.27.4 (2026-01-21)

### 🚀 New Features

- **dcr-stepper**: voeg dcr-stepper component toe

### 🐛 Bug Fixes

- **dcr-split-button**: los een probleem op... ([#29439](https://dev.azure.com/...))

4. Verwijzen naar Tickets en PR's in Azure DevOps

Om ervoor te zorgen dat tickets en PR's gekoppeld worden in de changelogs, is het belangrijk dat je:

• In commit berichten: Het ticketnummer opneemt, bijvoorbeeld (#1234).
• In PR's: Vermeld dat de wijzigingen gerelateerd zijn aan een specifiek ticket door het ticketnummer in de beschrijving op te nemen.

Door deze referenties toe te voegen, worden deze automatisch gekoppeld in Azure DevOps en in de gegenereerde changelogs. Dit maakt het makkelijker om de geschiedenis van wijzigingen te traceren en te begrijpen welke implementaties of fixes aan welke tickets gerelateerd zijn.