## 1. Project Overview & Quickstart (conventional-changelog/commitlint)

## File: @alias/commitlint-config-patternplate/README.md

# commitlint-config-patternplate

> Alias of [@commitlint/config-patternplate](https://www.npmjs.com/package/@commitlint/config-patternplate)

---

## File: @alias/commitlint-config-nx-scopes/README.md

# commitlint-config-nx-scopes

> Alias of [@commitlint/config-nx-scopes](https://www.npmjs.com/package/@commitlint/config-nx-scopes)

---

## File: @alias/commitlint-config-lerna-scopes/README.md

# commitlint-config-lerna-scopes

> Alias of [@commitlint/config-lerna-scopes](https://www.npmjs.com/package/@commitlint/config-lerna-scopes)

---

## File: @alias/commitlint-config-angular/README.md

# commitlint-config-angular

> Alias of [@commitlint/config-angular](https://www.npmjs.com/package/@commitlint/config-angular)

---

## File: @alias/commitlint/README.md

# commitlint

> Alias of [@commitlint/cli](https://www.npmjs.com/package/@commitlint/cli)

---

## File: @commitlint/travis-cli/README.md

> Lint all relevant commits for a change or PR on Travis CI

# @commitlint/travis-cli

This package is a convenience wrapper around `commitlint`,
providing zero-configuration linting of all relevant commits
for a given change/build combination.

## Getting started

```
npm install --save-dev @commitlint/travis-cli
```

```yml
# .travis.yml
script
- commitlint-travis
```

---

## File: @commitlint/read/README.md

# @commitlint/read

Read commit messages from a specified range or last edit

## Getting started

```shell
npm install --save @commitlint/read
```

## Documentation

Consult [API docs](https://commitlint.js.org/api/read) for comprehensive documentation.

Documentation generated from [`docs` folder](../../docs/api/read.md).

---

## File: @commitlint/prompt-cli/README.md

# @commitlint/prompt-cli

commit prompt using commitlint.config.js

## Getting started

```sh
npm install -g @commitlint/prompt-cli @commitlint/config-angular
echo "export default {extends: ['@commitlint/config-angular']};" > commitlint.config.js
```

```sh
git add .
commit
```

A full usage guide is available at [docs/prompt](https://commitlint.js.org/guides/use-prompt).

---

## File: @commitlint/prompt/README.md

# @commitlint/prompt

commitizen adapter using commitlint.config.js

This is the library and commitizen adapter version of commitlint prompt.
A ready-to-use cli version is available at [@commitlint/prompt-cli](../prompt-cli).
Learn how to use it in this [guide](https://commitlint.js.org/guides/use-prompt).

## Getting started

```bash
npm install --save-dev @commitlint/prompt @commitlint/config-conventional commitizen
echo "module.exports = {extends: ['@commitlint/config-conventional']};" > commitlint.config.js
```

In package.json

```
{
  "scripts": {
    "commit": "git-cz"
  },
  "config": {
    "commitizen": {
      "path": "@commitlint/prompt"
    }
  }
}
```

```bash
git add .
npm run commit
```

---

## File: @commitlint/parse/README.md

> Parse commit messages to structured data

# @commitlint/parse

## Install

```
npm install --save @commitlint/parse
```

## Use

```js
const parse = require("@commitlint/parse");
```

## API

### parse(message: string, parser: Function, parserOpts: Object)

- **message**: Commit message to parser
- **parser**: Sync parser function to use. Defaults to `sync` of `conventional-commits-parser`
- **parserOpts**: Options to pass to `parser`
  ```
  {
    commentChar: null, // character indicating comment lines
    issuePrefixes: ['#'] // prefix characters for issue references
  }
  ```

---

## File: @commitlint/load/README.md

# @commitlint/load

Load shared commitlint configuration

## Getting started

```shell
npm install --save-dev @commitlint/load
```

## Documentation

Consult [API docs](https://commitlint.js.org/api/load) for comprehensive documentation.

Documentation generated from [`docs` folder](../../docs/api/format.md).

---

## File: @commitlint/lint/README.md

# @commitlint/lint

Lint a string against commitlint rules

## Getting started

```shell
npm install --save @commitlint/lint
```

## Documentation

Consult [API docs](https://commitlint.js.org/api/lint) for comprehensive documentation.

Documentation generated from [`docs` folder](../../docs/api/format.md).

## 2. Official Technical Reference & Guides (conventional-changelog/conventional-changelog.github.io)

## File: content/v1.0.0-beta/index.it.md

---
draft: false
---

# Commit Convenzionali 1.0.0-beta

## Riepilogo

Da maintainer di codice open source, devo poter scrivere messaggi standardizzati per i commit
ed eseguire lo squash dei feature branch nel `master`.

I messaggi dei commit dovrebbero seguire la seguente struttura:

---

```
<tipo>[contesto opzionale]: <descrizione>

[corpo opzionale]

[piè di pagina opzionale]
```
---


Il commit contiene i seguenti elementi strutturali, allo scopo di comunicarne
l'intento al consumatore della libreria:

1. **fix:** un commit di _tipo_ `fix` risolve un errore nel codice (correlato al [`PATCH`](http://semver.org/#summary) in un versionamento semver).
1. **feat:**  un commit di _tipo_ `feat` introduce una nuova funzionalità al codice (correlato al [`MINOR`](http://semver.org/#summary) in un versionamento semver).
1. **BREAKING CHANGE:** un commit che contiente il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`MAJOR`](http://semver.org/#summary) in un versionamento semver).
Una _breaking change_ può essere parte di entrambi i _tipi_ `fix:` w `feat:`.

Un _contesto_ potrebbe essere aggiunto al _tipo_ di commit, al fine di offrire ulteriori informazioni contestuali.
Da aggiungere tra delle parentesi tonde, Es: `feat(parser): add ability to parse arrays`.

Sono ammessi altri _tipi_ oltre `fix:` e `feat:`, ad esempio [la convenzione Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) raccomanda `docs:`, `style:`, `refactor:`, `perf:`, `test:`, `chore:`, ma questi non sono coperti da questa specifica.

## Introduzione

Nello sviluppo software, secondo la mia esperienza, gli errori sono spesso introdotti ai limiti tra le applicazioni.

I test unitari vanno benissimo per le interazioni che i mantenitori open source conoscono,
ma non fanno un ottimo lavoro nel catturare tutti i modi interessanti, spesso inaspettati, con i quali la comunità utilizza una libreria.

Solamente chi ha visto la propria applicazione restituire errori 500
dopo aver aggiornato una dipendenza ad una nuova versione patch,
sa quanto sia importante una cronologia di commit facilmente leggibile
(e nel migliore dei casi [un changlelog ben mantenuto](http://keepachangelog.com/en/0.3.0/))
per il processo di investigazione che dovrà affrontare.

La specifica per commit convenzionali propone l'introduzione di una convenzione
facilmente applicabile ai messaggi dei commit.
Questa convenzione legata al [SemVer](http://semver.org), chiede ai sviluppatori software
di descrivere nei messaggi dei commit qualsiasi feature, fix e breaking change loro abbiano fatto.

Introducendo questa convenzione, si crea un linguaggio comune che rende più semplice
rimuovere errori tra progetti.

## Specifica

Le parole “DEVE”, “NON DEVE”, “RICHIESTO”, “DOVRÀ”, “NON DOVRÀ”, “DOVREBBE”, “NON DOVREBBE”, “RACCOMANDATO”, “POTREBBE” e “OPZIONALE” devo essere interpretata come da specifica [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).

1. Un commit DEVE iniziare con un _tipo_, il quale consiste in un sostantivo, `feat`, `fix`, etc.,
   seguito dai due punti ed uno spazio.
1. Il _tipo_ `feat` DEVE essere usato quando un commit aggiunge una funzionalità
   all'applicazione o libreria.
1. Il _tipo_ `fix` DEVE essere usato quando un commit corregge un errore all'applicazione o libreria.
1. Un _contesto_ opzionale POTREBBE essere fornito dopo il _tipo_.
   Un _contesto_ rappresenta una sezione dell'applicazione o libreria, il contentuo va racchiusa tra delle parentesi.
   Es: `fix(parser):`
1. Una _descrizione_ DEVE seguire immediatamente il _tipo_ (con eventuale _contesto_).
   Per _descrizione_ si intende una breve spiegazione della pull request.
   Es: _fix: array parsing issue when multiple spaces were contained in string._
1. Un _corpo_ del commit più lungo POTREBBE essere aggiunto dopo una breve _descrizione_.
   Il _corpo_ DEVE inizare dopo una linea vuota dalla _descrizione_.
1. Un _piè di pagina_ POTREBBE essere aggiunto inserendo una linea vuota dopo il _corpo_.
   Il _piè di pagina_ DOVREBBE contenere ulteriori informazioni riguardo la pull request (come le issue che risolve,
   Es: `fixes #13, #5`).
1. Una _breaking changes_ DEVE essere indicata all'inizio delle sezioni _piè di pagina_ o del _corpo_ del commit.
   Una _breaking change_ DEVE essere scritta in maiuscolo `BREAKING CHANGE`, seguita dai due punti ed uno spazio.
1. Una descrizione DEVE essere aggiunta dopo il testo `BREAKING CHANGE: `, descrivendo il cambiamento delle API.
   Es: _BREAKING CHANGE: environment variables now take precedence over config files._
1. Un commit POTREBBE utilizzare altri _tipi_ al di fuori di `feat` e `fix` nel messagio.

## Perchè utilizzare commit convenzionali

* CHANGELOG generati automaticamente.
* Determina automaticamente l'incremento di un versionamento semver (basandosi sui tipi di commit utilizzati).
* Comunica la natura dei cambiamenti a colleghi, pubblico, o altri parti interessate.
* Attiva build e processi di rilascio.
* Rendi più semplice alle persone contribuire al tuo progetto, dando la possibilità di espolrare una cronologia di commit più strutturata.

## FAQ

### Come dovrei comportarmi con i messaggi dei commit nella fase iniziale del progetto?

Raccomandiamo di procedere come se il tuo prodotto sia già stato rilasciato. Tipicamente *qualcuno*, anche i tuoi colleghi, stanno utilizzando il tuo software. Loro vorranno sapere cosa sia stato risolto, cosa si sia rotto etc.

### Cosa faccio se il tipo di commit è conforme a più di un tipo?

Torna indietro e dividi in più commit dove puoi.
Parte del beneficio di usare Commit Convenzionali è quello di spingerti a fare commit e pull request più organizzati.

### Non disincoraggia sviluppo ed iterazioni rapidi?

Disingoraggia farlo in una maniere disorgaizzata. Inoltre ti aiuterà a muoverti più velocemente su più progetti con diversi contributori.

### Potrebbe Commit Convenzionali limitare gli sviluppatori a fare solamente alcuni tipi commit perchè penseranno nei tipi forniti dalla specifica?

Commit Convenzionali ti incoraggia nel fare più di certi tipi di commit.
Inoltre la flessibilità di Commit Convenzionali consente al tuo team di inventare i propri tipi e cambiarli nel tempo.

### Come si collega a SemVer?

I commit di tipo `fix` dovrebbero essere traducibili ai rilasci `PATCH`.
I commit di tipo `feat` dovrebbero essere traducibili ai rilasci `MINOR`.
I commit con `BREAKING CHANGE`, indipentemente dal tipo, dovrebbero essere traducibili ai rilasci `MAJOR`.

### Come dovrei versionare le mie estensioni per la specifica Commit Convenzionali? (Es: `@jameswomack/conventional-commit-spec`)

Raccomandiamo l'utilizzo di SemVer per rilasciare la tua estensione (crea delle estensioni!)

### Cosa faccio se accidentalmente utilizzo un tipo di commit sbagliato?

#### Quando usi un tipo della specifica ma non quello giusto (Es: `fix` invece di `feat`)

Se ancora devi creare il merge o il rilascio dell'errore, raccomandiamo l'utilizzo di `git rebase -i` per riscrivere la cronologia dei commit.
Nel caso ti abbia già rilasciato questa correzzione dipende dai tool e processi che usi.

#### Quando usi un tipo *non* della specifica (Es: `feet` invece di `feat`)

Non è la fine del mondo se un commit non segue la specifica Commit Convenzionali.
Semplicemente il commit verrà ignorato dai tool che sono basati su questa specifica.

### Devono tutti i contributori seguire la specifica Commit Convenzionali?

No. Se usi un workflow basato sugli squash di Git, i mantenitori possono pulire i messaggi dei commit mentre vengono inseriti nel branch principale (merge), non aggiungendo alcun carico di lavoro ai committer occasionali.
Un workflow comune è quello di unire (con lo squash) automaticamente i commit dalle pull request e far utilizzare un form ai mantenitori per riscrivere un messaggio più adeguato.

---

## File: content/v1.0.0-beta/index.md

---
draft: false
---

# Conventional Commits 1.0.0-beta

## Summary

As an open-source maintainer, squash feature branches onto `master` and write
a standardized commit message while doing so.

The commit message should be structured as follows:

---

```
<type>[optional scope]: <description>

[optional body]

[optional footer]
```
---


The commit contains the following structural elements, to communicate intent to the
consumers of your library:

1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in semantic versioning).
1. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates
  with [`MINOR`](http://semver.org/#summary) in semantic versioning).
1. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) in semantic versioning). A breaking change can be
  part of either a `fix:` or `feat:` _type_ commit.


A scope may be provided to a commit's type, to provide additional contextual information and
is contained within parenthesis, e.g., `feat(parser): adds ability to parse arrays`.

Commit _types_ other than `fix:` and `feat:` are allowed, for example [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) recommends `docs:`, `style:`, `refactor:`, `perf:`, `test:`, `chore:`, but these tags are
not mandated by the conventional commits specification.

## Introduction

In software development, it's been my experience that bugs are most often introduced
at the boundaries between applications. Unit testing works great for testing the interactions
that an open-source maintainer knows about, but do a poor job of capturing all the
interesting, often unexpected, ways that a community puts a library to use.

Anyone who has upgraded to a new patch version of a dependency, only to watch their
application start throwing a steady stream of 500 errors, knows how important
a readable commit history (and [ideally a well maintained CHANGELOG](http://keepachangelog.com/en/0.3.0/)) is to the ensuing
forensic process.

The Conventional Commits specification proposes introducing a standardized lightweight
convention on top of commit messages. This convention dovetails with [SemVer](http://semver.org),
asking software developers to describe in commit messages, features, fixes, and breaking
changes that they make.

By introducing this convention, we create a common language that makes it easier to
debug issues across project boundaries.

## Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).

1. commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc.,
   followed by a colon and a space.
1. the type `feat` MUST be used when a commit adds a new feature to your application
  or library.
1. the type `fix` MUST be used when a commit represents a bug fix for your application.
1. an optional scope MAY be provided after a type. A scope is a phrase describing
  a section of the codebase enclosed in parenthesis, e.g., `fix(parser):`
1. A description MUST immediately follow the type/scope prefix.
  The description is a short description of the pull request, e.g.,
  _fix: array parsing issue when multiple spaces were contained in string._
1. A longer commit body MAY be provided after the short description. The body MUST
   begin one blank line after the description.
1. A footer MAY be provided one blank line after the body. The footer SHOULD contain
   additional meta-information about the pull-request (such as the issues it fixes, e.g., `fixes #13, #5`).
1. Breaking changes MUST be indicated at the very beginning of the footer or body section of a commit. A breaking change MUST consist of the uppercase text `BREAKING CHANGE`, followed by a colon and a space.
1. A description MUST be provided after the `BREAKING CHANGE: `, describing what
  has changed about the API, e.g., _BREAKING CHANGE: environment variables now take precedence over config files._
1. types other than `feat` and `fix` MAY be used in your commit messages.

## Why Use Conventional Commits

* Automatically generating CHANGELOGs.
* Automatically determining a semantic version bump (based on the types of commits landed).
* Communicating the nature of changes to teammates, the public, and other stakeholders.
* Triggering build and publish processes.
* Making it easier for people to contribute to your projects, by allowing them to explore
  a more structured commit history.

## FAQ

### How should I deal with commit messages in the initial development phase?

We recommend that you proceed as if you've an already released product. Typically *somebody*, even if its your fellow software developers, is using your software. They'll want to know what's fixed, what breaks etc.

### What do I do if the commit conforms to more than one of the commit types?

Go back and make multiple commits whenever possible. Part of the benefit of Conventional Commits is its ability to drive us to make more organized commits and PRs.

### Doesn’t this discourage rapid development and fast iteration?

It discourages moving fast in a disorganized way. It helps you be able to move fast long term across multiple projects with varied contributors.

### Might Conventional Commits lead developers to limit the type of commits they make because they'll be thinking in the types provided?

Conventional Commits encourages us to make more of certain types of commits such as fixes. Other than that, the flexibility of Conventional Commits allows your team to come up with their own types and change those types over time.

### How does this relate to SemVer?

`fix` type commits should be translated to `PATCH` releases. `feat` type commits should be translated to `MINOR` releases. Commits with `BREAKING CHANGE` in the commits, regardless of type, should be translated to `MAJOR` releases.

### How should I version my extensions to the Conventional Commits Specification, e.g. `@jameswomack/conventional-commit-spec`?

We recommend using SemVer to release your own extensions to this specification (and
encourage you to make these extensions!)

### What do I do if I accidentally use the wrong commit type?

#### When you used a type that's of the spec but not the correct type, e.g. `fix` instead of `feat`

Prior to merging or releasing the mistake, we recommend using `git rebase -i` to edit the commit history. After release, the cleanup will be different according to what tools and processes you use.

#### When you used a type *not* of the spec, e.g. `feet` instead of `feat`

In a worst case scenario, it's not the end of the world if a commit lands that does not meet the conventional commit specification. It simply means that commit will be missed by tools that are based on the spec.

### Do all my contributors need to use the conventional commit specification?

No! If you use a squash based workflow on Git lead maintainers can clean up the commit messages as they're merged—adding no workload to casual committers. A common workflow for this is to have your git system automatically squash commits from a pull request and present a form for the lead maintainer to enter the proper git commit message for the merge.

---

## File: content/v1.0.0-beta/index.pl.md

---
draft: false
---

# Konwencjonalne Commity 1.0.0-beta

## Streszczenie

Jako opiekun open-sourcowego kodu, spłaszczaj (squashuj) gałęzie funkcyjne (featurowe) do gałęzi głównej - `master`
oraz pisz ustandaryzowane opisy dostarczeń (commitów).

Opis dostarczenia powinien wyglądać następująco:

---

```
<typ>[opcjonalny zakres]: <opis>

[opcjonalne ciało wiadomości]

[opcjonalna stopka wiadomości]
```
---


Wiadomość zawiera następujące strukturalne elementy po to, aby zakomunikować intencje
do użytkowników Twojej biblioteki:

1. **fix:** dostarczenie _typu_ `fix` naprawia błąd obecny w Twoim kodzie (powiązane z [`PATCH`](http://semver.org/#summary) w wersjonowaniu semantycznym).
1. **feat:** dostarczenie _typu_ `feat` wprowadza nowe funkcje do Twojej biblioteki (powiązane z [`MINOR`](http://semver.org/#summary) w wersjonowaniu semantycznym).
1. **BREAKING CHANGE:** dostarczenie, które posiada tekst `BREAKING CHANGE:` na początku jego opcjonalnego ciała bądź stopki wprowadza zmianę łamiącą kompatybilność API (powiązane z [`MAJOR`](http://semver.org/#summary) w wersjonowaniu semantycznym). Zmiana łamiąca kompatybilność wsteczną może być elementem zmian  _typu_, `fix:` lub `feat:`.

Przy typie dostarczenia może zostać podany zakres w celu dostarczenia dokładniejszej informacji o kontekście dostarczenia.
Zawiera się on w nawiasach następujących bezpośrednio po typie, np. `feat(parser): dodano możliwość parsowania list`.

Wiadomości _typu_ innego niż `fix:` oraz `feat:` są dopuszczalne, na przykład [konwencja Angulara](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) poleca `docs:`, `style:`, `refactor:`, `perf:`, `test:`, `chore:`,
jednak tagi te nie są respektowane przez specyfikacje konwencjonalnych Commitów.

## Wprowadzenie

Podczas rozwoju oprogramowania zauważyłem, że błędy często występują na granicy
pomiędzy aplikacjami. Testy jednostkowe doskonale zdają egzamin w przypadkach, o których
opiekun biblioteki pomyślał, jednak sposoby, w jakich oprogramowanie zostanie użyte
przez społeczność często, choć interesujące mogą być nie do pomyślenia.
Tutaj testy jednostkowe niezbyt zdają egzamin.

Każdy, kto kiedykolwiek zaktualizował zależność swojej aplikacji, chociażby o jedną wersję _patch_,
tylko po to, aby zobaczyć, jak jego aplikacja zaczyna rzucać 500 błędami, wie,
jak ważną rolę stanowi czytelna historia dostarczeń (oraz dodatkowo [dobrze zarządzany DZIENNIK ZMIAN](http://keepachangelog.com/en/0.3.0/))
podczas naprawy.

Specyfikacja Konwencjonalnych Commitów proponuje wprowadzenie ustandaryzowanej, lekkiej
konwencji wykorzystującej wiadomości w dostarczeniach. Konwencja ta łączy się z [SemVer](http://semver.org),
nakazując deweloperom opisywanie w wiadomościach podczas dostarczania jakie funkcje wprowadzają, co naprawiają
oraz jakie niekompatybilne wstecz zmiany wnoszą.

Wprowadzając tę konwencję, tworzymy powszechny język, który pozwala na dużo łatwiejsze
wyłapywanie błędów występujących na granicy projektu z jego zależnościami.

## Specyfikacja

Następujące terminy “MUSI” (“MUST”), “NIE MOŻE” (“MUST NOT”), “WYMAGANY” (“REQUIRED”), “MA BYĆ” (“SHALL”), “NIE BĘDZIE” (“SHALL NOT”), “POWINIEN” (“SHOULD”), “NIE POWINIEN” (“SHOULD NOT”), “ZALECANY” (“RECOMMENDED”), “MOŻE” (“MAY”) oraz “OPCJONALNY” (“OPTIONAL”) pojawiające się w tym dokumencie rozumiane są zgodnie z ich opisem na stronie: [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).

1. Dostarczenie MUSI być poprzedzone typem, który składa się z rzeczownika, np. `feat`, `fix`, itp.,
   oraz następującymi bezpośrednio po nim dwukropka oraz spacji.
1. Typ `feat` MUSI być użyt, gdy dostarczenie dodaje nową funkcję do Twojej aplikacji bądź bibliteki.
1. Typ `fix` MUSI być użyty, kiedy dostarczenie naprawia błąd w Twojej aplikacji.
1. Opcjonalny zakres MOŻE być podany po typie. Zakres jest to fraza opisująca obszar kodu zawarta w nawiasach okrągłych, np., `fix(parser):`
1. Opis MUSI występować zaraz po przedrostku typu/zakresu.
  Opis jest to krótka notka stanowiąca o treści dostarczenia, np.,
  _fix: problem podczas parsowania listy, kiedy string zawierał wiele spacji._
1. Dłuższe ciało wiadomośći MOŻĘ być podane po krótkim opisie. Ciało MUSI zaczynać się jedną pustą linię po opisie.
1. Stopka MOŻE być podane jedną linię za ciałem wiadomości. Stopka POWINNA zawierać dodatkowe informacje odnośnie zgłoszeń błędów lub propozycji funkcjonalności, które rozwiąznuje, np. `fixes #13, #5`.
1. Zmiany niekompatybilne wstecz MUSZĄ być zaznaczone na samym początku sekcji ciała wiadmości lub stopki. Informacja o niekompatybilności MUSI zawierać tekst `BREAKING CHANGE`, wraz z następującymi po nim dwukropkiem oraz spacją.
1. Po tekście `BREAKING CHANGE: ` MUSI następować opis mówiący o tym, co zostało zmienione w kodzie w sposób, który niszczy kompatybilność wstecz,
np. _BREAKING CHANGE: zmienne środowiskowe mają teraz większy priorytet niż pliki konfiuguracyjne._
1. Typy inne niż `feat` oraz `fix` MOGĄ być użyte w wiadomościach Twoich dostarczeń.

## Dlaczego używać Konwencjonalnych Commitów

* Automatycznie generowany DZIENNIK ZMIAN.
* Automatycznie wykrywana zmiana semantycznej zmiany wersji (określana na podstawie typów dostarczonych zmian)
* Komunikowanie zmian członkom zespołu, publice, oraz innym zainteresowanym.
* Wyzywalanie procesów budowania oraz publikacji.
* Łatwiejsze włączenie się w rozwój kodu przez ludzi z zewnątrz poprzez pozwolenie im na przeglądanie
  bardziej zorganizowanej historii dostarczeń.

## FAQ

### Jak powinienem radzić sobie z wiadomościami dostarczeń w fazie początkowej rozwoju kodu?

Polecamy, żebyś postępował tak, jakby Twój produkt już został wydany. Zazwyczaj *ktoś*, nawet jeśli jest to Twój kolega z zespołu, już
używa Twojego oprogramowania. Będzie chciał wiedzieć, co zostało naprawione, co nie działa itp.

### Co powinienem zrobić, jeśli dostarczenie pasuje do więcej niż jednego typu?

Wróć się i stwórz więcej dostarczeń, jeśli to tylko możliwe. Częściową korzyścią z Konwencjonalnych Commitów jest zdolność do tworzenia kodu
w bardziej zorganizowany sposób.

### Czy takie podejście nie zniechęca do szybkiego rozwoju oraz szybkich iteracji?

Zniechęca do szybkiego poruszania się do przodu w niezorganizowany sposób. Pozwala Ci na szybkie posuwanie się do przodu w wielu projektach oraz
różnorodnych deweloperów.

### Czy Konwencjonalne Commity mogą prowadzić do zmniejszenia ilości typów dostarczanych przez deweloperów, ponieważ będą myśleć w przestrzeni wymienionych typów?

Konwencjonalne Commity zachęcają do tworzenia większej ilości dostarczeń danego typu, np. napraw. Z innego punktu widzenia, elastyczność
Konwencjonalnych Commitów pozwala Twojemu zespołowi stworzyć własne typy oraz zmieniać je z biegiem czasu.

### Jak jest to powiązane z SemVer?

Wiadomości typu `fix` powinny być traktowane tak jak `PATCH`. Wiadomości typu `feat` tak jak `MINOR`, natomiast dostarczenia zawierające `BREAKING CHANGE`, bez względu na typ, powinny być traktowane jak `MAJOR`.

### Jak powinienem wersjonować moje rozszerzenia zgodnie ze specyfikacją Konwencjonalnych Commitów, np. `@jameswomack/conventional-commit-spec`?

Zalecamy używanie SemVer do wydawania własnych rozszerzeń do tej specyfikacji (oraz zachęcamy do tworzenia tych rozszerzeń!).

### Co powinienem zrobić, jeśli przypadkowo użyje błędnego typu dostarczenia?

#### Jeśli użyłeś typu, który znajduje się w specyfikacji, ale nie jest poprawny, np. `fix` zamiast `feat`

Przed dostarczeniem i wydaniem pomyłki, polecamy użyć `git rebase -i` w celu zmienienia historii dostarczeń. Zmiana po dostarczeniu zależy od narzędzi oraz procesów, których używasz.

#### Jeśli użyłeś typu, który *nie* znajduje się w specyfikacji, np. `feet` zamiast `feat`

W najgorszym przypadku - to nie koniec świata, jeśli dostarczenie niespełniające specyfikacji Konwencjonalnych Commitów zostanie wprowadzone.
Po prostu znaczy to, że będzie pominięty przez narzędzia bazujące na specyfikacji.

### Czy wszyscy moi kontrybutorzy muszą używać specyfikacji Konwencjonalnych Commitów?

Nie! Jeśli używasz trybu bazującego na spłaszczaniu historii dostarczeń, wtedy główni opiekunowie projektu mogą posprzątać wiadomości
podczas dostarczania. Takie podejście nie narzuca żadnego obowiązku na osoby dostarczające od czasu do czasu. Powszechnym podejściem
jest używanie automatycznego spłaszczania historii dostarczeń z pull requestóœ oraz wyświetlenie formularza osobie dostarczającej w celu wypełnienia wiadomości poprawną treścią.

---

## File: content/v1.0.0-beta/index.zh-hans.md

---
draft: false
---

# 约定式提交 1.0.0-beta

## 概述

开源维护者在将特性分支合并入 `master` 时，可编写标准化的提交说明。

提交说明的结构如下所示：

---

```
<类型>[可选的作用域]: <描述>

[可选的正文]

[可选的页脚]
```
---


提交说明包含了下面的结构化元素，以向类库使用者表明其意图：

1.**fix:** _类型_ 为 `fix` 的提交表示在代码库中修复了一个 bug（这和语义化版本中的 [`PATCH`](http://semver.org/#summary) 相对应）。
1.**feat:** _类型_ 为 `feat` 的提交表示在代码库中新增了一个功能（这和语义化版本中的 [`MINOR`](http://semver.org/#summary) 相对应）。
1.**BREAKING CHANGE:** 在可选的正文或页脚的起始位置带有 `BREAKING CHANGE:` 的提交，表示引入了破坏性变更（这和语义化版本中的 [`MAJOR`](http://semver.org/#summary) 相对应）。破坏性变更可以是 `fix:` 或 `feat:` _类型_ 提交的一部分。
1.其它在 `fix:` 和 `feat:` 之外的提交 _类型_ 也都是支持的，例如 [Angular 约定](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) 中推荐使用 `docs:`、`style:`、`refactor:`、`perf:`、`test:`、`chore:`，但这些标签在约定式提交规范中并不是强制性的。


可以为提交类型添加一个围在圆括号内的作用域，以为其提供额外的上下文信息。例如 `feat(parser): add ability to parse arrays.`

## 介绍

在软件开发中，个人的经验是 bug 最常由应用间的边界引入。对单元测试而言，在所测试的交互处在开源维护者知识范围内时，它工作得很好。但在刻画社区里各种有趣而常在预料之外的使用场景时，它就显得比较糟糕了。

任何在升级新依赖 patch 版本后发现应用开始抛出稳定 500 错误流的人，都知道可读的提交历史（以及[理想条件下高质量维护的 CHANGELOG](http://keepachangelog.com/en/0.3.0/)）有多重要。

约定式的提交规范提议在提交说明的基础上，引入标准化的轻量约定。这个约定和 [SemVer](http://semver.org) 相吻合，要求开发者在提交信息中描述新特性、bug 修复和破坏性更新。

引入这一约定后，我们可以创建一种通用的语言，简化在项目边界之间调试的问题。

## 约定式提交规范

本文档中的关键词 “必须”、“禁止”、“需要”、“应当”、“不应当”、“应该”、“不应该”、“推荐”、“可以” 和 “可选” 应按照 [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) 的描述解释。

1. 每个提交都**必须**使用类型字段前缀，这由一个形如 `feat` 或 `fix` 的名词组成，其后接冒号和空格。
1. 当一个提交为应用或类库实现了新特性时，**必须**使用 `feat` 类型。
1. 当一个提交为应用修复了 bug 时，**必须**使用 `fix` 类型。
1. 可选的作用域字段**可以**在类型后提供。作用域是描述代码库中某个部分的词组，封装在括号中，形如 `fix(parser):` 等。
1. 描述字段**必须**紧接在类型或作用域前缀之后。描述指的是对 pull request 的简短描述，形如 _fix: array parsing issue when multiple spaces were contained in string._
1. 在简短描述之后，**可以**编写更长的提交正文。正文**必须**起始于描述字段结束的一个空行后。
1. 在正文结束的一个空行后，**可以**编写页脚。页脚**应当**包含额外的元信息（例如它所修复的 issue，类似 `fixse #13, #5` 等）。
1. 破坏性变更**必须**在提交的正文或脚注加以展示。一个破坏性变更**必须**包含大写的文本 `BREAKING CHANGE`，紧跟冒号和空格。
1. 在 `BREAKING CHANGE: ` 之后**必须**提供描述，以描述对 API 的变更。例如 _BREAKING CHANGE: environment variables now take precedence over config files._
1. 在提交说明中，**可以**使用 `feat` 和 `fix` 之外的类型。

## 为什么使用约定式提交

* 自动化生成 CHANGELOG。
* 基于提交的类型，自动决定语义化的版本变更。
* 向同事、公众与其他利益关系人传达变化的性质。
* 触发构建和部署流程。
* 让人们更容易地探索结构化的提交历史，降低贡献项目的难度。

## FAQ

### 如何处理初始开发阶段的提交说明？

我们建议你按照已发布的产品那样来处理。一般情况下即便是开发者同事，也*有人*使用你的软件。他们会希望知道诸如修复了什么、哪里不兼容等信息。

### 提交符合一或多种类型时该如何处理？

回退并尽可能创建多次提交。约定式提交的部分好处是能够促使我们做出更有组织的提交和 PR。

### 这不会阻碍快速的开发和迭代吗？

它阻碍的是以杂乱无章的方式快速前进。它帮助我们在横跨长时间周期、多个项目、多个贡献者时能够保持效率。

### 约定式提交会让开发者受限于提交的类型吗？

约定式提交鼓励我们更多地使用某些类型的提交，比如 fixes。除此之外，约定式提交的灵活性也允许你的团队使用自己的类型，并随着时间的推移更改这些类型。

### 这和 SemVer 有什么关联呢？

`fix` 类型提交应当对应到 `PATCH` 版本。`feat` 类型提交应该对应到 `MINOR` 版本。带有 `BREAKING CHANGE` 的提交不管类型如何，都应该对应到 `MAJOR` 版本。

### 我对约定式提交做了形如 `@jameswomack/conventional-commit-spec` 的扩展，该如何版本化管理这些扩展呢？

我们推荐使用 SemVer 来发布你对于这个规范的扩展（并鼓励你创建这些扩展！）

### 如果我不小心使用了错误的提交类型，该怎么办呢？

#### 当你使用了在规范中但错误的类型时，如将 `feat` 写成了 `fix`

在合并或发布这个错误之前，我们建议使用 `git rebase -i` 来编辑提交历史。而在发布之后，根据你使用的工具和流程不同，会有不同的清理方案。

#### 当使用了 *不* 在规范中的类型时，如将 `feat` 写成了 `feet`

在最坏的场景下，即便提交没有满足约定式提交的规范，也不是世界的终结。这只意味着这个提交会被基于规范的工具错过而已。

### 所有的贡献者都需要使用约定式提交规范吗？

并不！如果你使用基于 squash 的 Git 工作流，主管维护者可以在合并时清理提交信息——这不会对普通提交者产生额外的负担。有种常见的工作流是让 git 系统自动从 pull request 中 squash 出提交，向主管维护者提供表单，来在合并时输入合适的 git 提交信息。

---

## File: content/v1.0.0-beta.4/index.fr.md

---
draft: false
aliases: ["/fr/"]
---

# Conventional Commits 1.0.0-beta.4

## Résumé

La spécification de Conventional Commits est une convention légère pour des messages de commit au top.
Il fournit un ensemble simple de règles pour créer un historique de commit explicite;
Ce qui facilite l'écriture d'outils automatisés.
Cette convention est liée à [SemVer](http://semver.org),
en décrivant les fonctionnalités,
les correctifs et les modifications importantes apportées aux messages de commit.

Le message du commit doit être structuré comme suit:

---

```
<type>[optional scope]: <description>

[optional body]

[optional footer]
```
---


Le commit contient les éléments structurels suivants, permettant de communiquer à l’intention des
consommateurs de votre bibliothèque:

1. **fix:** un commit de _type_ `fix` corrige un bogue dans le code (cela est en corrélation avec
[`PATCH`](http://semver.org/#summary) en versioning sémantique).
1. **feat:** un commit de _type_ `feat` introduit une nouvelle fonctionnalité dans le code (cela est en corrélation avec  [`MINOR`](http://semver.org/#summary) en versioning sémantique).
1. **BREAKING CHANGE:** un commit qui a le texte `BREAKING CHANGE:` qui est facultatif au début du texte ou section de pied de page introduit un changement cassant l'API (cela est en corrélation avec [`MAJOR`](http://semver.org/#summary) en versioning sémantique).
Un changement radical peut faire partie des commits de n'importe quel type.
1. Others: commit de _types_ autre que `fix:` et `feat:` sont autorisés, par exemple [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (basé sur [the Angular convention](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)) recommande `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, et d'autres.

Nous recommandons également `improvement` pour les commits qui améliorent une implémentation en cours sans ajouter de nouvelle fonctionnalité ou correction de bogue. Remarquez que ces types ne sont pas prescrits par la spécification de Conventional Commits et n'ont aucun effet implicite dans la gestion des versions sémantiques (à moins qu'ils ne comportent un BREAKING CHANGE).

Un scope peut être fourni au type d'un commit, pour fournir des informations contextuelles supplémentaires et
le contenu entre parenthèses, par exemple, `feat (analyseur): ajout possibilité d'analyser des tableaux`.

## Exemples

### Message de commit avec description et changement radical dans le texte
```
feat: permet à l'objet de configuration fourni d'étendre d'autres configurations

BREAKING CHANGE: la clé `extends` dans le fichier de configuration est maintenant utilisée pour étendre d'autres fichiers de configuration
```

### Message du commit avec l'option `!` attire l'attention sur un changement radical
```
chore!: supprimer le nœud 6 de la matrice de test

BREAKING CHANGE: suppression du nœud 6 qui arrive en fin de vie en avril
```

### Message commit sans corps de texte
```
docs: correction d'orthographe dans CHANGELOG
```

### Message commit avec scope
```
feat(lang): ajout de la langue polonaise
```

### Message commit pour un correctif à l'aide d'un numéro d'un issue (facultatif).
```
fix: fautes de frappe mineures dans le code

voir le problème pour plus de détails sur les fautes de frappe corrigées

fixes issue #12
```

## Spécification

Les mots clés ”DOIT” (“MUST”), “NE DOIT PAS” (“MUST NOT”), “REQUIS” (“REQUIRED”), “NE DOIT” (“SHALL”), “NE DOIT PAS” (“SHALL NOT”), “NE DEVRAIT” (“SHOULD”), “NE DEVRAIT PAS” (“SHOULD NOT”), “RECOMMANDÉ” (“RECOMMENDED”), “PEUT” (“MAY”), et “FACULTATIF” (“OPTIONAL”) dans ce document doivent être interprétés comme décrit dans [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).

1. Les commits DOIVENT être préfixés par un type, qui consiste en un nom, `feat`,` fix`, etc.,
   suivi de deux points et d'un espace.
1. Le type `feat` DOIT être utilisé lorsqu'un commit ajoute une nouvelle fonctionnalité à votre application.
  ou bibliothèque.
1. Le type `fix` DOIT être utilisé lorsqu'un commit représente un correctif pour votre application.
1. Un scope facultative PEUT être fourni après un type. Un scope est une phrase décrivant
  une section du code encadrée par des parenthèses, par exemple, `fix (analyseur):`
1. Une description DOIT suivre immédiatement le préfixe type/scope.
  La description est une brève description des modifications du code, par exemple,
  _fix: problème d'analyse d'un tableau lorsque plusieurs espaces étaient contenus dans string._
1. Un texte plus long PEUT être fourni après la description courte, fournissant des informations contextuelles supplémentaires sur les modifications du code. Le texte DOIT commencer par une ligne vide après la description.
1. Un pied de page d'une ou plusieurs lignes PEUT être précédé d'une ligne blanche après le corps. Le pied de page DOIT contenir des méta-informations.
  À propos du commit, par exemple, demandes d'extraction associées, relecteurs, modifications importantes, avec une méta-information
par ligne.
1. Les changements de rupture DOIVENT être indiqués au tout début de la section corps, ou au début d’une ligne dans la section pied de page. Un changement radical DOIT être dans le texte en majuscule BREAKING CHANGE, suivi de deux points et d'un espace.
1. Une description DOIT être fournie après le `BREAKING CHANGE: `, décrivant
  la modification de l’API, par exemple, _BREAKING CHANGE: les variables d’environnement sont désormais prioritaires sur les fichiers de configuration._
1. Des types autres que `feat` et` fix` PEUVENT être utilisés dans vos messages de commit.
1. Les unités d'informations constituant les commits classiques NE DOIVENT PAS être considérées comme sensibles à la casse par les développeurs, à l'exception de BREAKING CHANGE, qui DOIT être en majuscule.
1. Un `!` PEUT être ajouté avant le `:` dans le préfixe type/scope, pour attirer davantage l'attention sur la modification des modifications. `BREAKING CHANGE: la description` DOIT également être incluse dans le corps
ou pied de page, avec le `!` dans le préfixe.

## Pourquoi Utiliser Conventional Commits

* Génération automatique de CHANGELOGs.
* Déterminer automatiquement un choc de version sémantique (en fonction des types de commits débarqués).
* Communiquer la nature des changements aux coéquipiers, au public et aux autres parties prenantes.
* Déclencher des processus de construction et de publication.
* Faciliter la contribution des personnes à vos projets en leur permettant d’explorer
   un historique de commit plus structurée.

## FAQ

### Comment dois-je gérer les messages de commit dans la phase de développement initiale ?

Nous vous recommandons de procéder comme si vous aviez déjà publié un produit. Généralement *quelqu'un*, même si ce sont vos collègues développeurs de logiciels, utilise votre logiciel. Ils voudront savoir ce qui est corrigé, ce qui casse, etc.

### Les types dans le titre des commits sont-ils en majuscules ou en minuscules?

N'importe quelle taille peut être utilisée, mais il est préférable d'être cohérent.

### Que dois-je faire si le commit est conforme à plus d'un type de commit?

Revenez en arrière et faites plusieurs commits autant que possible. Une partie des avantages de Conventional Commits réside dans sa capacité à nous inciter à créer des commits et des PR plus organisés.

### Est-ce que cela ne décourage pas le développement rapide et l’itération rapide ?

Cela décourage les commits rapides de manière désorganisée. Il vous aide à être en mesure que vous commité rapidement à long terme dans plusieurs projets avec des contributeurs variés.

### Les engagements conventionnels peuvent-ils amener les développeurs à limiter le type d’engagements qu’ils font car ils penseront aux types fournis?

Conventional Commits nous encouragent à utiliser davantage certains types de commits tels que les correctifs. En dehors de cela, la flexibilité de Conventional Commits permet à votre équipe de créer ses propres types et de les modifier au fil du temps.

### Quel est le lien avec SemVer ?

Les corrections de type `fix` devraient être traduites en` PATCH`. Les commits de type `feat` devraient être traduits en versions` MINOR`. Les commits avec `BREAKING CHANGE` dans les commits, quel que soit leur type, doivent être traduits en versions` MAJOR`.

### Comment dois-je mettre à jour mes extensions de la spécification de Conventional Commits, par exemple `@jameswomack/conventionnel-commit-spec` ?

Nous vous recommandons d’utiliser SemVer pour publier vos propres extensions à cette spécification (et
vous encourage à faire ces extensions !)

### Que dois-je faire si j'utilise accidentellement le type de commit incorrect ?

#### Lorsque vous utilisez un type de commit incorrect, par exemple `fix` au lieu de` feat`

Avant de fusionner ou de libérer l'erreur, nous vous recommandons d'utiliser `git rebase -i` pour éditer l'historique du commit. Après la publication, le nettoyage sera différent selon les outils et les processus que vous utilisez.

#### Lorsque vous utilisez un type qui n'est *pas* dans les spécifications, par exemple `feet` au lieu de` feat`

Dans le pire des cas, ce n'est pas la fin du monde si un commit atterrit sans respecter les spécifications de Conventional Commits. Cela signifie simplement que l’engagement sera raté par des outils basés sur les spécifications.

### Est-ce que tous mes contributeurs doivent utiliser les spécifications de Conventional Commits ?

Non ! Si vous utilisez un flux de travail basé sur squash sur Git, les responsables principaux peuvent nettoyer les messages des commits au fur et à mesure de leur fusion, ce qui permet de ne pas ajouter de charge de travail aux committers occasionnels.
Un processus courant consiste à ce que votre système git écrase automatiquement les commits d'une demande d'extraction et présente un formulaire permettant au responsable de la maintenance d'entrer le message du commit git approprié pour la fusion.

---

## File: content/v1.0.0-beta.4/index.hy.md

---
draft: false
aliases: ["/hy/"]
---


# Համաձայնեցված «Commit»֊ներ 1.0.0-beta.4

## Համառոտագիր

Համաձայնեցված «commit»֊ների սպեցիֆիկացիան կանոնների խումբ է «commit»
մեսիջների վերաբերյալ։ Այն առաջարկում է պարզ կանոններ և պահանջներ, որոնց միջոոցով
հնարավոր է ստանալ հասկանալի և ընթեռնելի «commit»֊ների պատմություն, և հեշտացնել
ավտոմատացված ծրագրային ապահովման ստեղծումը, որոնք աշխատում են «commit» մեսիջների
հիման վրա։ Այս կանոնները ուղիղ կապ ունեն
[SemVer](http://semver.org/#summary)֊ի սպեցիֆիկացիայի հետ, և օգատգործվում են նոր
ֆունցիոնալի ինտեգրման (features), սխալների ուղղումների (fixes) և հետ
համատեղելիությունը խախտող փոփոխությունների (bracking changes) մասին «commit»
մեսիջներում տեղելացնելու համար։

«commit» մեսիջները պետք է ունենան հետևյալ կառուցվածքը՝

---

```
<տեսակ (type)>[ոչ պարտադիր կոնտեքստ (optional scope)]: <բացատրություն (description)>

[ոչ պարտադիր մարմին (optional body)]

[ոչ պարտադիր ներքևի հատված (optional footer)]
```
---

«commit»֊ները պարունակում են հետևյալ ստրուկտուրալ էլեմենտները, որոնց միջոցով ձեր
ծրագրային ապահովման օգտագործողները կարող են հասկանալ ինչ է տեղի ունեցել
«commit»֊ների արդյունքում՝

1. **fix։**․ `fix` _ՏԵՍԱԿԻ_ «commit»֊ները նախատեված են սխալների ուղղումների (bug
fix) մասին տեղեկացնելու համար (այն փոխկապակցված է սեմանտիկ տարբերակման մեջ
ներկայացված [`«ՓԱԹՉ»`](http://semver.org/#summary)֊ի հետ)։

2. **feat։**․ `feat` _ՏԵՍԱԿԻ_ «commit»֊ները նախատեված են նոր
ֆունկցիոնալի ինտեգրման մասին տեղեկացնելու համար (այն փոխկապակցված է սեմանտիկ
տարբերակման մեջ ներկայացված [`«ՄԻՆՈՐ»`](http://semver.org/#summary)֊ի հետ)։

3. **BREAKING CHANGE։**․ `BREAKING CHANGE։`  պարունակող «commit»֊ները
(_ՄԱՐՄՆՈՒՄ_ կամ _ՆԵՐՔԵՎԻ ՀԱՏՎԱԾՈՒՄ_ ) տեղեկացնում են API֊ում արված փոփոխության
մասին, որը խախտում է հետ համատեղելիությունը (breaking changes) (այն փոխկապակցված
է սեմանտիկ տարբերակման մեջ ներկայացված [`ՄԱԺՈՐ`](http://semver.org/#summary)֊ի
հետ), `BREAKING CHANGE:`֊ը կարող է հանդիպել կամայական _ՏԵՍԱԿԻ_ «commit»֊ների հետ:

4. Ուրիշ տեսակներ. կարելի է օգտագործել նաև վերը նշվածներից տարբերվող
_ՏԵՍԱԿ_ ունեցող (`fix:` և `feat:`) «commit»֊ներ, օրինակ՝
[@commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional)֊ը
(հիմնված է [Angular convention](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)֊ի վրա)
առաջարկում է օգագործել են նաև՝ `chore:`, `docs:`, `style:`, `refactor:`,
`perf:`, `test:` և այլ _ՏԵՍԱԿԻ_ «commit»֊ներ։

Մենք նաև առաջարկում ենք օգագործել `improvement`, այն _ՏԵՍԱԿԻ_ «commit»֊ների
համար, որոնք բարելավում են գործող իմպլեմենտացիան առանց նոր ֆունկցիոնալի
ինտեգրման և սխալների ուղղման։ Ուշադրություն դարձրեք, որ «commit»֊ների այս
_ՏԵՍԱԿՆԵՐԸ_ չեն հանդիսանում համաձայնեցված «commit»֊ների սպեցիֆիկացիայի մաս և ոչ
մի ձևով փոխկապակցված չեն սեմանտիկ տարբերակման սպեցիֆիկացիայի հետ (բացառություն
են հանդիսանում `BREAKING CHANGE:` պարունակող «commit»֊ները)։

_ԿՈՆՏԵՔՍՏ_ կարող է ավելացվել «commit»֊ի _ՏԵՍԱԿԻՆ_ ՝ «commit»-ի կոնտեքստ
սահմանելու նպատակով։ _ԿՈՆՏԵՔՍՏԸ_ պետք է լինի փակագծերի մեջ օրինակ՝
`feat(parser): add ability to parse arrays`։

## Օրինակներ

### «commit», որը ունի _ԲԱՑԱՏՐՈՒԹՅՈՒՆ_ և _BREAKING CHANGE_ իր մարմնում

```
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», որում կա `!` _BREAKING CHANGE_ ֊ի վրա ուշադրություն գրավելու համար

```
chore!: drop Node 6 from testing matrix

BREAKING CHANGE: dropping Node 6 which hits end of life in April
```

### «commit», որը չունի _ՄԱՐՄԻՆ_

```
docs: correct spelling of CHANGELOG
```

### «commit», որը ունի _ԿՈՆՏԵՔՍՏ_

```
feat(lang): add polish language
```

### «commit», սխալի ուղղման համար, որը պարունակում է առաջադրանքի (issue) համարը

```
fix: correct minor typos in code

see the issue for details on the typos fixed

closes issue #12
```

## Սպեցիֆիկացիա

Նշված բառերը՝ «ՊԵՏՔ Է» (MUST, SHALL), «ՉՊԵՏՔ Է» (MUST NOT, SHALL NOT),
«ՊԱՐՏԱԴԻՐ» (REQUIRED), «ԱՆՀՐԱԺԵՇՏ Է» (SHOULD), «ԱՆՀՐԱԺԵՇՏ ՉԷ» (SHOULD NOT),
«ԽՈՐՀՈՒՐԴ Է ՏՐՎՈՒՄ» (RECOMMENDED), «ԿԱՐՈՂ Է» (MAY) և «ՈՉ ՊԱՐՏԱԴԻՐ» (OPTIONAL)
պետք է ինտերպրիտացվեն [RFC 2119](http://tools.ietf.org/html/rfc2119) ստանդարտին
համապատասխան։

1. «commit» մեսիջները ՊԵՏՔ Է (MUST) սկսվեն _ՏԵՍԱԿԻ_ (type) մասին նշումով, որը
գոյական է (noun) և բաղկացած է լինում մեկ բառից՝ օրինակ՝ `feat`, `fix`, և այլն։
Դրան հետևում է ՈՉ ՊԱՐՏԱԴԻՐ (OPTIONAL) _ԿՈՆՏԵՔՍՏԸ_ (scope) և ՊԱՐՏԱԴԻՐ (REQUIRED)
վերջակետի նշանը և բացատը։

2. `feat` _ՏԵՍԱԿԸ_ ՊԵՏՔ Է (MUST) օգտագործվի, երբ «commit»֊ի արդյունքում տեղի է
ունենում նոր ֆունցիոնալի իմպլեմենտացիա ձեր ծրագրում կամ գրադարանում։

3. `fix` _ՏԵՍԱԿԸ_ ՊԵՏՔ Է (MUST) օգտագործվի, երբ «commit»֊ի արդյունքում տեղի է
ունենում սխալի ուղղում ձեր ծրագրում։

4. _ԿՈՆՏԵՔՍՏԸ_ ԿԱՐՈՂ Է (MAY) ավելացվել _ՏԵՍԱԿԻՑ_ անմիջապես հետո։ _ԿՈՆՏԵՔՍՏԸ_
ՊԵՏՔ Է (MUST) գոյական լինի պարփակված փակագծերի մեջ, և նկարագրի կոդի այն հատվածը,
որի վրա անդրադարձել է «commit»֊ը։ Օրինակ՝ `fix(parser): `։

5. _ԲԱՑԱՏՐՈՒԹՅՈՒՆԸ_ (description) ՊԵՏՔ Է (MUST) լինի անմիջապես
_ՏԵՍԱԿ/ԿՈՆՏԵՔՍՏ_-ին հետևող բացատից հետո։ _ԲԱՑԱՏՐՈՒԹՅՈՒՆԸ_ համառոտ ներկայանում է
կոդում եղած փոփոխությունները։ Օրինակ՝
`fix: array parsing issue when multiple spaces were contained in string`։

6. _ՄԱՐՄԻՆԸ_ (body) ԿԱՐՈՂ Է (MAY) հետևել կարճ _ԲԱՑԱՏՐՈՒԹՅԱՆԸ_ և ավելի մեծ
ինֆորմացիա տրամադրել կոդում եղած փոփոխությունների մասին։ _ՄԱՐՄԻՆԸ_ ՊԵՏՔ Է (MUST)
առանձնացվի _ԲԱՑԱՏՐՈՒԹՅՈՒՆԻՑ_ մեկ դատարկ տողով։

7. _ՆԵՐՔԵՎԻ ՀԱՏՎԱԾԸ_ (footer) ԿԱՐՈՂ Է (MAY) լինել մեկ կամ մի քանի տողի տեսքով
_ՄԱՐՄՆԻՑ_ անմիջապես հետո և պետք է անջատված լինի _ՄԱՐՄՆԻՑ_ մեկ դատարկ տողով։
_ՆԵՐՔԵՎԻ ՀԱՏՎԱԾԸ_ ՊԵՏՔ Է (MUST) պարունակի մետա֊ինֆորմացիա «commit»֊ի մասին,
օրինակ՝ «pull» հարցումների, ստուգողների (reviewers), հետ համատեղելիությունը
խախտող փոփոխությունների և ալյն։ Մետա֊ինֆորմացիայի ամեն մասը զբաղեցնում է մեկ տող։

8. Հետ համատեղելիությունը խախտող փոփոխությունները ՊԵՏՔ Է (MUST) պիտակավորվեն
_ՄԱՐՄԻՆԻ_ կամ _ՆԵՐՔԵՎԻ ՀԱՏՎԱԾԻ_ սկզբում։ Հետ համատեղելիությունը խախտող
փոփոխությունները ՊԵՏՔ Է (MUST) պիտակավորվեն այս արտահայտությամբ՝ BREAKING CHANGE
(պարտադիր մեծատառերով), որին հետևում է վերջակետ և բացատ։

9. Հետ համատեղելիությունը խախտող փոփոխությունների նկարագիրը (ինչ է փոխվել
API-ում) ՊԵՏՔ Է (MUST) հետևեն `BREAKING CHANGE: ` պիտակին։ Օրինակ՝
`BREAKING CHANGE: environment variables now take precedence over config files.`։

10. «commit»-ների _ՏԵՍԱԿՆԵՐԸ_ ԿԱՐՈՂ ԵՆ (MAY) լինել `feat`֊ից և `fix`֊ից տարբեր։

11. Համաձայնեցված «commit»֊ներում ներկայացված բաղադրիչները, ՉՊԵՏՔ Է (MUST NOT)
դիտարկվեն, որպես ռեգիստրից կախված (case sensitive), բացառություն է միայն
`BREAKING CHANGE`֊ը, որը միշտ պետք է լինի մեծատառերով։

12. `!` նշանը ԿԱՐՈՂ Է (MAY) ավելացվել `:` նշանից առաջ և _ՏԵՍԱԿ/ԿՈՆՏԵՔՍՏ_-ից հետո,
որպեսզի ուշադրություն գրավի հետ համատեղելիությունը խախտող փոփոխությունների վրա։
`BREAKING CHANGE: description` տողը ևս ՊԵՏՔ Է (MUST) ավելացվի
_ՄԱՐՄԻՆԻ_ կամ _ՆԵՐՔԵՎԻ ՀԱՏՎԱԾԻ_ սկզբում, եթե օգտագործվել է `!` նշանը։

## Ի՞նչու օգտագործել Համաձայնեցված «Commit»֊ներ

* Փոփոխությունների լոգերի (CHANGELOG) ավտոմատ գեներացում։
* Սեմանտիկ տարբերակի ավտոմատ որոշում «commit»֊ի հիման վրա։
* Տեղեկացնել փոփոխությունների բնույթի մասին թիմի անդամներին, հասարակությանը և
հետաքրքրված անձանց։
* Ավտոմատացնել կառուցման (build) և հրապարակման (publish) պրոցեսները։
* Հեշտացնում է նոր մասնակիցների ինտեգրումը ձեր նախագծին, հասանելի և
ստրուկտուրիզացված «commit»֊ների պատմության շնորհիվ։

## ՀՏՀ

### Ի՞նչպես գրել «commit» մեսիջները աշխատանքի նախնական փուլերում (initial development phase):

Խորհուրդ է տրվում գրել մեսիջներն այնպես, կարծես դուք արդեն հրապարակել եք
պրոդուկտը։ _Որևէ մեկին_ ՝ օրինակ ձեր գործընկերներին կարող է հետաքրքիր լինել, թե
ինչն է փոխվել, և ինչ նոր հետ համատեղելիությունը խախտող փոփոխություններ են եղել։

### Ի՞նչ անել, եթե «commit»֊ը ունի ավելի քան մեկ _ՏԵՍԱԿ_։

Եթե հնարավոր է արեք իմ քանի «commit»։ Համաձայնեցված «commit»֊ների հիմնական
առավելություններից մեկը՝ ավելի կազմակերպված «commit»֊ների և «PR»֊ների թողարկումն է։

### Արդյո՞ք աշխատելու այս ձևը չի խանգարում արագ ծրագրավորմանը (rapid development) և արագ իտերացիաներին (fast iteration)։

Այս եղանակը խանգարում է ոչ կազմակերպված արագ աշխատանքին։ Դրա փոխարեն դուք արագ
եք շարժվում երկարաժամկետ տեսլականով, մի քանի պրոյեկտի մասշտաբով և մի քանի
մասնակիցներ առկայությամբ։

### Արդյո՞ք համաձայնեցված «commit»֊ների _ՏԵՍԱԿՆԵՐԸ_ չեն սահմանափակի ծրագրավորողներին, քանի որ նրանք պետք է մտածեն տրամադրված _ՏԵՍԱԿՆԵՐԻ_ սահմաններում։

Համաձայնեցված «Commit»֊ների սպեցիֆիկացիան խրախուսում է այլ _ՏԵՍԱԿԻ_ «commit»֊ների
օգտագործումը։ Ձեր թիմը կարող է ազատ լինել իր սեփական _ՏԵՍԱԿՆԵՐԻ_ ստեղծման մեջ և
փոփոխել դրանք ժամանակի ընթացքում։

### Ի՞նչ կապ ունի այս ամենը տարբերակման սեմանտիկ կանոնների՝ SemVer֊ի հետ։

`fix` _ՏԵՍԱԿԻ_ «commit»֊ները թողարկվում են, որպես ՓԱԹՉ. `feat` _ՏԵՍԱԿԻ_
«commit»֊ները թողարկվում են, որպես ՄԻՆՈՐ. `BREAKING CHANGE` պարունակող կամայական
«commit», _ՏԵՍԱԿԻՑ_ անկախ, թողարկվում է, որպես ՄԱԺՈՐ։

### Ինչպե՞ս է պետք տարբերակել համաձայնեցված «commit»֊ների սպեցիֆիկացիայի հիման վրա ստեղծված իմ սեփական հավելվածերը, օրինակ՝ `@jameswomack/conventional-commit-spec`

Համաձայնեցված «commit»֊ների սպեցիֆիկացիայի հիման վրա ձեր հավելվածները ստեղծելիս
և թողարկելիս, խորհուրդ է տրվում օգտվել՝ [`SemVer`](http://semver.org/#summary)֊ից։
(Մենք խրախուսում ենք հավելվածների ստեղծումը)։

### Ինչ ես պետք է անեմ, երբ սխալմամբ «commit»֊ի սխալ _ՏԵՍԱԿ_ եմ օգտագործել։

#### Եթե ծեր օգտագործած _ՏԵՍԱԿԸ_ առկա է սպեցիֆիկացիայում, բայց այն սխալ է, օրինակ `fix`՝ `feat`֊ի փոխարեն։

Մինչ ձեր սխալը «mergе» անելը, կամ թողարկելը, խորհուրդ է տրվում օգտագործել
`git rebase -i` և փոփոխել commit»֊ների պատմությունը։ Թողարկելուց հետո, ուղղելու
եղանակները տարբեր են՝ կախված նրանից թե ինչ գործիքներից եք դուք օգտվում։

#### Եթե ձեր օգտագործած _ՏԵՍԱԿԸ_ առկա չէ սպեցիֆիկացիայում, օրինակ `feet`՝ `feat`֊ի փոխարեն։

Դա ամենևին էլ աշխարհի վերջը չէ։ Դա ուղղակի կնշանակի, որ ձեր սպեցիֆիկացիայի հիման վրա աշխատող գործիքներրը կանտեսեն այդ «commit»֊ը։

### Իմ բոլոր գործընկերները նույնպե՞ս պետք է հետևեն համաձայնեցված «commit»֊ների սպեցիֆիկացիային։

Ոչ․ եթե ձեր աշխատանքային պրոցեսը հիմնված է «squash»֊երի վրա՝ նախագծի ղեկավարը
կարող է մաքրել պատմությունը մինչև «mergе» անելը և ուշադրություն չդարձնել այդ ամենին։
Սովորաբար git֊ը ավտոմատ «squash» է անում «commit»֊ները PR֊ի ժամանակ և վերջին
«commit»֊ը անում է նախագծի ղեկավարը։

---

## File: content/v1.0.0-beta.4/index.id.md

---
draft: false
aliases: ["/id/"]
---

# Conventional Commits 1.0.0-beta.4

## Ringkasan

Conventional Commits adalah perjanjian sederhana tentang cara menulis pesat komit.
Ini menjelaskan sekumpulan aturan sederhana untuk membuat riwayat komit yang jelas;
yang memudahkan untuk membuat alat automatis di atasnya.
Perjanjian ini cocok dengan [SemVer](http://semver.org),
dengan menjelaskan suatu fitur (features), perbaikan (fixes), merusak perubahan (breaking changes) yang dimuat dalam pesan komit.

Pesan komit harus tersusun sebagai berikut:

---

```
<type>[optional scope]: <description>

[optional body]

[optional footer]
```
---


Komit berisi elemen struktural sebagai berikut, untuk menyampaikan maksud kepada
konsumen perpustakaan anda:

1. **fix:** komit _tipe_ `fix` untuk perbaikan celah (bug) dalam kode anda (ini berkolerasi dengan [`PATCH`](http://semver.org/#summary) di semantic versioning).
1. **feat:** komit _tipe_ `feat` memperkenalkan suatu fitur (feature) baru dalam kode anda (ini berkolerasi dengan [`MINOR`](http://semver.org/#summary) di semantic versioning).
1. **BREAKING CHANGE:** komit yang berisi teks `BREAKING CHANGE:` di awal bagian opsi badan atau kaki mengenalkan merusak perubahan API (ini berkolerasi dengan [`MAJOR`](http://semver.org/#summary) di semantic versioning).
BREAKING CHANGE dapat menjadi bagian dari komit _tipe_ apapun.
1. Lainya: komit dengan _tipe-tipe_ selain dari `fix:` and `feat:` diperbolehkan, misalnya [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (berdasarkan pada [Angular convention](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)) direkomendasikan `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, dan lainya.

Kami juga merekomendasikan `improvement` untuk komit yang meningkatkan implementasi saat ini tanpa menambahkan fitur baru atau memperbaiki celah (bug).
Perhatikan bahwa tipe-tipe ini tidak di amanatkan oleh spesifikasi conventional commits, dan tidak ada efek implisit dalam semantic versioning (kecuali mereka termasuk BREAKING CHANGE).

Cakupan dapat disediakan ke tipe komit. untuk memberikan informasi kontekstual tambahan dan terkandung dalam kurung, misalnya, `feat(parser): add ability to parse arrays`.

## Examples

### Pesan komit dengan deskripsi dan breaking change di badan
```
feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files
```

### Pesan komit dengan opsi `!` untuk menarik perhatian pada breaking change
```
chore!: drop Node 6 from testing matrix

BREAKING CHANGE: dropping Node 6 which hits end of life in April
```

### Pesan komit tanpa badan
```
docs: correct spelling of CHANGELOG
```

### Pesan komit dengan cakupan
```
feat(lang): add polish language
```

### Pesan komit untuk perbaikan menggunakan (opsi) nomor masalah.
```
fix: correct minor typos in code

see the issue for details on the typos fixed

closes issue #12
```

## Spesifikasi

Kata “HARUS”, “TIDAK BOLEH”, “DIBUTUHKAN”, “SEHARUSNYA”, “JANGAN SAMPAI”, “SEBAIKNYA”, “SEBAIKNYA TIDAK”, “DIREKOMENDASIKAN”, “BISA”, dan “OPSIONAL” di dokumen ini sesuai dengan [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).

1. Komit HARUS (MUST) diawali dengan tipe, yang terdiri dari kata benda, `feat`, `fix`, dll., diikuti
 dengan OPSIONAL (OPTIONAL) cakupan, dan DIBUTUHKAN terminal colon dan spasi.
1. tipe `feat` HARUS (MUST) digunakan ketika komit menambahkan fitur baru ke apilkasi atau perpustakaan anda.
1. tipe `fix` HARUS (MUST) digunakan ketika komit mewakili perbaikan celah (bug) untuk aplikasi anda.
1. Cakupan BISA (MAY) disediakan setelah tipe. Cakupan HARUS terdiri dari kata benda yang menggambarkan
 bagian dari kode yang dikelilingi tanda kurung, misalnya, `fix(parser):`
1. Deskripsi HARUS (MUST) segera mengikuti spasi setelah awalan tipe/cakupan.
Deskripsi adalah ringkasan singkat dari perubahan kode, misalnya, _fix: array parsing issue when multiple spaces were contained in string._
1. Komit badan yang leibh panjang BISA (MAY) disediakan setelah deskripsi pendek, memberikan informasi kontekstual tambahan tentang perubahan kode. Badan HARUS (MUST) diawalin dengan satu barus kosong setelah deskripsi.
1. Kaki satu atau lebih baris BISA (MAY) disediakan satu baris kosong setelah badan. kaki HARUS (MUST) berisi tentang meta-informasi
tentang perubahan, misalnya, related pull-requests, reviewers, breaking changes, dengan satu informasi meta
per baris.
1. Breaking changes HARUS (MUST) di tunjukan di bagian paling awal dari bagian tubuh, atau di awal baris di bagian kaki. Breaking change HARUS terdiri dari huruf besar BREAKING CHANGE, diikuti dengan colon dan spasi.
1. Deskripsi HARUS (MUST) disediakan setelah `BREAKING CHANGE: `, menggambarkan apa yang telah berubah tentang API, misalnya,  _BREAKING CHANGE: environment variables now take precedence over config files._
1. Tipe selain `feat` dan `fix` BISA (MAY) digunakan dalam pesan komit anda.
1. Unit-unit informasi yang membentuk conventional commits TIDAK BOLEH (MUST NOT) diperlakukan case sensitif oleh pelaksana, dengan pengecualian BREAKING CHANGE yang HARUS (MUST) huruf besar.
1. `!` BISA (MAY) ditambakan sebelum `:` dalam awalan tipe/cakupan, untuk menarik perhatian pada breaking changes. `BREAKING CHANGE: description` HARUS (MUST) dimasukan kedalam badan
atau kaki,bersama dengan `!` di awalan.

## Mengapa menggunakan Conventional Commits

* Secara automatis menghasilkan CHANGELOGs.
* Secara automatis menentukan versi semantic (Berdasarkan tipe komit yang dilakukan).
* Mengkomunikasikan sifat perubahan kepada rekan setim, publik, dan pemangku kepentingan lainnya.
* Memicu proses pembuatan dan publikasi.
* Mempermudah orang untuk berkontribusi pada proyek Anda, dengan memungkinkan mereka untuk menjelajah
  riwayat komit yang lebih terstruktur.

## FAQ

### Bagaimana saya harus berurusan dengan pesan komit pada fase pengembangan awal?

Kami menyarankan Anda melanjutkan seolah-olah Anda sudah merilis produk. Biasanya *seseorang*, bahkan jika itu sesama pengembang perangkat lunak Anda, menggunakan perangkat lunak Anda. Mereka ingin tahu apa yang diperbaiki, apa yang rusak, dll.

### Apakah tipe dalam komit judul huruf besar atau kecil?

Casing apa pun dapat digunakan, tetapi yang terbaik adalah konsisten.

### Apa yang harus saya lakukan jika komit sesuai dengan lebih dari satu tipe komit?

Kembalilah dan buat beberapa komit kapan pun memungkinkan. Bagian dari manfaat Conventional Commits adalah kemampuannya mendorong kami untuk membuat komitmen dan PR yang lebih terorganisir.

### Tidakkah ini menghambat pengembangan yang cepat dan iterasi yang cepat?

Ini mencegah bergerak cepat dengan cara yang tidak teratur. Ini membantu Anda dapat bergerak cepat jangka panjang di berbagai proyek dengan kontributor yang bervariasi.

### Mungkinkah Komitmen Konvensional membuat pengembang membatasi jenis komitmen yang mereka buat karena mereka akan memikirkan jenis yang disediakan?

Komitmen Konvensional mendorong kita untuk membuat lebih banyak jenis komitmen tertentu seperti perbaikan. Selain itu, fleksibilitas Komitmen Konvensional memungkinkan tim Anda untuk membuat tipe mereka sendiri dan mengubah tipe-tipe itu seiring waktu.

### Bagaimana ini berhubungan dengan SemVer?

Komit tipe `fix` harus diterjemahkan ke rilis `PATCH`. Komit tipe `feat` harus diterjemahkan ke rilis `MINOR`. Komit dengan `BREAKING CHANGE` dalam komit, apa pun jenisnya, harus diterjemahkan ke rilis `MAJOR`.

### Bagaimana cara saya memberi versi ekstensi saya ke Spesifikasi Komitmen Konvensional, mis. `@jameswomack/commit-spec-konvensional`?

Kami sarankan menggunakan SemVer untuk merilis ekstensi Anda sendiri ke spesifikasi ini (dan
mendorong Anda untuk membuat ekstensi ini!)

### Apa yang harus saya lakukan jika saya secara tidak sengaja menggunakan tipe komit yang salah?

#### Saat Anda menggunakan jenis yang memiliki spesifikasi tetapi bukan jenis yang benar, misalnya, `fix` bukan `feat`

Sebelum menggabungkan atau merilis kesalahan, sebaiknya gunakan `git rebase -i` untuk mengedit riwayat komit. Setelah rilis, pembersihan akan berbeda sesuai dengan alat dan proses apa yang Anda gunakan.

#### Saat Anda menggunakan jenis *bukan* spesifikasi, mis. `feet` bukannya `feat`

Dalam skenario terburuk, ini bukan akhir dunia jika komit mendarat yang tidak memenuhi spesifikasi conventional commit. Ini berarti komit akan dilewatkan oleh alat yang didasarkan pada spesifikasi.

### Apakah semua kontributor saya perlu menggunakan spesifikasi commit konvensional?

Tidak! Jika Anda menggunakan alur kerja berbasis squash di pengelola Git dapat membersihkan pesan komit saat mereka digabung — menambahkan tidak ada beban kerja ke komuter biasa.
Alur kerja umum untuk ini adalah membuat sistem git Anda secara otomatis squash melakukan dari permintaan tarikan dan menyajikan formulir bagi pengelola utama untuk memasukkan pesan git commit yang tepat untuk penggabungan.

---

## File: content/v1.0.0-beta.4/index.it.md

---
draft: false
aliases: ["/it/"]
---

# Commit Convenzionali 1.0.0-beta.4

## Riepilogo

La specifica Conventional Commits è una convenzione semplice da implementare per i messaggi dei commit.
Fornisce un insieme di semplici regole per la creazione di una cronologia di commit esplicita;
il che rende più facile utilizzare strumenti per automare processi.
Questa convenzione si completa con [SemVer](http://semver.org),
descrivendo le funzionalità, la risoluzione di errori e l'introduzione di breaking changes fatte dei commit.


I messaggi dei commit dovrebbero seguire la seguente struttura:

---

```
<tipo>[contesto opzionale]: <descrizione>

[corpo opzionale]

[piè di pagina opzionale]
```
---


Il commit contiene i seguenti elementi strutturali, allo scopo di comunicare l'intento al consumatore della libreria:

1. **fix:** un commit di _tipo_ `fix` risolve un errore nel codice (correlato al [`PATCH`](http://semver.org/#summary) in un versionamento semver).
1. **feat:**  un commit di _tipo_ `feat` introduce una nuova funzionalità al codice (correlato al [`MINOR`](http://semver.org/#summary) in un versionamento semver).
1. **BREAKING CHANGE:** un commit che contiene il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`MAJOR`](http://semver.org/#summary) in un versionamento semver).
Una _BREAKING CHANGE_ può essere parte di un commit di qualsiasi _tipo_.
1. Extra: sono ammessi ulteriori _tipi_ oltre `fix:` e`feat:`, per esempio [commitlint-config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (che si basa sulla [convenzione Angular](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)) raccomanda `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, ed altri.
Raccomandiamo anche `improvement` per commit che migliorano un'implementazione esistente senza aggiungere nuove funzionalità o risolvere un errore.
Notare che questi _tipi_ non sono mantenuti da questa specifica, e non hanno un effetto sul versionamento semver (a meno che non introducano una _BREAKING CHANGE_).

Un _contesto_ potrebbe essere aggiunto al _tipo_ di commit, al fine di offrire ulteriori informazioni contestuali.
Da aggiungere tra delle parentesi tonde, Es: `feat(parser): add ability to parse arrays`.

## Esempi

### Messaggio di un commit con una _descrizione_ e una breaking change nel _corpo_
```
feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files
```

### Messaggio di un commit con un opzionale `!` per attirare l'attenzione su una breaking change
```
chore!: drop Node 6 from testing matrix

BREAKING CHANGE: dropping Node 6 which hits end of life in April
```

### Messaggio di un commit senza una _descrizione_
```
docs: correct spelling of CHANGELOG
```

### Messaggio di un commit con uno _contesto_
```
feat(lang): added polish language
```

### Messaggio di un commit per un `fix` utilizzando il numero della issue (opzionale)
```
fix: minor typos in code

see the issue for details on the typos fixed

fixes issue #12
```

## Specifica

Le parole “DEVE”, “NON DEVE”, “RICHIESTO”, “DOVRÀ”, “NON DOVRÀ”, “DOVREBBE”, “NON DOVREBBE”, “RACCOMANDATO”, “POTREBBE” e “OPZIONALE” devo essere interpretata come da specifica [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).

1. Un commit DEVE iniziare con un _tipo_, il quale consiste in un sostantivo, `feat`, `fix`, etc., e DEVE essere seguito dai due punti ed uno spazio.
1. Il _tipo_ `feat` DEVE essere usato quando un commit aggiunge una funzionalità all'applicazione o libreria.
1. Il _tipo_ `fix` DEVE essere usato quando un commit corregge un errore all'applicazione o libreria.
1. Un _contesto_ opzionale POTREBBE essere fornito dopo il _tipo_.
   Un _contesto_ rappresenta una sezione dell'applicazione o della libreria, il contenuto va racchiuso tra parentesi.
   Es: `fix(parser):`
1. Una _descrizione_ DEVE seguire immediatamente il _tipo_ (con eventuale _contesto_).
   Per _descrizione_ si intende una breve spiegazione riguardo la modifica al codice.
   Es: _fix: array parsing issue when multiple spaces were contained in string._
1. Un _corpo_ del commit più lungo POTREBBE essere aggiunto dopo una breve _descrizione_, aggiungendo ulteriori informazioni contestuali riguardo le modifiche apportate al codice.
   Il _corpo_ DEVE iniziare dopo una linea vuota dalla _descrizione_.
1. Un _piè di pagina_ POTREBBE essere aggiunto inserendo una linea vuota dopo il _corpo_.
   Il _piè di pagina_ DOVREBBE contenere ulteriori informazioni riguardo le modifiche apportate al codice (come le issue che risolve,
   Es: `fixes #13, #5`).
1. Una _breaking changes_ DEVE essere indicata all'inizio delle sezioni _piè di pagina_ o del _corpo_ del commit.
   Una _breaking change_ DEVE essere scritta in maiuscolo `BREAKING CHANGE`, seguita dai due punti ed uno spazio.
1. Una descrizione DEVE essere aggiunta dopo il testo `BREAKING CHANGE: `, descrivendo il cambiamento delle API.
   Es: _BREAKING CHANGE: environment variables now take precedence over config files._
1. Il _piè di pagina_ DEVE solo contenere `BREAKING CHANGE`, collegamenti esterni, riferimenti alle issueed ulteriori meta-informazioni.
1. Un commit POTREBBE utilizzare altri _tipi_ al di fuori di `feat` e `fix` nel messaggio.
1. La convenzione NON DEVE tener conto del maiuscolo o minuscolo, ad eccezione di `BREAKING CHANGE` che DEVE sempre essere maiuscolo.
1. Un `!` POTREBBE essere aggiunti prima del prefisso`:` nel _tipo_/_contesto_, per attirare notificare l'introduzione di una breaking change. `BREAKING CHANGE: description` DEVE essere aggiungto nel _copro_ o _piè di pagina_ se un `!` è presente.

## Perchè utilizzare commit convenzionali

* CHANGELOG generati automaticamente.
* Determina automaticamente l'incremento di un versionamento semver (basandosi sui tipi di commit utilizzati).
* Comunica la natura dei cambiamenti a colleghi, pubblico, o altri parti interessate.
* Attiva build e processi di rilascio.
* Rendi più semplice alle persone contribuire al tuo progetto, dando la possibilità di esplorare una cronologia di commit più strutturata.

## FAQ

### Come dovrei comportarmi con i messaggi dei commit nella fase iniziale del progetto?

Raccomandiamo di procedere come se il tuo prodotto sia già stato rilasciato. Tipicamente *qualcuno*, anche i tuoi colleghi, stanno utilizzando il tuo software. Loro vorranno sapere cosa sia stato risolto, cosa si sia rotto etc.

### I _tipi_ devono essere in maiuscolo o minuscoli?

Si possono utilizzare entrambi, ma si raccomanda di essere consistenti ed utilizzarne solamente uno.

### Cosa faccio se il tipo di commit è conforme a più di un tipo?

Torna indietro e dividi in più commit dove puoi. Parte del beneficio di usare Commit Convenzionali è quello di spingerti a fare commit e pull request organizzate meglio.

### Non scoraggia sviluppo ed iterazioni rapidi?

Scoraggia a farlo in una maniere disorganizzata. Inoltre ti aiuterà a muoverti più velocemente su più progetti con diversi contributori.

### Potrebbe Commit Convenzionali limitare gli sviluppatori a fare solamente alcuni tipi commit perchè penseranno nei tipi forniti dalla specifica?

Commit Convenzionali ti incoraggia nel fare più di certi tipi di commit. Inoltre la flessibilità di Commit Convenzionali consente al tuo team di inventare i propri tipi e cambiarli nel tempo.

### Come si collega a SemVer?

I commit di tipo `fix` dovrebbero essere traducibili ai rilasci `PATCH`.
I commit di tipo `feat` dovrebbero essere traducibili ai rilasci `MINOR`.
I commit con `BREAKING CHANGE`, indipendentemente dal tipo, dovrebbero essere traducibili ai rilasci `MAJOR`.

### Come dovrei versionare le mie estensioni per la specifica Commit Convenzionali? (Es: `@jameswomack/conventional-commit-spec`)

Raccomandiamo l'utilizzo di SemVer per rilasciare la tua estensione (crea delle estensioni!)

### Cosa faccio se accidentalmente utilizzo un tipo di commit sbagliato?

#### Quando usi un tipo della specifica ma non quello giusto (Es: `fix` invece di `feat`)

Se ancora devi creare il merge o il rilascio dell'errore, raccomandiamo l'utilizzo di `git rebase -i` per riscrivere la cronologia dei commit. Nel caso ti abbia già rilasciato questa correzione dipende dai tool e processi che usi.

#### Quando usi un tipo *non* della specifica (Es: `feet` invece di `feat`)

Non è la fine del mondo se un commit non segue la specifica Commit Convenzionali. Semplicemente il commit verrà ignorato dai tool che sono basati su questa specifica.

### Devono tutti i contributori seguire la specifica Commit Convenzionali?

No. Se usi un workflow basato sugli squash di Git, i mantenitori possono pulire i messaggi dei commit mentre vengono inseriti nel branch principale (merge), non aggiungendo alcun carico di lavoro ai committer occasionali. Un workflow comune è quello di unire (con lo squash) automaticamente i commit dalle pull request e far utilizzare un form ai mantenitori per riscrivere un messaggio più adeguato.

---

## File: content/v1.0.0-beta.4/index.ja.md

---
draft: false
aliases: ["/ja/"]
---

# Conventional Commits 1.0.0-beta.4

## 概要

Conventional Commitsの仕様は、コミットメッセージのための軽量の規約です。
明示的なコミット履歴を作成するための簡単なルールを提供します、この規則に従うことで自動化ツールの導入を簡単にします。
この規約は[SemVer](http://semver.org)と組み合わせることで、コミットメッセージへ機能、修正、重大な変更を入れることで、さらに詳細な説明を可能にします。

コミットメッセージは次のような形にする必要があります

---

原文：

```
<type>[optional scope]: <description>

[optional body]

[optional footer]
```

訳：

```
<型>[任意 範囲]: <説明>

[任意 本文]

[任意 脚注]
```

---



コミットにはあなたのライブラリの利用者に思想を伝えるために、次の構造要素を持ちます：

1. **fix:** _型_ `fix` はコードベースのバグにパッチを当てる場合です。（これは セマンティックバージョン管理における[`PATCH`](http://semver.org/#summary)に相当します)
1. **feat:** _型_ `feat` はコードベースに新しい機能を追加した場合です。(これはセマンティックバージョン管理における [`MINOR`](http://semver.org/#summary)に相当します)
1. **BREAKING CHANGE:** 本体または脚注の冒頭に `BREAKING CHANGE:` という内容があるコミットは、APIの重大な変更を意味できます。(セマンティックバージョン管理における[`MAJOR`](http://semver.org/#summary)に相当します)
`BREAKING CHANGE` はあらゆる _型_ のコミットに含めることができます。

1. Others: `fix:` and `feat:` 以外のコミット _型_ を許容します、例えば  [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) ([Angularの規約](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)ベース)は  `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, などがあります。


新しい機能の追加やバグを修正ではなく、現在の実装を改善するコミットには `improvement` をおすすめします。


これらの _型_ はconventional commitsで強制されているものではなく、セマンティックバージョン管理に暗黙的な影響も与えません。（それが、BREAKING CHANGEを含めない限り）



コミットの _型_ には、追加の情報として _範囲_ を追加することができ、それは括弧で囲みます。例 `feat(parser): add ability to parse arrays`

## 例

### 説明と重大な変更を含む本文のメッセージをコミットに含める

```
feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files
```

### 重大な変更であることに気づいてもらうために `!` を付けてメッセージをコミットできる

```
chore!: drop Node 6 from testing matrix

BREAKING CHANGE: dropping Node 6 which hits end of life in April
```

### 本文無しでメッセージをコミットする

```
docs: correct spelling of CHANGELOG
```

### _範囲_ のあるメッセージをコミットする

```
feat(lang): add polish language
```

### (オプション) issueの番号を修正用のコミットメッセージに含めます

```
fix: correct minor typos in code

see the issue for details on the typos fixed

closes issue #12
```

## 仕様

この文書における次の各キーワード「しなければならない（ MUST ）」、 「してはならない（ MUST NOT ）」、「要求されている（ REQUIRED ）」、 「することになる（ SHALL ）」、「することはない（ SHALL NOT ）」、 「する必要がある（ SHOULD ）」、「しないほうがよい（ SHOULD NOT ）」、 「推奨される（ RECOMMENDED ）」、「してもよい（ MAY ）」、 「選択できる（ OPTIONAL ）」は、 [RFC 2119 (JPNIC 日本語)](https://www.nic.ad.jp/ja/tech/ipa/RFC2119JA.html) で述べられているように 解釈されるべきものです。

1. コミットは _型_ から始まり、次に選択できる（ OPTIONAL ） _範囲_ と、末尾に要求されている（ REQUIRED ）コロンとスペースで成り立ちます。
1. コミットがあなたのアプリケーションやライブラリに新しい機能を追加するとき、 _型_ は`feat`にしなければならない（ MUST ）。
1. コミットがあなたのアプリケーションのためのバグ修正を表すとき、 _型_ は `fix`にしなければならない（ MUST ）。
1. _範囲_ は _型_ の後に記述してもよい（ MAY ）。 _範囲_ は括弧で囲まれたコードベースのセクションを記述する名詞にしなければならない（ MUST ）。例： `fix(構文解析ツール): '
1. _説明_ は型/範囲の直後にしなければならない（ MUST ）。
_説明_ はコード変更の要約です。 _fix：文字列に複数の空白がある場合の配列解析における問題_
1. 短い _説明_ の後に、より長いコミットの本文を追加してもよく（ MAY ）、コード変更に関する追加の情報を提供することができます。
本文は、_説明_ の下に1行の空行を追加しなければならない（ MUST ）。
1. 1行以上の _脚注_ は、本文の後ろに1行の空白行を入れてもよい（ MAY ）。 _脚注_ はコミットに関するメタ情報、例えば関連するプルリクエスト、レビュアー、変更の中断などを1行につき1つのメタ情報として含めなければならない（ MUST ）。
1. 重大な変更(`BREAKING CHANGE`)は、本文セクションの一番最初、または脚注の先頭にしなければいけません（ MUST ）。
重大な変更は大文字のテキスト `BREAKING CHANGE` と続くコロンとスペースから構成されなければいけません（ MUST ）。
1. APIについて何が変わったのかを説明する`BREAKING CHANGE:`の後には説明を書かなければいけません（ MUST ）。
例、 _BREAKING CHANGE: 環境変数が設定ファイルよりも優先されるようになりました。_
1. `feat`と`fix` 以外の _型_ をあなたのコミットメッセージに仕様してもよい（ MAY ）。
1. Conventional Commitsを構成する情報の単位は、必ず大文字の`BREAKING CHANGE`を除いて、実装側は大文字と小文字を別の物して扱ってはいけない（ MUST NOT ）
1. さらに重大な変更の注意を引くために、  _種類_ / _範囲_ の `:` の前に `!`を追加することができます（ MAY ）。`BREAKING CHANGE: description`は、接頭辞の`!`とともに、本文または脚注にも含めなければなりません（ MUST ）。

## 何故 Conventional Commits を使うのか

* 変更履歴(CHANGELOG)を自動的に生成できます。
* semantic version単位で自動的に履歴を纏めれます（コミットされた _型_ に基づきます）。
* チームメイトや一般のユーザー、およびその他の利害関係者へ変更の内容を伝えることができる。
* ビルドおよび公開プロセスをトリガーにできます。
* より構造化されたコミット履歴を調査できるようにすることで、人々があなたのプロジェクトに貢献しやすくなります。

## よくある質問

### 初期の開発段階ではコミットメッセージをどのように扱うべきですか？

すでに製品をリリースしているかのように進めることをお勧めします。
あなたの仲間のソフトウェア開発者であっても、普通は *誰か* があなたのソフトウェアを使っています。
何が修正されたのか、何が壊れたのかなどを知りたいでしょう。

### コミットタイトル(1行目)の型は大文字か小文字のどちらが良いですか？

どちらでも問題はありません、一貫性を保つことが最善です。

### コミットが複数のコミットタイプ( _型_ )に準拠している場合はどうすればいいですか？

可能な限り前に戻り複数のコミットに分割します。
Conventional Commits の利点の一つは、より組織化されたコミットとプルリクエストを行う事を可能にする事です。

### これは開発速度とインテグレーションを遅くしたりはしませんか？

無秩序にただ早く開発することはお勧めではありません。
それはあなたがさまざまな貢献者との複数のプロジェクト間で長期的に素早く動けるようにするのを助けます。

### Conventional Commitsで開発者は提供された _型_ を検討することになるため、コミットの _型_ を制限することができますか？

Conventional Commitsは、修正などの特定の _型_ のコミットメントを行うように促します。
それ以外の点では、Conventional Commitsの柔軟性により、あなたのチームは彼ら自身の _型_ を新しく作り、時間の経過とともにそれらの _型_ を変更することもできます。

### これはSemVerとどのような関係を持っていますか？

`fix` _型_ のコミットは`PATCH`リリースへ変換します。 `feat` _型_ のコミットは`MINOR`リリースに変換します。 _型_ にかかわらずコミット内で `BREAKING CHANGE`を使ったコミットは`MAJOR`リリースに変換するべきでしょう。

### 私の拡張仕様をどのようにしてConventional Commitsの仕様にバージョンアップするべきでしょうか？、例： `@jameswomack/conventional-commit-spec`

SemVerを使用して、この仕様に対する独自の拡張仕様をリリースすることをお勧めします（そしてこれらの拡張仕様を作成することをお勧めします）。

### 間違ったコミットタイプを使用してしまった時はどうしたらいいですか？

#### 仕様的に正しい型だが意味を間違った _型_ を使用した場合、例えば `feat`の代わりに`fix`

間違いをマージやリリースする前に、コミット履歴を編集する`git rebase -i`を使うことを勧めます。
リリース後、どのツールやプロセスを使用するかによってクリーンアップは異なってくるでしょう。

#### 仕様に *ない* _型_ を使った時、例えば`feat` ではなく`feet`

最悪のシナリオはコミットが conventional commit の仕様を満たさない場合です、しかしそれは世界の終わりではありません。
それは単に仕様に基づいているツールによってコミットが見逃されるだけでしかありません。

### 貢献者全員が conventional commit を使用する必要がありますか？

いいえ！ Gitでsquashベースのワークフローを使用するなら、主要メンテナはマージ時にコミットメッセージをクリーンアップすることができるため、通常のコミッタには作業負荷がかかりません。
また一般的なワークフローの場合は、あなたのgitシステムが自動的にpull requestからコミットを破棄し、主要メンテナにマージのための適切なgit commitメッセージを入力するためのフォームを提示することです。

---

## File: content/v1.0.0-beta.4/index.ko.md

---
draft: false
aliases: ["/ko/"]
---

# Conventional Commits 1.0.0-beta.4

## 개요

Conventional Commits 스펙은 커밋 메시지에 곁들여진 가벼운 컨벤션으로 명확한 커밋 히스토리를 생성하기 위한 간단한 규칙을 제공합니다. 이렇게 만들어진 커밋 히스토리를 이용하여 더 쉽게 자동화된 도구를 만들 수 있습니다.
이 컨벤션은 커밋 메세지에 신규 기능 추가, 문제 수정, 커다란 변화가 있음을 기술함으로써 [유의적 버전(Semantic Versioning)](https://semver.org/lang/ko/)과 일맥상통한 면이 있습니다.

커밋 메세지는 다음과 같은 구조가 되어야 합니다:

---

```
<타입>[적용 범위(선택 사항)]: <설명>

[본문(선택 사항)]

[꼬리말(선택 사항)]
```
---



커밋에는 라이브러리를 사용하는 사람들에게 의도를 전달하기 위해 다음과 같은 구조적 요소가 포함되어 있습니다.

1. **fix:** 코드베이스에서 버그를 패치하는 `fix` _타입_ 의 커밋 (이는 유의적 버전에서의 [`PATCH`](http://semver.org/#summary)와 관련이 있습니다).
1. **feat:** 코드베이스에서 새 기능이 추가되는 `feat` _타입_ 의 커밋 (이는 유의적 버전에서의 [`MINOR`](http://semver.org/#summary)와 관련이 있습니다).
1. **BREAKING CHANGE:** 본문이나 꼬리말의 시작 부분에 `BREAKING CHANGE:`이라는 문자열을 가진 커밋은 커다란 API 변경 있다는 것을 의미합니다 (이는 유의적 버전에서의 [`MAJOR`](http://semver.org/#summary)와 관련이 있습니다). 어떤 커밋 타입이라도 BREAKING CHANGE는 해당 커밋의 일부가 될 수 있습니다.
1. 다른 타입: `fix:`와 `feat:` 이외의 커밋 타입을 말합니다, 예를 들어 [앵귤러 컨벤션](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)을 기반으로 하는 [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional)에서는 `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:` 등의 타입을 사용할 것을 권고하고 있습니다.

또한, 새로운 기능이나 버그 수정없이 현재 구현체를 개선하는 커밋에 대해서는 `improvement`을 사용하는 것이 좋습니다. 이 타입은 BREAKING CHANGES를 포함하지 않는 한 Conventional Commits 스펙에 의해 강제되는 부분은 아니고 유의적 버전에도 암묵적 영향을 가지지 않습니다.

추가적인 문맥 정보를 제공하기 위한 목적으로 사용되는 적용 범위는 커밋의 타입에 덧붙여질 수 있는데 괄호 안에 포함됩니다, 예를 들면, `feat(parser): add ability to parse arrays`.

## 예제

### 본문에 설명과 BREAKING CHANGE를 가지는 커밋 메세지
```
feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files
```

### BREAKING CHANGE에 주의를 주기 위해 옵션인 `!`를 포함한 커밋 메세지
```
chore!: drop Node 6 from testing matrix

BREAKING CHANGE: dropping Node 6 which hits end of life in April
```

### 본문이 없는 커밋 메세지
```
docs: correct spelling of CHANGELOG
```

### 적용 범위를 가지는 커밋 메세지
```
feat(lang): add polish language
```

### 옵션인 이슈 번호를 가진 fix 타입의 커밋 메세지
```
fix: correct minor typos in code

see the issue for details on the typos fixed

closes issue #12
```

## 규격

이 문서에서 언급되는 주요 단어들인 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, 그리고 “OPTIONAL”는 [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt)에 기술된 그대로 해석해야 합니다.

1. 모든 커밋은 `feat`, `fix` 같은 명사로 된 접두어를 포함해야 하고 그 뒤로 옵션인 적용 범위, 그리고 필수인 `:`과 공백이 있어야 합니다.
1. `feat` 타입은 커밋에 애플리케이션이나 라이브러리에 새로운 기능이 추가될 때 사용되어야 합니다.
1. `fix` 타입은 커밋에 애플리케이션의 버그 수정을 하는 내용을 포함하는 경우에 사용되어야 합니다.
1. 적용 범위는 타입 다음에 기술하는데 이는 코드베이스가 적용되는 영역을 기술하는 명사로 괄호로 감싸져야 합니다, 예를 들어, `fix(parser):`
1. 설명은 타입/적용 범위 접두어 뒤에 있는 공백 다음에 작성되어야 합니다. 설명은 코드 변경 사항에 대한 짧은 요약입니다, 예를 들어, _fix: array parsing issue when multiple spaces were contained in string._
1. 긴 커밋 본문은 짧은 설명 다음에 위치하는데 코드 변경 사항에 대한 추가적인 문맥적인 정보를 제공합니다. 본문은 반드시 설명 다음에 빈 행으로 시작해야 합니다.
1. 한 줄 이상을 가진 꼬리말은 본문 다음 빈 행 다음에 위치합니다. 꼬리말은 커밋에 대한 메타 정보를 포함해야 합니다. 예를 들어, 한 줄에 하나의 메타 정보로 관련 있는 PR, 리뷰어, BREAKING CHANGES를 포함합니다.
1. Breaking changes는 본문 영역의 시작이나 꼬리말 영역의 시작 부분에 위치합니다. Breaking changes는 대문자로 된 BREAKING CHANGE 문자열을 포함하고 그 뒤로 콜론과 공백이 옵니다.
1. 설명은 반드시 `BREAKING CHANGE: ` 다음에 와야 하는데 이는 API에서 변경된 사항을 기술해야 합니다, 예를 들어, _BREAKING CHANGE: environment variables now take precedence over config files._
1. `feat`와 `fix` 이외의 타입이 커밋 메세지에 사용될 수 있습니다.
1. Conventional Commit을 구성하는 정보의 단위는 반드시 문자이어야 하는 BREAKING CHANGES를 제외하고 구현자에 의해 대소문자를 구분하는 것으로 처리되어서는 안됩니다.
1. `!`는 타입/적용 범위 접두어에서 `:` 앞에 붙어야 하는데 큰 변화에 대한 주의를 주기 위함입니다. `BREAKING CHANGE: description`는 반드시 접두어에 `!`와 함께 본문이나 꼬리말에 포함되어야 합니다.

## 왜 Conventional Commits를 사용할까요?

* CHANGELOG를 자동으로 생성하기 위해서
* (포함된 커밋의 타입에 기반하여) 유의적 버전을 자동으로 변경하기 위해서
* 팀 동료, 타인, 그리고 기타 이해당사자에게 변화의 본질을 전달하기 위해서
* 빌드와 배포 프로세스를 수행하기 위해서
* 더 구조화된 커밋 히스토리를 보여줘서 사람들이 프로젝트에 기여하기 더 쉽도록 하기 위해서

## FAQ

### 초기 개발 단계에서 커밋 메세지를 어떻게 다루어야 하나요?

제품을 이미 출시한 것처럼 진행하세요. 일반적으로 *누군가* 는 여러분의 소프트웨어를 사용하고 있는데 그게 동료 개발자일 수도 있고 그들은 무엇이 고쳐졌는지, 무엇이 문제인지 등을 알고 싶어 할 것입니다.

### 커밋 제목에서 타입은 대문자로 쓰나요 소문자로 쓰나요?

대소문자 구분은 없지만 일관되게 사용하는 것이 좋습니다.

### 커밋이 커밋 타입 중 하나 이상에 해당하는 경우 어떻게 해야 하나요?

가능하면 돌아가서 여러 개의 커밋으로 쪼개세요. Conventional Commits의 이점 중 하나는 우리가 보다 조직화된 커밋과 PR을 만들도록 유도하는 능력입니다.

### Conventional Commits가 빠른 개발과 빠른 반복을 방해하지 않나요?

Conventional Commits는 무질서한 방법으로 빨리 움직이는 것을 지양하고 다양한 기여자들을 가진 여러 프로젝트에서 장기적으로 빠르게 이동할 수 있도록 도와줍니다.

### Conventional Commits가 개발자들로 하여금 제공된 타입안에서 생각하게 되기 때문에 그들이 만든 커밋의 타입을 제한하도록 유도할 수 있을까요?

Conventional Commits는 fix 같은 특정 종류의 커밋 타입을 더 많이 만들도록 장려하고 있습니다. 그 외에도, Conventional Commits의 유연성은 여러분의 팀이 그들만의 타입을 고안하고 시간이 지남에 따라 그 타입을 바꿀 수 있게 해줍니다.

### 이것이 SemVer와 어떤 관련이 있나요?

`fix` 타입의 커밋은 PATCH 버전으로 번역해야 합니다. `feat` 형식 커밋은 MINOR 버전으로 번역해야 합니다. 타입과 관계없이 BREAKING CHANGE를 포함한 커밋은 MAJOR(MAJOR)로 번역해야 한다.

### Conventional Commit 스펙을 개인적으로 확장한 형태의 버전을 어떻게 사용할 수 있을까요? 예를 들어, `@jameswomack/conventional-commit-spec`

SemVer를 사용해서 이 규격에 대한 사용자 자신의 확장판을 릴리즈할 것을 추천하며, 이러한 확장하여 사용하는 것을 권장합니다!

### 실수로 잘못된 커밋 타입을 사용하면 어떻게 해야 하나요?

#### 스펙에 맞는 타입을 사용하고 있지만 올바른 타입이 아닌 경우, 예를 들어, `feat` 대신 `fix`

실수를 병합 또는 리베이스하기 전에, `git rebase -i`를 사용하여 커밋 히스토리를 편집할 것을 권장합니다. 릴리즈 후에는 사용하는 툴과 프로세스에 따라 정리하는 방법이 다를 수 있습니다.

#### 스펙에 맞지 않은 타입을 사용하는 경우, 예를 들어, `feat` 대신 `feet`

최악의 경우, Conventional Commit 규격을 충족하지 않는 커밋이 추가되었다고 해서 그것이 세계의 종말을 의미하지 않습니다. 이는 커밋이 단순히 규격을 기반으로 하는 툴에 의해 누락된다는 것을 의미합니다.

### 모든 기여자가 Conventional Commit 규격을 사용해야 하나요?

아니요! Git을 기반으로 스쿼시를 사용하는 경우, 리드 유지관리자는 커밋된 메시지를 병합할 때 정리할 수 있으므로 일반 커밋자에 작업량이 추가되지 않습니다.
이에 대한 일반적인 작업 흐름은 Git 시스템이 자동으로 풀 요청에서 커밋되도록 하고 리드 유지관리자가 병합에 대한 적절한 Git 커밋 메시지를 입력할 수 있는 양식을 제시하도록 하는 것입니다.

---

## File: content/v1.0.0-beta.4/index.md

---
draft: false
aliases: ["/en/"]
---

# Conventional Commits 1.0.0-beta.4

## Summary

The Conventional Commits specification is a lightweight convention on top of commit messages.
It provides an easy set of rules for creating an explicit commit history;
which makes it easier to write automated tools on top of.
This convention dovetails with [SemVer](http://semver.org),
by describing the features, fixes, and breaking changes made in commit messages.

The commit message should be structured as follows:

---

```
<type>[optional scope]: <description>

[optional body]

[optional footer]
```
---


The commit contains the following structural elements, to communicate intent to the
consumers of your library:

1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with [`PATCH`](http://semver.org/#summary) in semantic versioning).
1. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates with [`MINOR`](http://semver.org/#summary) in semantic versioning).
1. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) in semantic versioning).
A BREAKING CHANGE can be part of commits of any _type_.
1. Others: commit _types_ other than `fix:` and `feat:` are allowed, for example [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (based on the [Angular convention](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit)) recommends `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.

We also recommend `improvement` for commits that improve a current implementation without adding a new feature or fixing a bug.
Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE).

A scope may be provided to a commit's type, to provide additional contextual information and is contained within parenthesis, e.g., `feat(parser): add ability to parse arrays`.

## Examples

### Commit message with description and breaking change in body
```
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 message with optional `!` to draw attention to breaking change
```
chore!: drop Node 6 from testing matrix

BREAKING CHANGE: dropping Node 6 which hits end of life in April
```

### Commit message with no body
```
docs: correct spelling of CHANGELOG
```

### Commit message with scope
```
feat(lang): add polish language
```

### Commit message for a fix using an (optional) issue number.
```
fix: correct minor typos in code

see the issue for details on the typos fixed

closes issue #12
```

## Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).

1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc., followed
  by an OPTIONAL scope, and a REQUIRED terminal colon and space.
1. The type `feat` MUST be used when a commit adds a new feature to your application or library.
1. The type `fix` MUST be used when a commit represents a bug fix for your application.
1. A scope MAY be provided after a type. A scope MUST consist of a noun describing a
  section of the codebase surrounded by parenthesis, e.g., `fix(parser):`
1. A description MUST immediately follow the space after the type/scope prefix.
The description is a short summary of the code changes, e.g., _fix: array parsing issue when multiple spaces were contained in string._
1. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
1. A footer of one or more lines MAY be provided one blank line after the body. The footer MUST contain meta-information
about the commit, e.g., related pull-requests, reviewers, breaking changes, with one piece of meta-information
per-line.
1. Breaking changes MUST be indicated at the very beginning of the body section, or at the beginning of a line in the footer section. A breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon and a space.
1. A description MUST be provided after the `BREAKING CHANGE: `, describing what has changed about the API, e.g., _BREAKING CHANGE: environment variables now take precedence over config files._
1. Types other than `feat` and `fix` MAY be used in your commit messages.
1. The units of information that make up conventional commits MUST NOT be treated as case-sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.
1. A `!` MAY be appended prior to the `:` in the type/scope prefix, to further draw attention to breaking changes. `BREAKING CHANGE: description` MUST also be included in the body
or footer, along with the `!` in the prefix.

## Why Use Conventional Commits

* Automatically generating CHANGELOGs.
* Automatically determining a semantic version bump (based on the types of commits landed).
* Communicating the nature of changes to teammates, the public, and other stakeholders.
* Triggering build and publish processes.
* Making it easier for people to contribute to your projects, by allowing them to explore
  a more structured commit history.

## FAQ

### How should I deal with commit messages in the initial development phase?

We recommend that you proceed as if you've already released the product. Typically *somebody*, even if it's your fellow software developers, is using your software. They'll want to know what's fixed, what breaks etc.

### Are the types in the commit title uppercase or lowercase?

Any casing may be used, but it's best to be consistent.

### What do I do if the commit conforms to more than one of the commit types?

Go back and make multiple commits whenever possible. Part of the benefit of Conventional Commits is its ability to drive us to make more organized commits and PRs.

### Doesn’t this discourage rapid development and fast iteration?

It discourages moving fast in a disorganized way. It helps you be able to move fast long term across multiple projects with varied contributors.

### Might Conventional Commits lead developers to limit the type of commits they make because they'll be thinking in the types provided?

Conventional Commits encourages us to make more of certain types of commits such as fixes. Other than that, the flexibility of Conventional Commits allows your team to come up with their own types and change those types over time.

### How does this relate to SemVer?

`fix` type commits should be translated to `PATCH` releases. `feat` type commits should be translated to `MINOR` releases. Commits with `BREAKING CHANGE` in the commits, regardless of type, should be translated to `MAJOR` releases.

### How should I version my extensions to the Conventional Commits Specification, e.g. `@jameswomack/conventional-commit-spec`?

We recommend using SemVer to release your own extensions to this specification (and
encourage you to make these extensions!)

### What do I do if I accidentally use the wrong commit type?

#### When you used a type that's of the spec but not the correct type, e.g. `fix` instead of `feat`

Prior to merging or releasing the mistake, we recommend using `git rebase -i` to edit the commit history. After release, the cleanup will be different according to what tools and processes you use.

#### When you used a type *not* of the spec, e.g. `feet` instead of `feat`

In a worst case scenario, it's not the end of the world if a commit lands that does not meet the conventional commit specification. It simply means that commit will be missed by tools that are based on the spec.

### Do all my contributors need to use the conventional commit specification?

No! If you use a squash based workflow on Git lead maintainers can clean up the commit messages as they're merged—adding no workload to casual committers.
A common workflow for this is to have your git system automatically squash commits from a pull request and present a form for the lead maintainer to enter the proper git commit message for the merge.

---

## File: content/v1.0.0-beta.4/index.pt-br.md

---
draft: false
aliases: ["/pt-br/"]
---

# Conventional Commits 1.0.0-beta.4

## Resumo

A especificação do Conventional Commits é uma convenção simples para utilizar nas
mensagens de commit.
Ela define um conjunto de regras para criar um histórico de commit
explícito, o que facilita a criação de ferramentas automatizadas.
Esta convenção segue o [SemVer](https://semver.org),
descrevendo os recursos, correções e modificações que quebram a compatibilidade
nas mensagens de commit.

A mensagem do commit deve ser estruturada da seguinte forma:

---

```
<tipo>[escopo opcional]: <descrição>

[corpo opcional]

[rodapé opcional]
```
---


O commit contém os seguintes elementos estruturais, para comunicar a intenção ao
utilizador da sua biblioteca:

1. **fix:** um commit do _tipo_ `fix` soluciona um problema na sua base de código
 (isso se correlaciona com [`PATCH`](https://semver.org/lang/pt-BR/#sum%C3%A1rio) do versionamento semântico).
1. **feat:** um commit do _tipo_ `feat` inclui um novo recurso na sua base
 de código (isso se correlaciona com [`MINOR`](https://semver.org/lang/pt-BR/#sum%C3%A1rio) do versionamento semântico).
1. **BREAKING CHANGE:** um commit que contém o texto `BREAKING CHANGE:`, no começo
 do texto do corpo opcional ou do rodapé opcional, inclui uma modificação que quebra
 a compatibilidade da API (isso se correlaciona com [`MAJOR`](https://semver.org/lang/pt-BR/#sum%C3%A1rio)
 do versionamento semântico). Uma BREAKING CHANGE pode fazer parte de commits de qualquer _tipo_.
1. Outros: _tipos_ adicionais são permitidos além de `fix:` e `feat:`, por exemplo
 [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional)
 (baseado na [Convenção do Angular](https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit))
 recomenda-se `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, entre outros.

Também recomendamos `improvement` para commits que melhoram uma implementação
 atual sem adicionar um novo recurso ou consertar um bug.
 Observe que esses tipos não são obrigatórios pela especificação do Conventional
 Commits e não têm efeito implícito no versionamento semântico (a menos que incluam
 uma BREAKING CHANGE).

Um escopo pode ser adicionado ao tipo do commit, para fornecer informações
 contextuais adicionais e está contido entre parênteses, por exemplo
 `feat(parser): adiciona capacidade de interpretar arrays`.

## Exemplos

### Mensagem de commit com descrição e modificação que quebra a compatibilidade no corpo
```
feat: permitir que o objeto de configuração fornecido estenda outras configurações

BREAKING CHANGE: a chave `extends`, no arquivo de configuração, agora é utilizada
para estender outro arquivo de configuração
```

### Mensagem de commit com `!` opcional para chamar a atenção para quebra a compatibilidade
```
chore!: remove Node 6 da matriz de testes

BREAKING CHANGE: removendo Node 6 que atinge o final de vida em Abril
```

### Mensagem de commit sem corpo
```
docs: ortografia correta de CHANGELOG
```

### Mensagem de commit com escopo
```
feat(lang): adiciona tradução para português brasileiro
```

### Mensagem de commit de uma correção utilizando número de ticket (opcional)
```
fix: corrige pequenos erros de digitação no código

veja o ticket para detalhes sobre os erros de digitação corrigidos

closes issue #12
```

## Especificação

As palavras-chaves “DEVE” (“MUST”), “NÃO DEVE” (“MUST NOT”), “OBRIGATÓRIO” (“REQUIRED”),
 “DEVERÁ” (“SHALL”), “NÃO DEVERÁ” (“SHALL NOT”), “PODEM” (“SHOULD"), “NÃO PODEM” (“SHOULD NOT”),
 “RECOMENDADO” (“RECOMMENDED”), “PODE” (“MAY”) e “OPCIONAL” (“OPTIONAL”), nesse
 documento, devem ser interpretados como descrito na [RFC 2119](http://tools.ietf.org/html/rfc2119).

1. A mensagem de commit DEVE ser prefixado com um tipo, que consiste em um
 substantivo, `feat`,` fix`, etc., seguido por um escopo OPCIONAL, e OBRIGATÓRIO
 terminar com dois-pontos e um espaço.
1. O tipo `feat` DEVE ser usado quando um commit adiciona um novo recurso ao seu
 aplicativo ou biblioteca.
1. O tipo `fix` DEVE ser usado quando um commit representa a correção de um
 problema em seu aplicativo ou biblioteca.
1. Um escopo PODE ser fornecido após um tipo. Um escopo DEVE consistir em um
 substantivo que descreve uma seção da base de código entre parênteses, por exemplo,
 `fix(parser): `
1. Uma descrição DEVE existir depois do espaço após o prefixo tipo/escopo.
 A descrição é um breve resumo das alterações de código, por exemplo,
 _fix: problema na interpretação do array quando uma string tem vários espaços._
1. Um corpo de mensagem de commit mais longo PODE ser fornecido após a descrição
 curta, fornecendo informações contextuais adicionais sobre as alterações no código.
 O corpo DEVE começar depois de uma linha em branco após a descrição.
1. Um rodapé de uma ou mais linhas PODE ser fornecido depois de uma linha em branco
 após o corpo. O rodapé DEVE conter informações adicionais sobre o commit, por exemplo,
 pull-requests, revisores, modificações que quebram a compatibilidade, com uma
 informação adicional por linha.
1. A modificação que quebra a compatibilidade DEVE ser indicadas logo no início
 da seção do corpo ou no início de uma linha na seção de rodapé. Uma modificação
 que quebra a compatibilidade DEVE consistir de um texto em maiúsculas
 BREAKING CHANGE, seguido por dois-pontos e um espaço.
1. Uma descrição DEVE ser fornecida após o texto "BREAKING CHANGE:", descrevendo
 o que mudou na API, por exemplo, _BREAKING CHANGE: as variáveis de ambiente agora
 têm preferência sobre os arquivos de configuração._
1. Além de `feat` e `fix`, outro tipo PODE ser usados em suas mensagens de commit.
1. Cada bloco de informação que compõem o commit convencional NÃO DEVE ser
 tratado como sensível a maiúscula e minúscula pelos implementadores, com exceção de
 BREAKING CHANGE, que DEVE ser maiúscula.
1. Um `!` PODE ser acrescentado antes do `:` no prefixo tipo/escopo, para chamar
 a atenção para modificações que quebram a compatibilidade. `BREAKING CHANGE: description`
 também DEVE ser incluído no corpo ou no rodapé, junto com o `!` no prefixo.

## Porque utilizar Conventional Commits

* Criação automatizada de CHANGELOGs.
* Determinar automaticamente um aumento de versionamento semântico (com base nos
 tipos de commits).
* Comunicar a natureza das mudanças para colegas de equipe, o público e outras
 partes interessadas.
* Disparar processos de build e deploy.
* Facilitar a contribuição de outras pessoas em seus projetos, permitindo que
 eles explorem um histórico de commits mais estruturado.

## Perguntas Frequentes

### Como devo lidar com mensagens de commit na fase inicial de desenvolvimento?

Recomendamos que você proceda como se já tivesse lançado o produto. Normalmente
 *alguém*, mesmo que seja seus colegas desenvolvedores, está usando
 seu software. Eles vão querer saber o que foi corrigido, o que quebra etc.

### Os tipos no título das mensagens commit são maiúsculos ou minúsculos?

Qualquer opção pode ser usada, mas é melhor ser consistente.

### O que eu faço se o commit estiver de acordo com mais de um dos tipos?

Volte e faça vários commits sempre que possível. Parte do benefício do Conventional
 Commits é a capacidade de nos levar a fazer commits e PRs mais organizados.

### Isso não desencoraja o desenvolvimento rápido e a iteração rápida?

Desencoraja a movimentação rápida de forma desorganizada. Ele ajuda você a ser capaz de se mover rapidamente a longo prazo em vários projetos com vários colaboradores.

### O Conventional Commits leva os desenvolvedores a limitar o tipo de commits que eles fazem porque estarão pensando nos tipos fornecidos?

O Conventional Commits nos encorajam a fazer mais commits de tipos específicos, por exemplo correções. Além disso, a flexibilidade do Conventional Commits permite que sua equipe crie seus próprios tipos e altere ao longo do tempo.

### Qual a relação com o SemVer?

Commits do tipo `fix` devem ser enviados para releases `PATCH`. Commits do tipo
 `feat` devem ser enviados para releases `MINOR`. Commits com `BREAKING CHANGE`
 nas mensagens, independentemente do tipo, devem ser enviados para releases `MAJOR`.

### Como devo versionar minhas extensões utilizando a especificação do Conventional Commits Specification, e.g. `@jameswomack/conventional-commit-spec`?

Recomendamos utilizar o [SemVer](http://semver.org) para liberar suas próprias
 extensões para esta especificação (e incentivamos você criar essas extensões!)

### O que eu faço se acidentalmente usar o tipo errado de commit?

#### Quando você usou um tipo da especificação, mas não do tipo correto, por exemplo `fix` em vez de `feat`

Antes do merge ou relase com o erro, recomendamos o uso de `git rebase -i` para
 editar o histórico do commit. Após o release, a limpeza será diferente de
 acordo com as ferramentas e processos que você utiliza.

#### Quando você usou um tipo que *não* é da especificação, por exemplo `feet` em vez de `feat`

Na pior das hipóteses, não é o fim do mundo se um commit não atender à
 especificação do Conventional Commits. Significa apenas que o commit será
 ignorado por ferramentas baseadas nessa especificação.

### Todos os meus colaboradores precisam usar a especificação do Conventional Commits?

Não! Se você usar um workflow de git baseado em squash, os mantenedores poderão
 limpar as mensagens de commit à medida que forem fazendo novos merges, não
 adicionando carga de trabalho aos committers casuais. Um workflow comum para
 isso é fazer com que o git faça squash dos commits automaticamente de um pull
 request e apresente um formulário para o mantenedor inserir a mensagem do commit
 apropriada para o merge.