diff --git a/content/v1.0.0/index.ru.md b/content/v1.0.0/index.ru.md index 3a65195..a744fd8 100644 --- a/content/v1.0.0/index.ru.md +++ b/content/v1.0.0/index.ru.md @@ -34,18 +34,18 @@ aliases: ["/ru/"] 1. **fix:** коммит _типа_ `fix` исправляет баг в вашем коде (соответствует [`PATCH`](https://semver.org/lang/ru/#%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE) в Семантическом Версионировании). -1. **feat:** коммит _типа_ `feat` добавляет новую функцию в ваш код +2. **feat:** коммит _типа_ `feat` добавляет новую функцию в ваш код (соответствует [`MINOR`](https://semver.org/lang/ru/#%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE) в Семантическом Версионировании). -1. **BREAKING CHANGE:** коммит, который имеет _сноску_ `BREAKING CHANGE` или +3. **BREAKING CHANGE:** коммит, который имеет _сноску_ `BREAKING CHANGE` или коммит, заканчивающийся восклицательным знаком (`!`) после _типа_ или _контекста_, вводящий изменение(я), нарушающие обратную совместимость (соответствует [`MAJOR`](https://semver.org/lang/ru/#%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE) в Семантическом Версионировании). `BREAKING CHANGE` может быть частью коммита любого _типа_. -1. Другие _типы_ коммитов разрешены. Например, +4. Другие _типы_ коммитов разрешены. Например, [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (основан на [соглашении Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) рекомендует `build`, `chore`, `ci`, `docs`, `style`, `refactor`, `perf`, `test` и другие. -1. Другие _сноски_ коммитов могут быть аналогичны соглашению [git trailer format](https://git-scm.com/docs/git-interpret-trailers). +5. Другие _сноски_ коммитов могут быть аналогичны соглашению [git trailer format](https://git-scm.com/docs/git-interpret-trailers). Дополнительные _типы_ не требуются «Соглашению о коммитах» и не имеют неявного эффекта в Семантическом Версионировании (если только они не включают @@ -121,51 +121,51 @@ Refs: #123 `feat`, `fix` и т.д. За ним следует необязательный (OPTIONAL) _контекст_, необязательный (OPTIONAL) восклицательный знак (`!`) и обязательные (REQUIRED) двоеточие (`:`) и пробел (` `). -1. _Тип_ `feat` должен (MUST) использоваться, когда коммит добавляет новый +2. _Тип_ `feat` должен (MUST) использоваться, когда коммит добавляет новый функционал в ваше приложение или вашу библиотеку. -1. _Тип_ `fix` должен (MUST) использоваться, когда коммит исправляет баг в +3. _Тип_ `fix` должен (MUST) использоваться, когда коммит исправляет баг в вашем приложении или вашей библиотеке. -1. _Контекст_ может (MAY) следовать после _типа_. _Контекст_ должен (MUST) +4. _Контекст_ может (MAY) следовать после _типа_. _Контекст_ должен (MUST) быть существительным, заключённым в круглые скобки, описывающий часть кодовой базы, которую затронул коммит. Например, `fix(parser)`. -1. _Описание_ должно (MUST) следовать сразу за двоеточием (`:`) и пробелом +5. _Описание_ должно (MUST) следовать сразу за двоеточием (`:`) и пробелом (` `) после _типа_ или _контекста_. _Описание_ представляет собой краткое изложение изменений кода. Например, `fix: array parsing issue when multiple spaces were contained in string`. -1. _Тело_ коммита может (MAY) следовать после короткого _описания_, добавляя +6. _Тело_ коммита может (MAY) следовать после короткого _описания_, добавляя дополнительную контекстную информацию об изменениях в коде. _Тело_ должно (MUST) отделяться от _описания_ одной пустой строкой. -1. _Тело_ коммита имеет произвольную форму и может (MAY) состоять из любого +7. _Тело_ коммита имеет произвольную форму и может (MAY) состоять из любого количества абзацев, разделённых новой строкой. -1. В одной или нескольких _сносках_ может (MAY) быть одна пустая строка после +8. В одной или нескольких _сносках_ может (MAY) быть одна пустая строка после _тела_. Каждая _сноска_ должна (MUST) состоять из токена слова, за которым следует разделитель `:<пробел>` или `<пробел>#`, за которым следует строковое значение (основано на [git trailer format](https://git-scm.com/docs/git-interpret-trailers)). -1. Токен _сноски_ должен (MUST) использовать `-` вместо пробельных символов. +9. Токен _сноски_ должен (MUST) использовать `-` вместо пробельных символов. Например, `Acked-by` (это помогает отличить раздел _сноски_ от его _тела_, состоящего из нескольких абзацев). Исключение составляет `BREAKING CHANGE`, которое может (MAY) также использоваться как токен. -1. _Сноска_ может (MAY) содержать пробелы и символы новой строки, а считывание - должно (MUST) завершаться при обнаружении следующей допустимой пары - токен-разделитель _сноски_. -1. Критические изменения должны (MUST) быть указаны в _типе_, _контексте_ или - _сноске_ коммита. -1. Если `BREAKING CHANGE` включено в _сноску_, то оно должно (MUST) состоять из - прописного текста `BREAKING CHANGE`, за которым следует двоеточие (`:`), - пробел (` `) и _описание_. Например, `BREAKING CHANGE: environment +10. _Сноска_ может (MAY) содержать пробелы и символы новой строки, а считывание + должно (MUST) завершаться при обнаружении следующей допустимой пары + токен-разделитель _сноски_. +11. Критические изменения должны (MUST) быть указаны в _типе_, _контексте_ или + _сноске_ коммита. +12. Если `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` при - использовании в качестве токена в _сноске_. +13. Если критические изменения находятся в _типе_ или _контексте_, то они должны + (MUST) быть обозначены восклицательным знаком (`!`), непосредственно перед + двоеточием (`:`). Если используется восклицательный знак (`!`), то + `BREAKING CHANGE` может (MAY) быть опущен в _сноске_, а _описание_ коммита + должно (SHALL) использоваться для описания критического изменения. +14. В ваших сообщениях коммитов могут (MAY) использоваться _типы_, отличные от + `feat` и `fix`. Например, `docs: updated ref docs`. +15. Единицы информации, которые составляют «Соглашение о коммитах», не должны + (MUST NOT) обрабатываться разработчиками как чувствительные к регистру, за + исключением `BREAKING CHANGE`, которое должно (MUST) быть прописными. +16. `BREAKING-CHANGE` должен (MUST) быть синонимом `BREAKING CHANGE` при + использовании в качестве токена в _сноске_. ## Зачем использовать «Соглашение о коммитах»