commitlint Documentation

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

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

commitlint-config-patternplate

Alias of @commitlint/config-patternplate

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

commitlint-config-nx-scopes

Alias of @commitlint/config-nx-scopes

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

commitlint-config-lerna-scopes

Alias of @commitlint/config-lerna-scopes

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

commitlint-config-angular

Alias of @commitlint/config-angular

File: @alias/commitlint/README.md

commitlint

Alias of @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

text

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 for comprehensive documentation.

Documentation generated from docs folder.

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

@commitlint/prompt-cli

commit prompt using commitlint.config.js

Getting started

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

git add .
commit

A full usage guide is available at docs/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.
Learn how to use it in this guide.

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

text

{
  "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

text

npm install --save @commitlint/parse

Use

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

text

{
  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 for comprehensive documentation.

Documentation generated from docs folder.

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 for comprehensive documentation.

Documentation generated from docs folder.

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:

text

<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:

fix: un commit di tipo fix risolve un errore nel codice (correlato al PATCH in un versionamento semver).
feat: un commit di tipo feat introduce una nuova funzionalità al codice (correlato al MINOR in un versionamento semver).
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 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 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)
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, 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.

Un commit DEVE iniziare con un tipo, il quale consiste in un sostantivo, feat, fix, etc.,
seguito dai due punti ed uno spazio.
Il tipo feat DEVE essere usato quando un commit aggiunge una funzionalità
all'applicazione o libreria.
Il tipo fix DEVE essere usato quando un commit corregge un errore all'applicazione o libreria.
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):
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.
Un corpo del commit più lungo POTREBBE essere aggiunto dopo una breve descrizione.
Il corpo DEVE inizare dopo una linea vuota dalla descrizione.
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).
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.
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.
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:

text

<type>[optional scope]: <description>

[optional body]

[optional footer]

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

fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in semantic versioning).
feat: a commit of the type feat introduces a new feature to the codebase (this correlates
with MINOR in semantic versioning).
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 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 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) 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,
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.

commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc.,
followed by a colon and a space.
the type feat MUST be used when a commit adds a new feature to your application
or library.
the type fix MUST be used when a commit represents a bug fix for your application.
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):
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.
A longer commit body MAY be provided after the short description. The body MUST
begin one blank line after the description.
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).
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.
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.
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:

text

<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:

fix: dostarczenie typu fix naprawia błąd obecny w Twoim kodzie (powiązane z PATCH w wersjonowaniu semantycznym).
feat: dostarczenie typu feat wprowadza nowe funkcje do Twojej biblioteki (powiązane z MINOR w wersjonowaniu semantycznym).
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 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 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)
podczas naprawy.

Specyfikacja Konwencjonalnych Commitów proponuje wprowadzenie ustandaryzowanej, lekkiej
konwencji wykorzystującej wiadomości w dostarczeniach. Konwencja ta łączy się z SemVer,
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.

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.
Typ feat MUSI być użyt, gdy dostarczenie dodaje nową funkcję do Twojej aplikacji bądź bibliteki.
Typ fix MUSI być użyty, kiedy dostarczenie naprawia błąd w Twojej aplikacji.
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):
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.
Dłuższe ciało wiadomośći MOŻĘ być podane po krótkim opisie. Ciało MUSI zaczynać się jedną pustą linię po opisie.
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.
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ą.
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.
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 时，可编写标准化的提交说明。

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

text

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

[可选的正文]

[可选的页脚]

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

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

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

介绍

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

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

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

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

约定式提交规范

本文档中的关键词 “必须”、“禁止”、“需要”、“应当”、“不应当”、“应该”、“不应该”、“推荐”、“可以” 和 “可选” 应按照 RFC 2119 的描述解释。

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

text

<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:

fix: un commit de type fix corrige un bogue dans le code (cela est en corrélation avec
PATCH en versioning sémantique).
feat: un commit de type feat introduit une nouvelle fonctionnalité dans le code (cela est en corrélation avec MINOR en versioning sémantique).
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 en versioning sémantique).
Un changement radical peut faire partie des commits de n'importe quel type.
Others: commit de types autre que fix: et feat: sont autorisés, par exemple @commitlint/config-conventional (basé sur the Angular convention) 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

text

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

text

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

text

docs: correction d'orthographe dans CHANGELOG

Message commit avec scope

text

feat(lang): ajout de la langue polonaise

Message commit pour un correctif à l'aide d'un numéro d'un issue (facultatif).

text

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.

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.
Le type feat DOIT être utilisé lorsqu'un commit ajoute une nouvelle fonctionnalité à votre application.
ou bibliothèque.
Le type fix DOIT être utilisé lorsqu'un commit représente un correctif pour votre application.
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):
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.
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.
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.
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.
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.
Des types autres que feat et fix PEUVENT être utilisés dans vos messages de commit.
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.
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֊ի սպեցիֆիկացիայի հետ, և օգատգործվում են նոր
ֆունցիոնալի ինտեգրման (features), սխալների ուղղումների (fixes) և հետ
համատեղելիությունը խախտող փոփոխությունների (bracking changes) մասին «commit»
մեսիջներում տեղելացնելու համար։

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

text

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

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

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

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

fix։․ fix ՏԵՍԱԿԻ «commit»֊ները նախատեված են սխալների ուղղումների (bug
fix) մասին տեղեկացնելու համար (այն փոխկապակցված է սեմանտիկ տարբերակման մեջ
ներկայացված «ՓԱԹՉ»֊ի հետ)։
feat։․ feat ՏԵՍԱԿԻ «commit»֊ները նախատեված են նոր
ֆունկցիոնալի ինտեգրման մասին տեղեկացնելու համար (այն փոխկապակցված է սեմանտիկ
տարբերակման մեջ ներկայացված «ՄԻՆՈՐ»֊ի հետ)։
BREAKING CHANGE։․ BREAKING CHANGE։ պարունակող «commit»֊ները
(ՄԱՐՄՆՈՒՄ կամ ՆԵՐՔԵՎԻ ՀԱՏՎԱԾՈՒՄ ) տեղեկացնում են API֊ում արված փոփոխության
մասին, որը խախտում է հետ համատեղելիությունը (breaking changes) (այն փոխկապակցված
է սեմանտիկ տարբերակման մեջ ներկայացված ՄԱԺՈՐ֊ի
հետ), BREAKING CHANGE:֊ը կարող է հանդիպել կամայական ՏԵՍԱԿԻ «commit»֊ների հետ:
Ուրիշ տեսակներ. կարելի է օգտագործել նաև վերը նշվածներից տարբերվող
ՏԵՍԱԿ ունեցող (fix: և feat:) «commit»֊ներ, օրինակ՝
@commitlint-config-conventional֊ը
(հիմնված է Angular convention֊ի վրա)
առաջարկում է օգագործել են նաև՝ 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_ իր մարմնում

text

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_ ֊ի վրա ուշադրություն գրավելու համար

text

chore!: drop Node 6 from testing matrix

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

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

text

docs: correct spelling of CHANGELOG

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

text

feat(lang): add polish language

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

text

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 ստանդարտին
համապատասխան։

«commit» մեսիջները ՊԵՏՔ Է (MUST) սկսվեն ՏԵՍԱԿԻ (type) մասին նշումով, որը
գոյական է (noun) և բաղկացած է լինում մեկ բառից՝ օրինակ՝ feat, fix, և այլն։
Դրան հետևում է ՈՉ ՊԱՐՏԱԴԻՐ (OPTIONAL) ԿՈՆՏԵՔՍՏԸ (scope) և ՊԱՐՏԱԴԻՐ (REQUIRED)
վերջակետի նշանը և բացատը։
feat ՏԵՍԱԿԸ ՊԵՏՔ Է (MUST) օգտագործվի, երբ «commit»֊ի արդյունքում տեղի է
ունենում նոր ֆունցիոնալի իմպլեմենտացիա ձեր ծրագրում կամ գրադարանում։
fix ՏԵՍԱԿԸ ՊԵՏՔ Է (MUST) օգտագործվի, երբ «commit»֊ի արդյունքում տեղի է
ունենում սխալի ուղղում ձեր ծրագրում։
ԿՈՆՏԵՔՍՏԸ ԿԱՐՈՂ Է (MAY) ավելացվել ՏԵՍԱԿԻՑ անմիջապես հետո։ ԿՈՆՏԵՔՍՏԸ
ՊԵՏՔ Է (MUST) գոյական լինի պարփակված փակագծերի մեջ, և նկարագրի կոդի այն հատվածը,
որի վրա անդրադարձել է «commit»֊ը։ Օրինակ՝ fix(parser): ։
ԲԱՑԱՏՐՈՒԹՅՈՒՆԸ (description) ՊԵՏՔ Է (MUST) լինի անմիջապես
ՏԵՍԱԿ/ԿՈՆՏԵՔՍՏ-ին հետևող բացատից հետո։ ԲԱՑԱՏՐՈՒԹՅՈՒՆԸ համառոտ ներկայանում է
կոդում եղած փոփոխությունները։ Օրինակ՝
fix: array parsing issue when multiple spaces were contained in string։
ՄԱՐՄԻՆԸ (body) ԿԱՐՈՂ Է (MAY) հետևել կարճ ԲԱՑԱՏՐՈՒԹՅԱՆԸ և ավելի մեծ
ինֆորմացիա տրամադրել կոդում եղած փոփոխությունների մասին։ ՄԱՐՄԻՆԸ ՊԵՏՔ Է (MUST)
առանձնացվի ԲԱՑԱՏՐՈՒԹՅՈՒՆԻՑ մեկ դատարկ տողով։
ՆԵՐՔԵՎԻ ՀԱՏՎԱԾԸ (footer) ԿԱՐՈՂ Է (MAY) լինել մեկ կամ մի քանի տողի տեսքով
ՄԱՐՄՆԻՑ անմիջապես հետո և պետք է անջատված լինի ՄԱՐՄՆԻՑ մեկ դատարկ տողով։
ՆԵՐՔԵՎԻ ՀԱՏՎԱԾԸ ՊԵՏՔ Է (MUST) պարունակի մետա֊ինֆորմացիա «commit»֊ի մասին,
օրինակ՝ «pull» հարցումների, ստուգողների (reviewers), հետ համատեղելիությունը
խախտող փոփոխությունների և ալյն։ Մետա֊ինֆորմացիայի ամեն մասը զբաղեցնում է մեկ տող։
Հետ համատեղելիությունը խախտող փոփոխությունները ՊԵՏՔ Է (MUST) պիտակավորվեն
ՄԱՐՄԻՆԻ կամ ՆԵՐՔԵՎԻ ՀԱՏՎԱԾԻ սկզբում։ Հետ համատեղելիությունը խախտող
փոփոխությունները ՊԵՏՔ Է (MUST) պիտակավորվեն այս արտահայտությամբ՝ BREAKING CHANGE
(պարտադիր մեծատառերով), որին հետևում է վերջակետ և բացատ։
Հետ համատեղելիությունը խախտող փոփոխությունների նկարագիրը (ինչ է փոխվել
API-ում) ՊԵՏՔ Է (MUST) հետևեն BREAKING CHANGE: պիտակին։ Օրինակ՝
BREAKING CHANGE: environment variables now take precedence over config files.։
«commit»-ների ՏԵՍԱԿՆԵՐԸ ԿԱՐՈՂ ԵՆ (MAY) լինել feat֊ից և fix֊ից տարբեր։
Համաձայնեցված «commit»֊ներում ներկայացված բաղադրիչները, ՉՊԵՏՔ Է (MUST NOT)
դիտարկվեն, որպես ռեգիստրից կախված (case sensitive), բացառություն է միայն
BREAKING CHANGE֊ը, որը միշտ պետք է լինի մեծատառերով։
! նշանը ԿԱՐՈՂ Է (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֊ից։
(Մենք խրախուսում ենք հավելվածների ստեղծումը)։

Ինչ ես պետք է անեմ, երբ սխալմամբ «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,
dengan menjelaskan suatu fitur (features), perbaikan (fixes), merusak perubahan (breaking changes) yang dimuat dalam pesan komit.

Pesan komit harus tersusun sebagai berikut:

text

<type>[optional scope]: <description>

[optional body]

[optional footer]

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

fix: komit tipe fix untuk perbaikan celah (bug) dalam kode anda (ini berkolerasi dengan PATCH di semantic versioning).
feat: komit tipe feat memperkenalkan suatu fitur (feature) baru dalam kode anda (ini berkolerasi dengan MINOR di semantic versioning).
BREAKING CHANGE: komit yang berisi teks BREAKING CHANGE: di awal bagian opsi badan atau kaki mengenalkan merusak perubahan API (ini berkolerasi dengan MAJOR di semantic versioning).
BREAKING CHANGE dapat menjadi bagian dari komit tipe apapun.
Lainya: komit dengan tipe-tipe selain dari fix: and feat: diperbolehkan, misalnya @commitlint/config-conventional (berdasarkan pada Angular convention) 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

text

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

text

chore!: drop Node 6 from testing matrix

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

Pesan komit tanpa badan

text

docs: correct spelling of CHANGELOG

Pesan komit dengan cakupan

text

feat(lang): add polish language

Pesan komit untuk perbaikan menggunakan (opsi) nomor masalah.

text

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.

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.
tipe feat HARUS (MUST) digunakan ketika komit menambahkan fitur baru ke apilkasi atau perpustakaan anda.
tipe fix HARUS (MUST) digunakan ketika komit mewakili perbaikan celah (bug) untuk aplikasi anda.
Cakupan BISA (MAY) disediakan setelah tipe. Cakupan HARUS terdiri dari kata benda yang menggambarkan
bagian dari kode yang dikelilingi tanda kurung, misalnya, fix(parser):
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.
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.
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.
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.
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.
Tipe selain feat dan fix BISA (MAY) digunakan dalam pesan komit anda.
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.
! 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,
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:

text

<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:

fix: un commit di tipo fix risolve un errore nel codice (correlato al PATCH in un versionamento semver).
feat: un commit di tipo feat introduce una nuova funzionalità al codice (correlato al MINOR in un versionamento semver).
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 in un versionamento semver).
Una BREAKING CHANGE può essere parte di un commit di qualsiasi tipo.
Extra: sono ammessi ulteriori tipi oltre fix: efeat:, per esempio commitlint-config-conventional (che si basa sulla convenzione Angular) 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).

Esempi

Messaggio di un commit con una _descrizione_ e una breaking change nel _corpo_

text

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

text

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_

text

docs: correct spelling of CHANGELOG

Messaggio di un commit con uno _contesto_

text

feat(lang): added polish language

Messaggio di un commit per un `fix` utilizzando il numero della issue (opzionale)

text

fix: minor typos in code

see the issue for details on the typos fixed

fixes issue #12

Specifica

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.
Il tipo feat DEVE essere usato quando un commit aggiunge una funzionalità all'applicazione o libreria.
Il tipo fix DEVE essere usato quando un commit corregge un errore all'applicazione o libreria.
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):
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.
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.
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).
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.
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.
Il piè di pagina DEVE solo contenere BREAKING CHANGE, collegamenti esterni, riferimenti alle issueed ulteriori meta-informazioni.
Un commit POTREBBE utilizzare altri tipi al di fuori di feat e fix nel messaggio.
La convenzione NON DEVE tener conto del maiuscolo o minuscolo, ad eccezione di BREAKING CHANGE che DEVE sempre essere maiuscolo.
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?

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と組み合わせることで、コミットメッセージへ機能、修正、重大な変更を入れることで、さらに詳細な説明を可能にします。

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

原文：

text

<type>[optional scope]: <description>

[optional body]

[optional footer]

訳：

text

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

[任意 本文]

[任意 脚注]

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

fix: 型 fix はコードベースのバグにパッチを当てる場合です。（これはセマンティックバージョン管理におけるPATCHに相当します)
feat: 型 feat はコードベースに新しい機能を追加した場合です。(これはセマンティックバージョン管理における MINORに相当します)
BREAKING CHANGE: 本体または脚注の冒頭に BREAKING CHANGE: という内容があるコミットは、APIの重大な変更を意味できます。(セマンティックバージョン管理におけるMAJORに相当します)
BREAKING CHANGE はあらゆる型のコミットに含めることができます。
Others: fix: and feat: 以外のコミット型を許容します、例えば @commitlint/config-conventional (Angularの規約ベース)は chore:, docs:, style:, refactor:, perf:, test:, などがあります。

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

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

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

例

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

text

feat: allow provided config object to extend other configs

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

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

text

chore!: drop Node 6 from testing matrix

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

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

text

docs: correct spelling of CHANGELOG

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

text

feat(lang): add polish language

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

text

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 日本語) で述べられているように解釈されるべきものです。

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

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

text

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

[본문(선택 사항)]

[꼬리말(선택 사항)]

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

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

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

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

예제

본문에 설명과 BREAKING CHANGE를 가지는 커밋 메세지

text

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에 주의를 주기 위해 옵션인 `!`를 포함한 커밋 메세지

text

chore!: drop Node 6 from testing matrix

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

본문이 없는 커밋 메세지

text

docs: correct spelling of CHANGELOG

적용 범위를 가지는 커밋 메세지

text

feat(lang): add polish language

옵션인 이슈 번호를 가진 fix 타입의 커밋 메세지

text

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에 기술된 그대로 해석해야 합니다.

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

The commit message should be structured as follows:

text

<type>[optional scope]: <description>

[optional body]

[optional footer]

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

fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in semantic versioning).
feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in semantic versioning).
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 in semantic versioning).
A BREAKING CHANGE can be part of commits of any type.
Others: commit types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the Angular convention) 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

text

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

text

chore!: drop Node 6 from testing matrix

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

Commit message with no body

text

docs: correct spelling of CHANGELOG

Commit message with scope

text

feat(lang): add polish language

Commit message for a fix using an (optional) issue number.

text

fix: correct minor typos in code

see the issue for details on the typos fixed

closes issue #12

Specification

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.
The type feat MUST be used when a commit adds a new feature to your application or library.
The type fix MUST be used when a commit represents a bug fix for your application.
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):
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.
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.
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.
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.
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.
Types other than feat and fix MAY be used in your commit messages.
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.
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?

How does this relate to SemVer?

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`

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,
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:

text

<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:

fix: um commit do tipo fix soluciona um problema na sua base de código
(isso se correlaciona com PATCH do versionamento semântico).
feat: um commit do tipo feat inclui um novo recurso na sua base
de código (isso se correlaciona com MINOR do versionamento semântico).
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
do versionamento semântico). Uma BREAKING CHANGE pode fazer parte de commits de qualquer tipo.
Outros: tipos adicionais são permitidos além de fix: e feat:, por exemplo
@commitlint/config-conventional
(baseado na Convenção do Angular)
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

text

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

text

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

text

docs: ortografia correta de CHANGELOG

Mensagem de commit com escopo

text

feat(lang): adiciona tradução para português brasileiro

Mensagem de commit de uma correção utilizando número de ticket (opcional)

text

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.

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.
O tipo feat DEVE ser usado quando um commit adiciona um novo recurso ao seu
aplicativo ou biblioteca.
O tipo fix DEVE ser usado quando um commit representa a correção de um
problema em seu aplicativo ou biblioteca.
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):
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.
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.
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.
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.
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.
Além de feat e fix, outro tipo PODE ser usados em suas mensagens de commit.
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.
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 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.

Docker & Self-Hosted Deployment Verified OCI

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

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

commitlint-config-patternplate

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

commitlint-config-nx-scopes

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

commitlint-config-lerna-scopes

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

commitlint-config-angular

File: @alias/commitlint/README.md Copy Chapter

commitlint

File: @commitlint/travis-cli/README.md Copy Chapter

@commitlint/travis-cli

Getting started Copy Chapter

File: @commitlint/read/README.md Copy Chapter

@commitlint/read

Getting started Copy Chapter

Documentation Copy Chapter

File: @commitlint/prompt-cli/README.md Copy Chapter

@commitlint/prompt-cli

Getting started Copy Chapter

File: @commitlint/prompt/README.md Copy Chapter

@commitlint/prompt

Getting started Copy Chapter

File: @commitlint/parse/README.md Copy Chapter

@commitlint/parse

Install Copy Chapter

Use Copy Chapter

API Copy Chapter

parse(message: string, parser: Function, parserOpts: Object) Copy Section

File: @commitlint/load/README.md Copy Chapter

@commitlint/load

Getting started Copy Chapter

Documentation Copy Chapter

File: @commitlint/lint/README.md Copy Chapter

@commitlint/lint

Getting started Copy Chapter

Documentation Copy Chapter

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

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

draft: false Copy Chapter

Commit Convenzionali 1.0.0-beta

Riepilogo Copy Chapter

Introduzione Copy Chapter

Specifica Copy Chapter

Perchè utilizzare commit convenzionali Copy Chapter

FAQ Copy Chapter

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

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

Non disincoraggia sviluppo ed iterazioni rapidi? Copy Section

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

Come si collega a SemVer? Copy Section

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

Cosa faccio se accidentalmente utilizzo un tipo di commit sbagliato? Copy Section

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

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

Devono tutti i contributori seguire la specifica Commit Convenzionali? Copy Section

File: content/v1.0.0-beta/index.md Copy Chapter

draft: false Copy Chapter

Conventional Commits 1.0.0-beta

Summary Copy Chapter

Introduction Copy Chapter

Specification Copy Chapter

Why Use Conventional Commits Copy Chapter

FAQ Copy Chapter

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

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

Doesn’t this discourage rapid development and fast iteration? Copy Section

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

How does this relate to SemVer? Copy Section

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

What do I do if I accidentally use the wrong commit type? Copy Section

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

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

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

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

draft: false Copy Chapter

Konwencjonalne Commity 1.0.0-beta

Streszczenie Copy Chapter

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

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

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

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

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

File: @alias/commitlint/README.md

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

Getting started

File: @commitlint/read/README.md

Getting started

Documentation

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

Getting started

File: @commitlint/prompt/README.md

Getting started

File: @commitlint/parse/README.md

Install

Use

API

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

File: @commitlint/load/README.md

Getting started

Documentation

File: @commitlint/lint/README.md

Getting started

Documentation

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

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

draft: false

Riepilogo

Introduzione

Specifica

Perchè utilizzare commit convenzionali

FAQ

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

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

Non disincoraggia sviluppo ed iterazioni rapidi?

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

Come si collega a SemVer?

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

Cosa faccio se accidentalmente utilizzo un tipo di commit sbagliato?

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

Devono tutti i contributori seguire la specifica Commit Convenzionali?

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

draft: false

Summary

Introduction

Specification

Why Use Conventional Commits

FAQ

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

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

Doesn’t this discourage rapid development and fast iteration?

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

How does this relate to SemVer?

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

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

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

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

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

draft: false

Streszczenie

Wprowadzenie

Specyfikacja

Dlaczego używać Konwencjonalnych Commitów

FAQ

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

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

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

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?

Jak jest to powiązane z SemVer?

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

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

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

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

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

draft: false

概述

介绍

约定式提交规范