mirror of
https://github.com/conventional-commits/conventionalcommits.org.git
synced 2024-11-15 02:45:15 +01:00
feat(lang): add Dutch translation
This commit is contained in:
Kay Beudeker
GitHub
parent
f02224332d
commit
7378866e83
17
config.yaml
17
config.yaml
@ -346,3 +346,20 @@ languages:
|
|||||||
current: v1.0.0
|
current: v1.0.0
|
||||||
list:
|
list:
|
||||||
- v1.0.0
|
- v1.0.0
|
||||||
|
|
||||||
|
nl:
|
||||||
|
weight: 19
|
||||||
|
languageName: "Nederlands"
|
||||||
|
title: Conventionele Commits
|
||||||
|
description: Een specificatie voor mens- en machine-leesbare commit berichten
|
||||||
|
actions:
|
||||||
|
- label: Samenvatting
|
||||||
|
url: '#samenvatting'
|
||||||
|
- label: Specificatie
|
||||||
|
url: '#specificatie'
|
||||||
|
- label: GitHub
|
||||||
|
url: 'https://github.com/conventional-commits/conventionalcommits.org'
|
||||||
|
versions:
|
||||||
|
current: v1.0.0
|
||||||
|
list:
|
||||||
|
- v1.0.0
|
||||||
|
|||||||
241
content/v1.0.0/index.nl.md
Normal file
241
content/v1.0.0/index.nl.md
Normal file
@ -0,0 +1,241 @@
|
|||||||
|
---
|
||||||
|
draft: false
|
||||||
|
aliases: ["/nl/"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Conventionele Commits 1.0.0
|
||||||
|
|
||||||
|
## Samenvatting
|
||||||
|
|
||||||
|
De Conventionele Commits-specificatie is een eenvoudige conventie gebaseerd op commit-berichten.
|
||||||
|
Het biedt een eenvoudige set regels voor het maken van een gestructureerde commit-geschiedenis;
|
||||||
|
waardoor het gemakkelijker wordt om er geautomatiseerde tools op te baseren.
|
||||||
|
Deze conventie sluit naadloos aan bij [SemVer](http://semver.org)
|
||||||
|
door nieuwe functies, correcties en wijzigingen in commit-berichten te beschrijven.
|
||||||
|
|
||||||
|
Het commit-bericht moet als volgt zijn gestructureerd:
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
```
|
||||||
|
<type>[optioneel domein]: <omschrijving>
|
||||||
|
|
||||||
|
[optioneel uitgebreide omschrijving]
|
||||||
|
|
||||||
|
[optioneel voettekst(en)]
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<br />
|
||||||
|
Het commit-bericht bevat de volgende structurele elementen om de uitwerking te communiceren met de
|
||||||
|
gebruikers van de applicatie/bibliotheek:
|
||||||
|
|
||||||
|
1. **fix:** een commit met _type_ `fix` patcht een bug in de codebase (dit correleert
|
||||||
|
met [`PATCH`](http://semver.org/#summary) in Semantic Versioning).
|
||||||
|
2. **feat:** een commit met _type_ `feat` introduceert een nieuwe functie in de codebase (dit correleert
|
||||||
|
met [`MINOR`](http://semver.org/#summary) in Semantic Versioning).
|
||||||
|
3. **BREAKING CHANGE:** een commit met de voettekst `BREAKING CHANGE:`, of met een `!` direct na type/domein,
|
||||||
|
introduceert een brekende API-wijziging (correlerend met [`MAJOR`](http://semver.org/#summary) in Semantic
|
||||||
|
Versioning).
|
||||||
|
Een BREAKING CHANGE kan altijd onderdeel van een commit-bericht, ongeacht het _type_.
|
||||||
|
4. _typen_ anders dan `fix:` en `feat:` zijn toegestaan. Zo
|
||||||
|
adviseert [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional)
|
||||||
|
(gebaseerd op
|
||||||
|
de [de Angular-conventie](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines))
|
||||||
|
het gebruik van `build:`, `chore: `,
|
||||||
|
`ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:` en meer.
|
||||||
|
5. _voettekst(en)_ anders dan `BREAKING CHANGE: <omschrijving>` kunnen worden toegepast volgens een conventie
|
||||||
|
vergelijkbaar met die van
|
||||||
|
[git trailer format](https://git-scm.com/docs/git-interpret-trailers).
|
||||||
|
|
||||||
|
Additionele typen zijn niet verplicht volgens de Conventionele Commits-specificatie en hebben geen direct effect in
|
||||||
|
Semantic Versioning (tenzij ze een BREAKING CHANGE bevatten).
|
||||||
|
<br /><br />
|
||||||
|
Een domein kan worden meegegeven aan het _type_ van een commit om aanvullende contextuele informatie te verschaffen en
|
||||||
|
dient, direct achter het _type_ en tussen haakjes, geplaatst te worden,
|
||||||
|
bijv. `feat(parser): add ability to parse arrays`.
|
||||||
|
|
||||||
|
## Voorbeelden
|
||||||
|
|
||||||
|
### Commit-bericht met omschrijving en BREAKING CHANGE als voettekst
|
||||||
|
|
||||||
|
```
|
||||||
|
feat: allow provided config object to extend other configs
|
||||||
|
|
||||||
|
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
|
||||||
|
```
|
||||||
|
|
||||||
|
### Commit-bericht met `!` om een breaking change uit te lichten
|
||||||
|
|
||||||
|
```
|
||||||
|
feat!: send an email to the customer when a product is shipped
|
||||||
|
```
|
||||||
|
|
||||||
|
### Commit-bericht inclusief domein en een `!` om een breaking change uit te lichten
|
||||||
|
|
||||||
|
```
|
||||||
|
feat(api)!: send an email to the customer when a product is shipped
|
||||||
|
```
|
||||||
|
|
||||||
|
### Commit-bericht met zowel een `!` als BREAKING CHANGE in de voettekst
|
||||||
|
|
||||||
|
```
|
||||||
|
chore!: drop support for Node 6
|
||||||
|
|
||||||
|
BREAKING CHANGE: use JavaScript features not available in Node 6.
|
||||||
|
```
|
||||||
|
|
||||||
|
### Commit-bericht zonder uitgebreide omschrijving
|
||||||
|
|
||||||
|
```
|
||||||
|
docs: correct spelling of CHANGELOG
|
||||||
|
```
|
||||||
|
|
||||||
|
### Commit-bericht inclusief domein
|
||||||
|
|
||||||
|
```
|
||||||
|
feat(lang): add Polish language
|
||||||
|
```
|
||||||
|
|
||||||
|
### Commit-bericht met meerdere paragrafen in de uitgebreide omschrijving en meerdere voetteksten
|
||||||
|
|
||||||
|
```
|
||||||
|
fix: prevent racing of requests
|
||||||
|
|
||||||
|
Introduce a request id and a reference to latest request. Dismiss
|
||||||
|
incoming responses other than from latest request.
|
||||||
|
|
||||||
|
Remove timeouts which were used to mitigate the racing issue but are
|
||||||
|
obsolete now.
|
||||||
|
|
||||||
|
Reviewed-by: Z
|
||||||
|
Refs: #123
|
||||||
|
```
|
||||||
|
|
||||||
|
## Specificatie
|
||||||
|
|
||||||
|
De woorden "MOET", "MOGEN NIET", "VEREIST", "ZAL", "ZAL NIET", "ZOU", "ZOU NIET", "AANBEVOLEN", "MAG" en "OPTIONEEL" in
|
||||||
|
dit document zijn te interpreteren zoals beschreven in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||||
|
|
||||||
|
1. Een commit-bericht MOET starten met het type, dat bestaat uit een zelfstandig naamwoord, `feat`, `fix`, enz., gevolgd
|
||||||
|
door een OPTIONEEL domein, OPTIONEEL `!` en VEREIST een dubbele punt en spatie.
|
||||||
|
2. Het type `feat` MOET gebruikt worden wanneer een commit een nieuwe functie toevoegt aan de applicatie/bibliotheek.
|
||||||
|
3. Het type `fix` MOET worden gebruikt wanneer een commit een bugfix in de codebase vertegenwoordigt.
|
||||||
|
4. Een domein MAG na een type worden opgegeven. Een domein MOET bestaan uit een zelfstandig naamwoord dat een
|
||||||
|
gedeelte van de codebase, omgeven door haakjes, bijv. `fix(parser):` omvat.
|
||||||
|
5. Een omschrijving MOET opgegeven worden direct na de dubbele punt + spatie na het type/domein.
|
||||||
|
De omschrijving is een korte samenvatting van de wijzigingen, bijv. _fix: array parsing issue when multiple spaces
|
||||||
|
were contained in string_.
|
||||||
|
6. Een uitgebreide omschrijving MAG worden opgegeven voor aanvullende contextuele informatie over de wijzigingen. De
|
||||||
|
uitgebreide omschrijving MOET één lege regel laten tussen de regel met het type/domein en de (korte) omschrijving.
|
||||||
|
7. De uitgbreide omschrijving is een veld dat MAG bestaan uit een willekeurig aantal, door lege regels gescheiden,
|
||||||
|
alinea's.
|
||||||
|
8. Een voettekst (meedere toegestaan) MAG, na één lege regel achter de uitgebreide omschrijving, worden opgegeven. Elke
|
||||||
|
voettekst MOET bestaan uit
|
||||||
|
een kenmerk, gevolgd door `:<spatie>` of `<spatie>#`, gevolgd door een tekenreeks (dit is geïnspireerd op de
|
||||||
|
[git trailer-convention](https://git-scm.com/docs/git-interpret-trailers)).
|
||||||
|
9. Een kenmerk van een voettekst MOET `-` gebruiken in plaats van spatie, bijv. `Acked-by` (dit helpt bij het
|
||||||
|
onderscheiden
|
||||||
|
het voettekstgedeelte en een uitgebreide omschrijving met meerdere alinea's). Een uitzondering wordt gemaakt
|
||||||
|
voor `BREAKING CHANGE`, dat ook als kenmerk MAG worden gebruikt.
|
||||||
|
10. De tekenreeks van een voettekst MAG spaties en nieuwe regels bevatten en d.m.v. parsing MOET de volgende geldige
|
||||||
|
voettekst (kenmerk/tekenrekens combinatie) worden waargenomen.
|
||||||
|
11. Brekende wijzigingen MOETEN worden opgegeven in het type/domein-voorvoegsel van een commit-bericht of als een
|
||||||
|
geldige regel in de voettekst.
|
||||||
|
12. Indien opgegeven in de voettekst, MOET een brekende wijziging bestaan uit de tekst BREAKING CHANGE in hoofdletters,
|
||||||
|
gevolgd door een dubbele punt, spatie en een omschrijving, bijv.
|
||||||
|
_BREAKING CHANGE: environment variables now take precedence over config files_.
|
||||||
|
13. Indien opgegeven in het type/domein-voorvoegsel, MOET een brekende wijziging worden aangegeven met een `!` direct
|
||||||
|
voor de `:`. Als `!` wordt gebruikt, MAG `BREAKING CHANGE:` worden weggelaten uit het voettekstgedeelte
|
||||||
|
en de uigebreide omschrijving MOET worden gebruikt om de brekende wijziging te beschrijven.
|
||||||
|
14. Een ander type dan `feat` of `fix` MAG worden gebruikt in het commit-bericht, bijv. _docs: updated ref docs._
|
||||||
|
15. De elementen waaruit Conventionele Commits is opgebouwd, MOGEN NIET worden beschouwd als hoofdlettergevoelig,
|
||||||
|
met uitzondering van BREAKING CHANGE, dat in hoofdletters geschreven MOET worden.
|
||||||
|
16. BREAKING-CHANGE MOET een synoniem zijn voor BREAKING CHANGE wanneer gebruikt als een kenmerk in een voettekst.
|
||||||
|
|
||||||
|
## Waarom Conventionele Commits gebruiken
|
||||||
|
|
||||||
|
* Automatisch CHANGELOG's genereren.
|
||||||
|
* Automatisch bepalen van een semantic version bump (gebaseerd op typen van commits).
|
||||||
|
* Communiceren van veranderingen aan collega's, het publiek en andere belanghebbenden.
|
||||||
|
* Activeren van build- en publish-processen.
|
||||||
|
* Het voor andere mensen gemakkelijker maken om bij te dragen aan projecten d.m.v. inzage in een gestructureerdere
|
||||||
|
commit-geschiedenis.
|
||||||
|
|
||||||
|
## Veel gestelde vragen
|
||||||
|
|
||||||
|
### Hoe moet ik omgaan met commit-berichten in de initiële ontwikkelingsfase?
|
||||||
|
|
||||||
|
We raden aan te werk te gaan alsof het product al is uitgebracht. Doorgaans gebruikt *iemand*, al zijn het slechts
|
||||||
|
collega's, de software al. Zij willen weten wat er is aangepast, wat (nog) niet werkt, enz.
|
||||||
|
|
||||||
|
### Zijn de typen in de titel van een commit-bericht hoofdletters of kleine letters?
|
||||||
|
|
||||||
|
Elke vorm kan worden gebruikt, al het is verstandig om hier consistent in te zijn.
|
||||||
|
|
||||||
|
### Wat moet ik doen als een commit valt onder meer dan een van de commit-typen?
|
||||||
|
|
||||||
|
Ga terug en maak waar mogelijk meerdere commits. Het voordeel van het gebruik van Conventionele Commits is het vermogen
|
||||||
|
om ons ertoe aan te zetten meer georganiseerde commits en PR's te maken.
|
||||||
|
|
||||||
|
### Ontmoedigt dit snelle ontwikkeling en snelle iteratie niet?
|
||||||
|
|
||||||
|
Het ontmoedigt snel te ontwikkelen op een ongeorganiseerde manier. Het helpt juist om op lange termijn snel over
|
||||||
|
meerdere
|
||||||
|
projecten, met verschillende bijdragers, te ontwikkelen.
|
||||||
|
|
||||||
|
### Kunnen Conventionele Commits ertoe kunnen leiden dat ontwikkelaars beperkte type commits maken omdat ze zullen denken in de beschikbare typen?
|
||||||
|
|
||||||
|
Conventionele Commits moedigt aan om meer van bepaalde typen commits te maken, zoals fixes. Afgezien daarvan stelt
|
||||||
|
de flexibiliteit van Conventionele Commits een team in staat om eigen typen te bedenken en deze in de loop van de tijd
|
||||||
|
te veranderen.
|
||||||
|
|
||||||
|
### Hoe verhoudt dit zich tot SemVer?
|
||||||
|
|
||||||
|
Commits van het type `fix` moeten worden vertaald naar `PATCH`-releases. Commits van het type `feat` moeten worden
|
||||||
|
vertaald naar releases van het type `MINOR`. Commits met `BREAKING CHANGE` in het commit-bericht, ongeacht het type,
|
||||||
|
moeten worden
|
||||||
|
vertaald naar `MAJOR`-releases.
|
||||||
|
|
||||||
|
### Hoe moet ik mijn extensies aanpassen aan de Conventionele Commits-specificatie, bijv. `@jameswomack/conventional-commit-spec`?
|
||||||
|
|
||||||
|
We raden aan om SemVer te gebruiken om eigen extensies voor deze specificatie uit te brengen (en
|
||||||
|
moedigen je aan om deze extensies te maken!)
|
||||||
|
|
||||||
|
### Wat moet ik doen als ik per ongeluk het verkeerde type commit gebruik?
|
||||||
|
|
||||||
|
#### Als je een type hebt gebruikt dat voldoet aan de specificaties, maar niet het juiste type, bijv. `fix` in plaats van `feat`
|
||||||
|
|
||||||
|
Voor het mergen of openbaar maken van deze foutieve commit, raden we aan om `git rebase -i` te gebruiken om de
|
||||||
|
commit-geschiedenis te bewerken.
|
||||||
|
|
||||||
|
#### Wanneer je een type gebruikt hebt dat *niet* tot de specificatie behoort, bijv. `feet` in plaats van `feat`
|
||||||
|
|
||||||
|
Het is niet het einde van de wereld als een commit niet volledig voldoet aan de Conventionele Commit-specificatie.
|
||||||
|
Dit kan echter wel betekenen dat commits worden gemist door (automatische) tools die zijn gebaseerd op de specificatie.
|
||||||
|
|
||||||
|
### Moeten al mijn bijdragers de Conventionele Commit-specificatie gebruiken?
|
||||||
|
|
||||||
|
Nee! Als je een op squash gebaseerde workflow van git gebruikt, kunnen maintainers de commit-berichten opschonen
|
||||||
|
wanneer ze deze mergen. Dit vereist geen aanpassing en/of extra werk van bijdragers.
|
||||||
|
Een veelgebruikte workflow hiervoor is om het git-systeem automatisch commits te laten squashen bij een pull request en
|
||||||
|
de maintainers een formulier te bieden om het gewenste commit-bericht op te geven om zo de merge te beschrijven.
|
||||||
|
|
||||||
|
### Hoe gaat de Conventionele Commits-specificatie om met teruggedraaide commits?
|
||||||
|
|
||||||
|
Het terugdraaien van code kan ingewikkeld zijn: draai je meerdere commits terug? Als je een feature terugdraait, moet de
|
||||||
|
volgende release dan een patch zijn?
|
||||||
|
|
||||||
|
De Conventionele Commits-specificatie heeft geen vaste regels m.b.t. het terugdaaien van commits. In plaats daarvan
|
||||||
|
laten we tooling auteurs vrij om de flexibiliteit van _typen_ en _voettekst(en)_ te gebruiken om eigen regels te ontwikkelen m.b.t. het
|
||||||
|
terugdraaien van commits.
|
||||||
|
|
||||||
|
Een aanbeveling is om het `revert`-type te gebruiken i.c.m. een voettekst die verwijst naar de commit SHA's die worden
|
||||||
|
teruggedraaid:
|
||||||
|
|
||||||
|
```
|
||||||
|
revert: let us never again speak of the noodle incident
|
||||||
|
|
||||||
|
Refs: 676104e, a215868
|
||||||
|
```
|
||||||
Loading…
Reference in New Issue
Block a user