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. Enkele voorbeelden:

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

Stijlregels voor Commit Berichten

Voor onze commit berichten volgen we deze stijlregels:

• 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 of 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.
• Body (optioneel): Voeg een lege regel toe en beschrijf in detail wat je hebt aangepast als je meer uitleg nodig hebt.
• Ticketreferenties: Verwijs naar relevante tickets in Azure DevOps door het ticketnummer op te nemen, bijvoorbeeld: feat: verbeter login validatie (#1234).

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(auth): voeg wachtwoord reset functionaliteit toe, fix(ui): 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. Gestroomde Release Flow

Na de merge van je pull-request voer je de volgende commando's uit om een gestroomde release flow te waarborgen:

1. Versie vrijgave uitvoeren:
   Voer het volgende commando uit om een nieuwe versie vrij te geven:

   npx nx run tools:release

   Hiermee wordt de versie geüpdatet en worden changelogs genereerd volgens de conventies van Conventional Commits.

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.