fix(ru): hyperlinks and spelling

content/v1.0.0/index.ru.md

@@ -11,7 +11,7 @@ aliases: ["/ru/"]
 писать сообщения коммитов.  Оно описывает простой набор правил для создания
 понятной истории коммитов, а также позволяет проще разрабатывать инструменты
 автоматизации, основанные на истории коммитов.  Данное соглашение совместимо с
-[семантическим версионированием][semver], описывая новые функции, исправления и
+[Семантическим Версионированием](https://semver.org/lang/ru/), описывая новые функции, исправления и
 изменения, нарушающие обратную совместимость в сообщениях коммитов.
 
 Сообщения коммитов должны быть следующей структуры:
@@ -32,23 +32,22 @@ aliases: ["/ru/"]
 пользователям вашей библиотеки:
 
 1. **fix:** коммит _типа_ `fix` исправляет баг в вашем коде (соответствует
-   `PATCH` в [семантическом версионировании][semver]).
+   [`PATCH`](https://semver.org/lang/ru/#%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE) в Cемантическом Версионировании).
 1. **feat:** коммит _типа_ `feat` добавляет новую функцию в ваш код
-   (соответствует `MINOR` в [семантическом версионировании][semver]).
+   (соответствует [`MINOR`](https://semver.org/lang/ru/#%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE) в Cемантическом Версионировании).
 1. **BREAKING CHANGE:** коммит, который имеет _сноску_ `BREAKING CHANGE` или
    коммит, заканчивающийся восклицательным знаком (`!`) после _типа_ или
    _контекста_, вводящий изменение(я), нарушающие обратную совместимость
-   (соответствует `MAJOR` в [семантическом версионировании][semver]).
+   (соответствует [`MAJOR`](https://semver.org/lang/ru/#%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE) в Cемантическом Версионировании).
    `BREAKING CHANGE` может быть частью коммита любого _типа_.
 1. Другие _типы_ коммитов разрешены.  Например,
-   [@commitlint/config-conventional][@commitlint/config-conventional] (основан
+   [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (основан
-   на [соглашении Angular][angular-convention]) рекоммендует `build`, `chore`,
+   на [соглашении Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) рекомендует `build`, `chore`,
    `ci`, `docs`, `style`, `refactor`, `perf`, `test` и другие.
-1. Другие _сноски_ коммитов могут быть аналогичны соглашению [git trailer
+1. Другие _сноски_ коммитов могут быть аналогичны соглашению [git trailer format](https://git-scm.com/docs/git-interpret-trailers).
-   format][git-trailer-format].
 
 Дополнительные _типы_ не требуются «Соглашению о коммитах» и не имеют неявного
-эффекта в [семантическом версионировании][semver] (если только они не включают
+эффекта в семантическом версионировании (если только они не включают
 `BREAKING CHANGE`).
 <br /><br />
 _Контекст_ может быть добавлен к _типу_ коммита, чтобы предоставить
@@ -106,9 +105,9 @@ Refs #133
 ## Спецификация
 
 Слова «MUST», «MUST NOT», «REQUIRED», «SHALL», «MAY» и «OPTIONAL» в данном
-документе должны интерпретироваться как в [RFC 2119][rfc-2119].
+документе должны интерпретироваться как в [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
 
-1. Коммиты должны (MUST) начинатся с _типа_, который является существительным:
+1. Коммиты должны (MUST) начинается с _типа_, который является существительным:
    `feat`, `fix` и т.д. За ним следует необязательный (OPTIONAL) _контекст_,
    необязательный (OPTIONAL) восклицательный знак (`!`) и обязательные
    (REQUIRED) двоеточие (`:`) и пробел (` `).
@@ -131,15 +130,15 @@ Refs #133
 1. В одной или нескольких _сносках_ может (MAY) быть одна пустая строка после
    _тела_.  Каждая _сноска_ должна (MUST) состоять из токена слова, за которым
    следует разделитель `:<пробел>` или `<пробел>#`, за которым следует
-   строковое значение (основано на [git trailer format][git-trailer-format]).
+   строковое значение (основано на [git trailer format](https://git-scm.com/docs/git-interpret-trailers)).
 1. Токен _сноски_ должен (MUST) использовать `-` вместо пробельных символов.
    Например, `Acked-by` (это помогает отличить раздел _сноски_ от его _тела_,
    состоящего из нескольких абзацев).  Исключение составляет `BREAKING CHANGE`,
    которое может (MAY) также использоваться как токен.
-1. _Сноска_ может (MAY) содержать пробелы и символы новой строки, а парсер
+1. _Сноска_ может (MAY) содержать пробелы и символы новой строки, а считывание
-   должен (MUST) завершаться при обнаружении следующей допустимой пары
+   должно (MUST) завершаться при обнаружении следующей допустимой пары
    токен-разделитель _сноски_.
-1. Критические изменения должны (MUST) быть указаны в _типе_, _контесте_ или
+1. Критические изменения должны (MUST) быть указаны в _типе_, _контексте_ или
    _сноске_ коммита.
 1. Если `BREAKING CHANGE` включено в _сноску_, то оно должно (MUST) состоять из
    прописного текста `BREAKING CHANGE`, за которым следует двоеточие (`:`),
@@ -186,7 +185,7 @@ Refs #133
 
 По возможности вернитесь назад и сделайте несколько коммитов.  Частью
 преимущества «Соглашения о коммитах» является способность побуждать нас делать
-более организованные коммиты и PRs (pull requests, или пулл-реквесты, или
+более организованные коммиты и PRs (pull requests, или
 запросы на вытягивание).
 
 ### Разве это не препятствует интенсивной разработке и быстрой итерации?
@@ -198,24 +197,24 @@ Refs #133
 ### Может ли «Соглашение о коммитах» привести разработчиков к ограничению _типов_ совершаемых ими коммитов, потому что они будут думать в соответствии с предоставленными _типами_?
 
 «Соглашение о коммитах» побуждают нас делать больше определённых _типов_
-коммитов, таких как `fix`.  Помимо этого, гибкость «Соглашения о коммитах»
+коммитов, таких, как `fix`.  Помимо этого, гибкость «Соглашения о коммитах»
 позволяет вашей команде придумывать свои собственные _типы_ и со временем
 изменять их.
 
-### Как это связано с [семантическим версионированием][semver]?
+### Как это связано с Семантическим Версионированием?
 
 Коммиты _типа_ `fix` должны быть переведены в выпуски `PATCH`, `feat` — в
 `MINOR`, `BREAKING CHANGE`, независимо от _типа_, — в `MAJOR`.
 
 ### Как мне довести свои расширения до спецификации «Соглашение о коммитах».  Например, `@jameswomack/standard-commit-spec`?
 
-Мы рекомендуем использовать [семантическое версионирование][semver] для выпуска
+Мы рекомендуем использовать Семантическое Версионирование для выпуска
 ваших собственных расширений для этой спецификации (и призываем вас создавать
 эти расширения!).
 
 ### Что мне делать, если я случайно использовал неправильный _тип_ коммита?
 
-#### Когда вы использовали _тип_, соответствующий спецификации, но неправильный.  Например, `fix` вместо `feat`
+#### Когда вы использовали неправильный _тип_, но соответствующий спецификации.  Например, `fix` вместо `feat`
 
 Перед объединением или выпуском ошибки мы рекомендуем использовать `git rebase
 -i` для редактирования истории коммитов.  После выпуска редактирование будет