xsteadfastx/conventionalcommits.org
1
0
Fork 0
mirror of https://github.com/conventional-commits/conventionalcommits.org.git synced 2025-09-18 21:07:48 +02:00
Code Issues Projects Releases Wiki Activity

docs(ru): fix ordered lists to use sequential numbering

Browse Source
This commit is contained in:
Иванов Павел Романович 2025-08-30 13:20:49 +03:00
parent ec7a65ff2f
commit 679bce7e24
1 changed files with 32 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
content/v1.0.0/index.ru.md
View File

@ -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` при
использовании в качестве токена в _сноске_.
## Зачем использовать «Соглашение о коммитах»