From 782d5f2621ee7f7319eff7955268580cf1793e54 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=98=D0=B2=D0=B0=D0=BD=D0=BE=D0=B2=20=D0=9F=D0=B0=D0=B2?= =?UTF-8?q?=D0=B5=D0=BB=20=D0=A0=D0=BE=D0=BC=D0=B0=D0=BD=D0=BE=D0=B2=D0=B8?= =?UTF-8?q?=D1=87?= Date: Sat, 30 Aug 2025 13:15:47 +0300 Subject: [PATCH 1/5] =?UTF-8?q?docs(ru):=20fix=20Latin=20C=20to=20Cyrillic?= =?UTF-8?q?=20=D0=A1=20in=20"=D0=A1=D0=B5=D0=BC=D0=B0=D0=BD=D1=82=D0=B8?= =?UTF-8?q?=D1=87=D0=B5=D1=81=D0=BA=D0=BE=D0=BC"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/v1.0.0/index.ru.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/v1.0.0/index.ru.md b/content/v1.0.0/index.ru.md index 30c70527..10992850 100644 --- a/content/v1.0.0/index.ru.md +++ b/content/v1.0.0/index.ru.md @@ -32,13 +32,13 @@ aliases: ["/ru/"] пользователям вашей библиотеки: 1. **fix:** коммит _типа_ `fix` исправляет баг в вашем коде (соответствует - [`PATCH`](https://semver.org/lang/ru/#%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE) в Cемантическом Версионировании). + [`PATCH`](https://semver.org/lang/ru/#%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE) в Семантическом Версионировании). 1. **feat:** коммит _типа_ `feat` добавляет новую функцию в ваш код - (соответствует [`MINOR`](https://semver.org/lang/ru/#%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE) в Cемантическом Версионировании). + (соответствует [`MINOR`](https://semver.org/lang/ru/#%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE) в Семантическом Версионировании). 1. **BREAKING CHANGE:** коммит, который имеет _сноску_ `BREAKING CHANGE` или коммит, заканчивающийся восклицательным знаком (`!`) после _типа_ или _контекста_, вводящий изменение(я), нарушающие обратную совместимость - (соответствует [`MAJOR`](https://semver.org/lang/ru/#%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE) в Cемантическом Версионировании). + (соответствует [`MAJOR`](https://semver.org/lang/ru/#%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE) в Семантическом Версионировании). `BREAKING CHANGE` может быть частью коммита любого _типа_. 1. Другие _типы_ коммитов разрешены. Например, [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (основан From 71877974de4cf58eda31d9b06a1340438c22d590 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=98=D0=B2=D0=B0=D0=BD=D0=BE=D0=B2=20=D0=9F=D0=B0=D0=B2?= =?UTF-8?q?=D0=B5=D0=BB=20=D0=A0=D0=BE=D0=BC=D0=B0=D0=BD=D0=BE=D0=B2=D0=B8?= =?UTF-8?q?=D1=87?= Date: Sat, 30 Aug 2025 13:16:13 +0300 Subject: [PATCH 2/5] =?UTF-8?q?docs(ru):=20fix=20verb=20agreement=20from?= =?UTF-8?q?=20"=D0=BD=D0=B0=D1=87=D0=B8=D0=BD=D0=B0=D0=B5=D1=82=D1=81?= =?UTF-8?q?=D1=8F"=20to=20"=D0=BD=D0=B0=D1=87=D0=B8=D0=BD=D0=B0=D1=82?= =?UTF-8?q?=D1=8C=D1=81=D1=8F"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/v1.0.0/index.ru.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/v1.0.0/index.ru.md b/content/v1.0.0/index.ru.md index 10992850..506fb797 100644 --- a/content/v1.0.0/index.ru.md +++ b/content/v1.0.0/index.ru.md @@ -109,7 +109,7 @@ Refs: #123 Слова «MUST», «MUST NOT», «REQUIRED», «SHALL», «MAY» и «OPTIONAL» в данном документе должны интерпретироваться как в [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). -1. Коммиты должны (MUST) начинается с _типа_, который является существительным: +1. Коммиты должны (MUST) начинаться с _типа_, который является существительным: `feat`, `fix` и т.д. За ним следует необязательный (OPTIONAL) _контекст_, необязательный (OPTIONAL) восклицательный знак (`!`) и обязательные (REQUIRED) двоеточие (`:`) и пробел (` `). From 9b8b9927294c89b60b04da200a3819614c86547f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=98=D0=B2=D0=B0=D0=BD=D0=BE=D0=B2=20=D0=9F=D0=B0=D0=B2?= =?UTF-8?q?=D0=B5=D0=BB=20=D0=A0=D0=BE=D0=BC=D0=B0=D0=BD=D0=BE=D0=B2=D0=B8?= =?UTF-8?q?=D1=87?= Date: Sat, 30 Aug 2025 13:19:05 +0300 Subject: [PATCH 3/5] =?UTF-8?q?docs(ru):=20standardize=20capitalization=20?= =?UTF-8?q?of=20"=D0=A1=D0=B5=D0=BC=D0=B0=D0=BD=D1=82=D0=B8=D1=87=D0=B5?= =?UTF-8?q?=D1=81=D0=BA=D0=BE=D0=B5=20=D0=92=D0=B5=D1=80=D1=81=D0=B8=D0=BE?= =?UTF-8?q?=D0=BD=D0=B8=D1=80=D0=BE=D0=B2=D0=B0=D0=BD=D0=B8=D0=B5"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/v1.0.0/index.ru.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/v1.0.0/index.ru.md b/content/v1.0.0/index.ru.md index 506fb797..0e263498 100644 --- a/content/v1.0.0/index.ru.md +++ b/content/v1.0.0/index.ru.md @@ -47,7 +47,7 @@ aliases: ["/ru/"] 1. Другие _сноски_ коммитов могут быть аналогичны соглашению [git trailer format](https://git-scm.com/docs/git-interpret-trailers). Дополнительные _типы_ не требуются «Соглашению о коммитах» и не имеют неявного -эффекта в семантическом версионировании (если только они не включают +эффекта в Семантическом Версионировании (если только они не включают `BREAKING CHANGE`).

_Контекст_ может быть добавлен к _типу_ коммита, чтобы предоставить From ec7a65ff2f61f7e8538a8fcfc4bc03f44f1c245c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=98=D0=B2=D0=B0=D0=BD=D0=BE=D0=B2=20=D0=9F=D0=B0=D0=B2?= =?UTF-8?q?=D0=B5=D0=BB=20=D0=A0=D0=BE=D0=BC=D0=B0=D0=BD=D0=BE=D0=B2=D0=B8?= =?UTF-8?q?=D1=87?= Date: Sat, 30 Aug 2025 13:19:41 +0300 Subject: [PATCH 4/5] docs(ru): format documentation for consistency --- content/v1.0.0/index.ru.md | 81 +++++++++++++++++++++----------------- 1 file changed, 45 insertions(+), 36 deletions(-) diff --git a/content/v1.0.0/index.ru.md b/content/v1.0.0/index.ru.md index 0e263498..3a651951 100644 --- a/content/v1.0.0/index.ru.md +++ b/content/v1.0.0/index.ru.md @@ -8,9 +8,9 @@ aliases: ["/ru/"] ## Главное Спецификация «Соглашение о коммитах» — простое соглашение о том, как нужно -писать сообщения коммитов. Оно описывает простой набор правил для создания +писать сообщения коммитов. Оно описывает простой набор правил для создания понятной истории коммитов, а также позволяет проще разрабатывать инструменты -автоматизации, основанные на истории коммитов. Данное соглашение совместимо с +автоматизации, основанные на истории коммитов. Данное соглашение совместимо с [Семантическим Версионированием](https://semver.org/lang/ru/), описывая новые функции, исправления и изменения, нарушающие обратную совместимость в сообщениях коммитов. @@ -25,6 +25,7 @@ aliases: ["/ru/"] [необязательная(ые) сноска(и)] ``` + ---
@@ -40,7 +41,7 @@ aliases: ["/ru/"] _контекста_, вводящий изменение(я), нарушающие обратную совместимость (соответствует [`MAJOR`](https://semver.org/lang/ru/#%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE) в Семантическом Версионировании). `BREAKING CHANGE` может быть частью коммита любого _типа_. -1. Другие _типы_ коммитов разрешены. Например, +1. Другие _типы_ коммитов разрешены. Например, [@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` и другие. @@ -51,12 +52,13 @@ aliases: ["/ru/"] `BREAKING CHANGE`).

_Контекст_ может быть добавлен к _типу_ коммита, чтобы предоставить -дополнительную контекстную информацию; она содержится в скобках. Например, +дополнительную контекстную информацию; она содержится в скобках. Например, `feat(parser): add ability to parse arrays`. ## Примеры ### Сообщение коммита с _описанием_ и _сноской_ `BREAKING CHANGE` + ``` feat: allow provided config object to extend other configs @@ -64,16 +66,19 @@ BREAKING CHANGE: `extends` key in config file is now used for extending other co ``` ### Сообщение коммита с `!` для привлечения внимания к `BREAKING CHANGE` + ``` feat!: send an email to the customer when a product is shipped ``` ### Сообщение коммита с _контекстом_ и `!` для привлечения внимания к `BREAKING CHANGE` + ``` feat(api)!: send an email to the customer when a product is shipped ``` ### Сообщение коммита вместе с `!` и _сноской_ `BREAKING CHANGE` + ``` chore!: drop support for Node 6 @@ -81,16 +86,19 @@ BREAKING CHANGE: use JavaScript features not available in Node 6. ``` ### Сообщение коммита без _тела_ + ``` docs: correct spelling of CHANGELOG ``` ### Сообщение коммита с _контекстом_ + ``` feat(lang): add polish language ``` ### Сообщение коммита с _телом_ из нескольких абзацев и несколькими _сносками_ + ``` fix: prevent racing of requests @@ -117,25 +125,25 @@ Refs: #123 функционал в ваше приложение или вашу библиотеку. 1. _Тип_ `fix` должен (MUST) использоваться, когда коммит исправляет баг в вашем приложении или вашей библиотеке. -1. _Контекст_ может (MAY) следовать после _типа_. _Контекст_ должен (MUST) +1. _Контекст_ может (MAY) следовать после _типа_. _Контекст_ должен (MUST) быть существительным, заключённым в круглые скобки, описывающий часть - кодовой базы, которую затронул коммит. Например, `fix(parser)`. + кодовой базы, которую затронул коммит. Например, `fix(parser)`. 1. _Описание_ должно (MUST) следовать сразу за двоеточием (`:`) и пробелом - (` `) после _типа_ или _контекста_. _Описание_ представляет собой краткое - изложение изменений кода. Например, `fix: array parsing issue when multiple - spaces were contained in string`. + (` `) после _типа_ или _контекста_. _Описание_ представляет собой краткое + изложение изменений кода. Например, `fix: array parsing issue when multiple +spaces were contained in string`. 1. _Тело_ коммита может (MAY) следовать после короткого _описания_, добавляя - дополнительную контекстную информацию об изменениях в коде. _Тело_ должно + дополнительную контекстную информацию об изменениях в коде. _Тело_ должно (MUST) отделяться от _описания_ одной пустой строкой. 1. _Тело_ коммита имеет произвольную форму и может (MAY) состоять из любого количества абзацев, разделённых новой строкой. 1. В одной или нескольких _сносках_ может (MAY) быть одна пустая строка после - _тела_. Каждая _сноска_ должна (MUST) состоять из токена слова, за которым + _тела_. Каждая _сноска_ должна (MUST) состоять из токена слова, за которым следует разделитель `:<пробел>` или `<пробел>#`, за которым следует строковое значение (основано на [git trailer format](https://git-scm.com/docs/git-interpret-trailers)). 1. Токен _сноски_ должен (MUST) использовать `-` вместо пробельных символов. Например, `Acked-by` (это помогает отличить раздел _сноски_ от его _тела_, - состоящего из нескольких абзацев). Исключение составляет `BREAKING CHANGE`, + состоящего из нескольких абзацев). Исключение составляет `BREAKING CHANGE`, которое может (MAY) также использоваться как токен. 1. _Сноска_ может (MAY) содержать пробелы и символы новой строки, а считывание должно (MUST) завершаться при обнаружении следующей допустимой пары @@ -144,15 +152,15 @@ Refs: #123 _сноске_ коммита. 1. Если `BREAKING CHANGE` включено в _сноску_, то оно должно (MUST) состоять из прописного текста `BREAKING CHANGE`, за которым следует двоеточие (`:`), - пробел (` `) и _описание_. Например, `BREAKING CHANGE: environment - variables now take precedence over config files`. + пробел (` `) и _описание_. Например, `BREAKING CHANGE: environment +variables now take precedence over config files`. 1. Если критические изменения находятся в _типе_ или _контексте_, то они должны (MUST) быть обозначены восклицательным знаком (`!`), непосредственно перед - двоеточием (`:`). Если используется восклицательный знак (`!`), то + двоеточием (`:`). Если используется восклицательный знак (`!`), то `BREAKING CHANGE` может (MAY) быть опущен в _сноске_, а _описание_ коммита должно (SHALL) использоваться для описания критического изменения. 1. В ваших сообщениях коммитов могут (MAY) использоваться _типы_, отличные от - `feat` и `fix`. Например, `docs: updated ref docs`. + `feat` и `fix`. Например, `docs: updated ref docs`. 1. Единицы информации, которые составляют «Соглашение о коммитах», не должны (MUST NOT) обрабатываться разработчиками как чувствительные к регистру, за исключением `BREAKING CHANGE`, которое должно (MUST) быть прописными. @@ -161,22 +169,22 @@ Refs: #123 ## Зачем использовать «Соглашение о коммитах» -* Автоматическое создание списков изменения. -* Автоматическое определение семантического повышения версии (на основе _типов_ +- Автоматическое создание списков изменения. +- Автоматическое определение семантического повышения версии (на основе _типов_ совершённых коммитов). -* Информирование товарищей по команде, общественности и других заинтересованных +- Информирование товарищей по команде, общественности и других заинтересованных сторон о характере изменений. -* Запуск процессов сборки и публикации. -* Упрощать людям участие в ваших проектах, позволив им изучить более +- Запуск процессов сборки и публикации. +- Упрощать людям участие в ваших проектах, позволив им изучить более структурированную историю коммитов. ## FAQ (часто задаваемые вопросы) ### Как мне поступать с сообщениями коммитов на начальном этапе разработки? -Мы рекомендуем действовать так, как если бы вы уже выпустили продукт. Обычно -*кто-то*, даже если это ваши коллеги-разработчики программного обеспечения, -использует ваше программное обеспечение. Они захотят знать, что исправлено, +Мы рекомендуем действовать так, как если бы вы уже выпустили продукт. Обычно +_кто-то_, даже если это ваши коллеги-разработчики программного обеспечения, +использует ваше программное обеспечение. Они захотят знать, что исправлено, что ломается и т. д. ### _Типы_ в заголовке коммита должны быть прописными или строчными? @@ -185,21 +193,21 @@ Refs: #123 ### Что мне делать, если коммит соответствует более чем одному _типу_? -По возможности вернитесь назад и сделайте несколько коммитов. Часть +По возможности вернитесь назад и сделайте несколько коммитов. Часть преимущества «Соглашения о коммитах» - его способность побуждать нас делать более организованные коммиты и PRs (pull requests, или запросы на вытягивание). ### Разве это не препятствует интенсивной разработке и быстрой итерации? -Это препятствует быстрому неорганизованному движению. Это поможет вам быстро +Это препятствует быстрому неорганизованному движению. Это поможет вам быстро продвигаться в долгосрочной перспективе в нескольких проектах с разными участниками. ### Может ли «Соглашение о коммитах» привести разработчиков к ограничению _типов_ совершаемых ими коммитов, потому что они будут думать в соответствии с предоставленными _типами_? «Соглашение о коммитах» побуждает нас делать больше определённых _типов_ -коммитов, таких, как `fix`. Помимо этого, гибкость «Соглашения о коммитах» +коммитов, таких, как `fix`. Помимо этого, гибкость «Соглашения о коммитах» позволяет вашей команде придумывать свои собственные _типы_ и со временем изменять их. @@ -208,7 +216,7 @@ Refs: #123 Коммиты _типа_ `fix` должны быть переведены в выпуски `PATCH`, `feat` — в `MINOR`, `BREAKING CHANGE`, независимо от _типа_, — в `MAJOR`. -### Как мне довести свои расширения до спецификации «Соглашение о коммитах». Например, `@jameswomack/standard-commit-spec`? +### Как мне довести свои расширения до спецификации «Соглашение о коммитах». Например, `@jameswomack/standard-commit-spec`? Мы рекомендуем использовать Семантическое Версионирование для выпуска ваших собственных расширений для этой спецификации (и призываем вас создавать @@ -216,24 +224,24 @@ Refs: #123 ### Что мне делать, если я случайно использовал неправильный _тип_ коммита? -#### Когда вы использовали неправильный _тип_, но соответствующий спецификации. Например, `fix` вместо `feat` +#### Когда вы использовали неправильный _тип_, но соответствующий спецификации. Например, `fix` вместо `feat` Перед объединением или выпуском ошибки мы рекомендуем использовать `git rebase --i` для редактирования истории коммитов. После выпуска редактирование будет +-i` для редактирования истории коммитов. После выпуска редактирование будет отличаться в зависимости от того, какие инструменты и процессы вы используете. -#### Когда вы использовали _тип_, не указанный в спецификации. Например, `feet` вместо `feat` +#### Когда вы использовали _тип_, не указанный в спецификации. Например, `feet` вместо `feat` В худшем случае это ещё не конец света, если коммит не соответствует -спецификации «Соглашения о коммитах». Это просто означает, что коммит будет +спецификации «Соглашения о коммитах». Это просто означает, что коммит будет пропущен инструментами, основанными на спецификации. ### Все ли мои участники должны использовать спецификацию «Соглашения о коммитах»? -Нет! Если вы используете рабочий процесс на основе соединения (squash) +Нет! Если вы используете рабочий процесс на основе соединения (squash) коммитов в Git, то ведущие специалисты по сопровождению могут приводить в порядок сообщения коммитов по мере их слияния (merge), не добавляя нагрузки для -обычных коммиттеров. Обычный рабочий процесс для этого состоит в том, чтобы +обычных коммиттеров. Обычный рабочий процесс для этого состоит в том, чтобы ваша система Git автоматически соединяла коммиты из PR и представляла форму для ведущего сопровождающего, чтобы ввести более подходящее сообщение коммита для слияния. @@ -241,17 +249,18 @@ Refs: #123 ### Как «Соглашение о коммитах» обрабатывает отмену коммитов? Отмена изменений кода может быть сложной: + - Вы отменяете изменения нескольких коммитов? - Если вы отмените изменения новых функций, должен ли следующий выпуск быть патчем? «Соглашение о коммитах» не делает явных попыток определить поведение отмены -изменений. Вместо этого мы оставляем авторам инструментов использование +изменений. Вместо этого мы оставляем авторам инструментов использование гибкости _типов_ и _сносок_ для разработки своей логики для обработки отмены изменений. Одна из рекомендаций — использовать _тип_ `revert` и _сноску_, которая -ссылается на отменяемые хэш-суммы коммитов. Например: +ссылается на отменяемые хэш-суммы коммитов. Например: ``` revert: let us never again speak of the noodle incident From 679bce7e2462129b7a5c9411a94e1f639560d18c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=D0=98=D0=B2=D0=B0=D0=BD=D0=BE=D0=B2=20=D0=9F=D0=B0=D0=B2?= =?UTF-8?q?=D0=B5=D0=BB=20=D0=A0=D0=BE=D0=BC=D0=B0=D0=BD=D0=BE=D0=B2=D0=B8?= =?UTF-8?q?=D1=87?= Date: Sat, 30 Aug 2025 13:20:49 +0300 Subject: [PATCH 5/5] docs(ru): fix ordered lists to use sequential numbering --- content/v1.0.0/index.ru.md | 64 +++++++++++++++++++------------------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/content/v1.0.0/index.ru.md b/content/v1.0.0/index.ru.md index 3a651951..a744fd8c 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` при + использовании в качестве токена в _сноске_. ## Зачем использовать «Соглашение о коммитах»