на [соглашении Angular][angular-convention]) рекоммендует `build`, `chore`,
`ci`, `docs`, `style`, `refactor`, `perf`, `test` и другие.
1. Другие _сноски_ коммитов могут быть аналогичны соглашению [git trailer
format][git-trailer-format].
Дополнительные _типы_ не требуются «Соглашению о коммитах» и не имеют неявного
эффекта в [семантическом версионировании][semver] (если только они не включают
`BREAKING CHANGE`).
<br/><br/>
_Контекст_ может быть добавлен к _типу_ коммита, чтобы предоставить
дополнительную контекстную информацию; она содержится в скобках. Например,
`feat(parser): add ability to parse arrays`.
## Примеры
### Сообщение коммита с _описанием_ и _сноской_ `BREAKING CHANGE`
```
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
```
### Чтобы привлечь внимание к критическим изменением, к сообщению коммита добавляется `!`
```
refactor!: drop support for Node 6
```
### Сообщение коммита вместе с `!` и _сноской_ `BREAKING CHANGE`.
```
refactor!: drop support for Node 6
BREAKING CHANGE: refactor to use JavaScript features not available in Node 6.
```
### Сообщение коммита без _тела_
```
docs: correct spelling of CHANGELOG
```
### Сообщение коммита с _контекстом_.
```
feat(lang): add polish language
```
### Сообщение коммита с _телом_ из нескольких абзацев и несколькими _сносками_
```
fix: correct minor typos in code
see the issue for details
on typos fixed.
Reviewed-by: Z
Refs #133
```
## Спецификация
Слова «MUST», «MUST NOT», «REQUIRED», «SHALL», «MAY» и «OPTIONAL» в данном
документе должны интерпретироваться как в [RFC 2119][rfc-2119].
1. Коммиты должны (MUST) начинатся с_типа_, который является существительным:
`feat`, `fix` и т. д. За ним следует необязательный (OPTIONAL) _контекст_,
необязательный (OPTIONAL) восклицательный знак (`!`) и обязательные
(REQUIRED) двоеточие (`:`) и пробел (` `).
1._Тип_`feat` должен (MUST) использоваться, когда коммит добавляет новый
функционал в ваше приложение или вашу библиотеку.
1._Тип_`fix` должен (MUST) использоваться, когда коммит исправляет баг в
вашем приложении или вашей библиотеке.
1._Контекст_ может (MAY) следовать после _типа_. _Контекст_ должен (MUST)
быть существительным, заключённым в круглые скобки, описывающий часть
кодовой базы, которую затронул коммит. Например, `fix(parser)`.
1._Описание_ должно (MUST) следовать сразу за двоеточием (`:`) и пробелом
(` `) после _типа_ или _контекста_. _Описание_ представляет собой краткое
изложение изменений кода. Например, `fix: array parsing issue when multiple
spaces were contained in string`.
1._Тело_ коммита может (MAY) следовать после короткого _описания_, добавляя
дополнительную контекстную информацию об изменениях в коде. _Тело_ должно
(MUST) отделяться от _описания_ одной пустой строкой.
1._Тело_ коммита имеет произвольную форму и может (MAY) состоять из любого
количества абзацев, разделённых новой строкой.
1.В одной или нескольких _сносках_ может (MAY) быть одна пустая строка после
_тела_. Каждая _сноска_ должна (MUST) состоять из токена слова, за которым
следует разделитель `:<пробел>` или `<пробел>#`, за которым следует
строковое значение (основано на [git trailer format][git-trailer-format]).
1. Токен _сноски_ должен (MUST) использовать `-` вместо пробельных символов.
Например, `Acked-by` (это помогает отличить раздел _сноски_ от его_тела_,
состоящего из нескольких абзацев). Исключение составляет `BREAKING CHANGE`,
которое может (MAY) также использоваться как токен.
1._Сноска_ может (MAY) содержать пробелы и символы новой строки, а парсер
должен (MUST) завершаться при обнаружении следующей допустимой пары
токен-разделитель _сноски_.
1. Критические изменения должны (MUST) быть указаны в _типе_, _контесте_ или
_сноске_ коммита.
1. Если `BREAKING CHANGE` включено в _сноску_, то оно должно (MUST) состоять из
прописного текста `BREAKING CHANGE`, за которым следует двоеточие (`:`),
пробел (` `) и _описание_. Например, `BREAKING CHANGE: environment
variables now take precedence over config files`.
1. Если критические изменения находятся в _типе_ или _контексте_, то они должны
(MUST) быть обозначены восклицательным знаком (`!`), непосредственно перед
двоеточием (`:`). Если используется восклицательный знак (`!`), то
`BREAKING CHANGE` может (MAY) быть опущен в _сноске_, а_описание_ коммита
должно (SHALL) использоваться для описания критического изменения.
1.В ваших сообщениях коммитов могут (MAY) использоваться _типы_, отличные от
`feat` и `fix`. Например, `docs: updated ref docs`.
1. Единицы информации, которые составляют «Соглашение о коммитах», не должны
(MUST NOT) обрабатываться разработчиками как чувствительные к регистру, за
исключением `BREAKING CHANGE`, которое должно (MUST) быть прописными.
1.`BREAKING-CHANGE` должен (MUST) быть синонимом `BREAKING CHANGE` при
использовании в качестве токена в _сноске_.
## Зачем использовать «Соглашение о коммитах»
* Автоматическое создание списков изменения.
* Автоматическое определение семантического повышения версии (на основе _типов_
совершённых коммитов).
* Информирование товарищей по команде, общественности и других заинтересованных
сторон о характере изменений.
* Запуск процессов сборки и публикации.
* Упростите людям участие в ваших проектах, позволив им изучить более
структурированную историю коммитов.
## FAQ (часто задаваемые вопросы)
### Как мне поступать с сообщениями коммитов на начальном этапе разработки?
Мы рекомендуем действовать так, как если бы вы уже выпустили продукт. Обычно
*кто-то*, даже если это ваши коллеги-разработчики программного обеспечения,
использует ваше программное обеспечение. Они захотят знать, что исправлено,
что ломается и т. д.
### _Типы_ в заголовке коммита должны быть прописными или строчными?
Выберите тот, который больше всего вам нравится, и строго ему следуйте.
### Что мне делать, если коммит соответствует более чем одному _типу_?
По возможности вернитесь назад и сделайте несколько коммитов. Частью
преимущества «Соглашения о коммитах» является способность побуждать нас делать
более организованные коммиты и PRs (pull requests, или пулл-реквесты, или
запросы на вытягивание).
### Разве это не препятствует интенсивной разработке и быстрой итерации?
Это препятствует быстрому неорганизованному движению. Это поможет вам быстро
продвигаться в долгосрочной перспективе в нескольких проектах с разными
участниками.
### Может ли «Соглашение о коммитах» привести разработчиков к ограничению _типов_ совершаемых ими коммитов, потому что они будут думать в соответствии с предоставленными _типами_?
«Соглашение о коммитах» побуждают нас делать больше определённых _типов_
коммитов, таких как `fix`. Помимо этого, гибкость «Соглашения о коммитах»
позволяет вашей команде придумывать свои собственные _типы_ и со временем
изменять их.
### Как это связано с [семантическим версионированием][semver]?
Коммиты _типа_`fix` должны быть переведены в выпуски `PATCH`, `feat` — в
