также разрешены. Например, [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional)
реализацию без добавления новых функций и исправления ошибок. Обратите внимание, что
данный тип не описывается данной спецификацией и не имеет эффекта в SemVer
(за исключением, когда он включает BREAKING CHANGE).
<br/>
Контекст (scope) может быть объявлен рядом с типом commit'а для добавления дополнительной
информации о контексте. Он должен содержаться в круглых скобках, например, `feat(parser): add ability to parse arrays`.
## Примеры
### Сообщение commit'ас описанием и изменениям, нарушающим обратную совместимость, в теле
```
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'a с не обязательным `!`, для того, чтобы привлечь внимание к изменениям, нарушающим обратную совместимость
```
chore!: drop Node 6 from testing matrix
BREAKING CHANGE: dropping Node 6 which hits end of life in April
```
### Сообщение commit'а без тела
```
docs: correct spelling of CHANGELOG
```
### Сообщение commit'ас указанием контекста (scope)
```
feat(lang): add polish language
```
### Сообщение commit'а, исправляющего ошибку (fix), использующее не обязательный номер задачи (issue) в багтрекере
```
fix: correct minor typos in code
see the issue for details on the typos fixed
closes issue #12
```
## Спецификация
Слова “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, и “OPTIONAL” в данном документе должны интерпретироваться как в [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
1. Commit'ы должны (MUST) начинаться с типа, который является существительным: `feat`, `fix`, и т.д.,
за которым следуют не обязательное (OPTIONAL) указание контекста (scope), двоеточие и пробел.
1. Тип `feat` должен (MUST) использоваться, когда commit добавляет новый функционал (feature) в
ваше приложение или библиотеку.
1. Тип `fix` должен (MUST) использоваться, когда commit исправляет ошибку (fix)
* Автоматически срабатываемый процесс сборки и публикации.
* Людям проще участвовать в вашем проекте, потому что им доступна более структурированная история коммитов.
## FAQ
### Как я должен писать сообщения commit'ов на начальной стадии разработки?
Мы рекомендуем писать сообщения commit'ов так, как будто вы уже выпустили продукт. Как правило, *кто-то*, например,
ваши коллеги, уже используют ваш код. И они хотят знать, что исправилось, что изменилось, какие нарушения обратной
совместимости появились и т.д.
### В каком регистре я должен писать заголовки commit'ов?
Любой регистр можно использовать, но лучше во всей истории использовать один стиль.
### Что мне делать, если commit должен содержать больше одного типа?
Вернитесь назад и сделайте несколько commit'ов, если это возможно. Часть из преимуществ использования Conventional Commits - это его способность побуждать делать более организованные коммиты и PR'ы.
### Разве это не препятствует быстрому развитию и быстрой интеграции?
Это препятствует быстрому развитию в неорганизованном виде. Это помогает быстро двигаться в нескольких проектах
с несколькими участниками.
### Могут ли Conventional Commits заставить разработчиков ограничивать их типы commit'ов, потому что им придется думать об этих типах?
Conventional Commits побуждают делать больше commit'ов с определенными типами, такими как `fix`. Кроме того, гибкость
* [php-commitizen](https://github.com/damianopetrungaro/php-commitizen): утилита для создания сообщений commit'ов, следующих Conventional Commits спецификации.
Используется для PHP-проектов, как зависимость composer, или глобально для не PHP-проектов.
* [conform](https://github.com/autonomy/conform): утилита, которая может быть использована для реализации политик в git-репозиториях, включая правила написания commit'ов.
