Merge 679bce7e24 into 7bb1084f68

content/v1.0.0/index.ru.md

@@ -25,6 +25,7 @@ aliases: ["/ru/"]
 
 [необязательная(ые) сноска(и)]
 ```
+
 ---
 
 <br />
@@ -32,22 +33,22 @@ 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` добавляет новую функцию в ваш код
+2. **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` или
+3. **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. Другие _типы_ коммитов разрешены.  Например,
+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).
 
 Дополнительные _типы_ не требуются «Соглашению о коммитах» и не имеют неявного
-эффекта в семантическом версионировании (если только они не включают
+эффекта в Семантическом Версионировании (если только они не включают
 `BREAKING CHANGE`).
 <br /><br />
 _Контекст_ может быть добавлен к _типу_ коммита, чтобы предоставить
@@ -57,6 +58,7 @@ _Контекст_ может быть добавлен к _типу_ комми
 ## Примеры
 
 ### Сообщение коммита с _описанием_ и _сноской_ `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
 
@@ -109,65 +117,65 @@ 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) двоеточие (`:`) и пробел (` `).
-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) содержать пробелы и символы новой строки, а считывание
+10. _Сноска_ может (MAY) содержать пробелы и символы новой строки, а считывание
     должно (MUST) завершаться при обнаружении следующей допустимой пары
     токен-разделитель _сноски_.
-1. Критические изменения должны (MUST) быть указаны в _типе_, _контексте_ или
+11. Критические изменения должны (MUST) быть указаны в _типе_, _контексте_ или
     _сноске_ коммита.
-1. Если `BREAKING CHANGE` включено в _сноску_, то оно должно (MUST) состоять из
+12. Если `BREAKING CHANGE` включено в _сноску_, то оно должно (MUST) состоять из
     прописного текста `BREAKING CHANGE`, за которым следует двоеточие (`:`),
     пробел (` `) и _описание_. Например, `BREAKING CHANGE: environment
 variables now take precedence over config files`.
-1. Если критические изменения находятся в _типе_ или _контексте_, то они должны
+13. Если критические изменения находятся в _типе_ или _контексте_, то они должны
     (MUST) быть обозначены восклицательным знаком (`!`), непосредственно перед
     двоеточием (`:`). Если используется восклицательный знак (`!`), то
     `BREAKING CHANGE` может (MAY) быть опущен в _сноске_, а _описание_ коммита
     должно (SHALL) использоваться для описания критического изменения.
-1. В ваших сообщениях коммитов могут (MAY) использоваться _типы_, отличные от
+14. В ваших сообщениях коммитов могут (MAY) использоваться _типы_, отличные от
     `feat` и `fix`. Например, `docs: updated ref docs`.
-1. Единицы информации, которые составляют «Соглашение о коммитах», не должны
+15. Единицы информации, которые составляют «Соглашение о коммитах», не должны
     (MUST NOT) обрабатываться разработчиками как чувствительные к регистру, за
     исключением `BREAKING CHANGE`, которое должно (MUST) быть прописными.
-1. `BREAKING-CHANGE` должен (MUST) быть синонимом `BREAKING CHANGE` при
+16. `BREAKING-CHANGE` должен (MUST) быть синонимом `BREAKING CHANGE` при
     использовании в качестве токена в _сноске_.
 
 ## Зачем использовать «Соглашение о коммитах»
 
-* Автоматическое создание списков изменения.
+- Автоматическое создание списков изменения.
-* Автоматическое определение семантического повышения версии (на основе _типов_
+- Автоматическое определение семантического повышения версии (на основе _типов_
   совершённых коммитов).
-* Информирование товарищей по команде, общественности и других заинтересованных
+- Информирование товарищей по команде, общественности и других заинтересованных
   сторон о характере изменений.
-* Запуск процессов сборки и публикации.
+- Запуск процессов сборки и публикации.
-* Упрощать людям участие в ваших проектах, позволив им изучить более
+- Упрощать людям участие в ваших проектах, позволив им изучить более
   структурированную историю коммитов.
 
 ## FAQ (часто задаваемые вопросы)
@@ -175,7 +183,7 @@ Refs: #123
 ### Как мне поступать с сообщениями коммитов на начальном этапе разработки?
 
 Мы рекомендуем действовать так, как если бы вы уже выпустили продукт. Обычно
-*кто-то*, даже если это ваши коллеги-разработчики программного обеспечения,
+_кто-то_, даже если это ваши коллеги-разработчики программного обеспечения,
 использует ваше программное обеспечение. Они захотят знать, что исправлено,
 что ломается и т. д.
 
@@ -241,6 +249,7 @@ Refs: #123
 ### Как «Соглашение о коммитах» обрабатывает отмену коммитов?
 
 Отмена изменений кода может быть сложной:
+
 - Вы отменяете изменения нескольких коммитов?
 - Если вы отмените изменения новых функций, должен ли следующий выпуск быть
   патчем?