Typos (#272)

* исправлены ошибки и опечатки
* исправлены ошибки пунктуации
* исправлен перевод

book/05-distributed-git/sections/contributing.asc

@@ -51,9 +51,8 @@ image::images/git-diff-check.png[Вывод команды `git diff --check`.]
 Даже если вы не делали коммиты на выходных, то в понедельник используйте область подготовленных файлов для того, чтобы разделить проделанную работу по принципу минимум один коммит на задачу, давая полезные комментарии к каждому из них.
 Если несколько изменений касаются одного файла, используйте `git add --patch` для частичного добавления файлов в индекс (детально описано в <<ch07-git-tools#r_interactive_staging>>).
 Состояние проекта в конце ветки не зависит от количества сделанных вами коммитов, так как все изменения добавятся в один момент, поэтому постарайтесь облегчить задачу вашим коллегам, когда они будут просматривать ваши изменения.
-
 Такой подход так же облегчает извлечение или отмену отдельных изменений, если это вдруг потребуется в будущем.
-<<ch07-git-tools#r_rewriting_history>> описывает ряд полезных трюков Git для переписывания истории изменений и интерактивного инексирования -- используйте эти инструменты для создания чистой и понятной истории перед отправкой проделанной работы кому-то ещё.
+<<ch07-git-tools#r_rewriting_history>> описывает ряд полезных трюков Git для переписывания истории изменений и интерактивного индексирования -- используйте эти инструменты для создания чистой и понятной истории перед отправкой проделанной работы кому-то ещё.
 
 Последнее, что нужно иметь ввиду -- это сообщение коммита.
 Привычка создавать качественные сообщения к коммитам позволяет упростить использование и взаимодействие посредством Git.
@@ -498,9 +497,9 @@ image::images/managed-team-flow.png[Основная последователь
 
 (((contributing, public small project)))
 Участие в публичном проекте сильно отличается.
-Так как у вас нет доступа обновлять ветки пероекта напрямую, то передавать проделанную работу следует другим способом.
+Так как у вас нет доступа обновлять ветки проекта напрямую, то передавать проделанную работу следует другим способом.
 В первом примере рассматривается участие в публичном проекте посредством форка на Git платформах, где возможно его простое создание.
-Много Git хостинг сайтов поддерживают такую функцию (включая GitHub, BitBucket, repo.or.cz и другие), как и большинство тех, кто поддерживает проекты, ожидают такой стиль участия.
+Много Git хостинг сайтов поддерживают такую функцию (включая GitHub, BitBucket, repo.or.cz и другие), как и большинство тех, кто поддерживате проекты, ожидают такой стиль участия.
 Следующий раздел посвящен проектам, которые предпочитают принимать исправления в виде патчей по электронной почте.
 
 Для начала, вам следует склонировать основной репозиторий, создать тематическую ветку для одного или нескольких патчей и работать в ней.
@@ -636,7 +635,7 @@ image::images/public-small-3.png[История коммитов после ра
 ==== Публичный проект посредством E-Mail
 
 (((contributing, public large project)))
-Много проектов имеют устоявшиеся процедуры по принятию патчей -- вам следует знакомиться с правилами для каждого проекта, так как они могут отличаться.
+Много проектов имеют устоявшиеся процедуры по принятию патчей -- вам следует ознакомиться с правилами для каждого проекта, так как они могут отличаться.
 Так как существует несколько больших старых проектов, которые принимают патчи посредством почтовых рассылок, мы рассмотрим такой пример.
 
 Рабочий процесс похож на предыдущий -- вы создаёте тематическую ветку для каждого набора патчей, над которыми собираетесь работать.
@@ -654,7 +653,7 @@ $ git commit
 
 (((git commands, format-patch)))
 Сейчас у вас два коммита, которые вы хотите отправить в почтовую рассылку.
-Используйте команду `git format-patch` для генерации файлов в формате mbox, которые можно отправить по почте -- это обернёт каждый коммит в e-mail сообщение, где первая строка из сообщение коммита будет темой письма, а остальные строки плюс сам патч будут телом письма.
+Используйте команду `git format-patch` для генерации файлов в формате mbox, которые можно отправить по почте -- это обернёт каждый коммит в e-mail сообщение, где первая строка из сообщения коммита будет темой письма, а остальные строки плюс сам патч будут телом письма.
 Применение патча в формате e-mail, сгенерированного с помощью команды `format-patch`, сохраняет всю информацию о коммите должным образом.
 
 [source,console]
@@ -702,7 +701,7 @@ index 76f47bc..f9815f1 100644
 Вы можете редактировать эти файлы, добавляя информацию для списка рассылки, но которую вы не хотите видеть в сообщении к коммиту.
 Если добавить текст между строкой `---` и началом патча (строка `diff --git`), то разработчики увидят его, но применяться он не будет.
 
-Для отправки в список рассылки можно либо вставить файлы в почтовую программу, либо отправить их командной строки.
+Для отправки в список рассылки можно либо вставить файлы в почтовую программу, либо отправить их из командной строки.
 Вставка текста обычно сопровождается проблемами форматирования, особенно при использовании ``умных'' клиентов, которые не заботятся о переносе строк и пробелах соответствующим образом.
 К счастью, Git предоставляет утилиту, которая умеет отправлять корректно отформатированные патчи по протоколу IMAP.
 Позже мы покажем как отправлять патчи через Gmail, так сложилось что мы знаем этот почтовый агент лучше других; вы можете воспользоваться инструкциями по использованию большого числа почтовых программ в вышеупомянутом файле `Documentation/SubmittingPatches` из исходных кодов Git.

book/05-distributed-git/sections/maintaining.asc

@@ -442,7 +442,7 @@ user: "Scott Chacon <[email protected]>"
 
 Если вы используете цифровую подпись при расстановке тегов, то возникает проблема распространения публичной части PGP ключа, использованного при создании подписи.
 Сопровождающий Git проекта может решить эту проблему добавив в репозиторий свой публичный ключ как бинарный объект и установив ссылающийся на него тег.
-Чтобы это сделать, выберите нужный ключ и списка доступных, который можно получить с помощью команды `gpg --list-keys`:
+Чтобы это сделать, выберите нужный ключ из списка доступных, который можно получить с помощью команды `gpg --list-keys`:
 
 [source,console]
 ----

book/06-github/sections/1-setting-up-account.asc

@@ -39,7 +39,7 @@ image::images/account-settings.png[Ссылка ``Настройка учётн
 .Ссылка (``SSH keys'').
 image::images/ssh-keys.png[Ссылка (``SSH keys'')]
 
-Затем нажмите на кнопку "`Добавить ключ SSH`"("`Add an SSH key`"), задайте имя ключа а так же скопируйте и вставьте сам публичный ключ из `~/.ssh/id_rsa.pub` (ну или как бы у вас не назывался этот файл) в текстовое поле, затем нажмите ``Добавить ключ''(``Add key'').
+Затем нажмите на кнопку "`Добавить ключ SSH`"("`Add an SSH key`"), задайте имя ключа, а так же скопируйте и вставьте сам публичный ключ из `~/.ssh/id_rsa.pub` (ну или как бы у вас не назывался этот файл) в текстовое поле, затем нажмите ``Добавить ключ''(``Add key'').
 
 [NOTE]
 ====

book/06-github/sections/2-contributing.asc

@@ -201,7 +201,7 @@ GitHub так же проверяет может ли запрос на слия
 ===== Запросы слияния как Патчи
 
 Важно понимать, что многие проекты не воспринимают запросы слияния как очередь идеальных патчей, которые должны применяться аккуратно и по порядку, как и большинство проектов, участие в которых основывается на отправке набора патчей через списки почтовых рассылок.
-Большинство проектов на GitHub понимают ветки запросов слияние как беседу относительно предлагаемого изменения, завершающуюся слиянием унифицированных изменений.
+Большинство проектов на GitHub понимают ветки запросов на слияние как беседу относительно предлагаемого изменения, завершающуюся слиянием унифицированных изменений.
 
 Это важное различие, так как изменение предлагается до того, как код станет считаться идеальным, что гораздо реже происходит с распространяемыми наборами патчей через списки рассылок.
 Обсуждение происходит на более раннем этапе и выработка правильного решения происходит за счёт усилий сообщества.
@@ -324,7 +324,7 @@ image::images/mentions-03-closed.png[Отображение перекрёстн
 
 Кроме идентификационных номеров, можно ссылаться на конкретный коммит используя SHA-1.
 Следует указывать полный 40 символьный хэш SHA-1, но если GitHub увидит его в комментарии, то автоматически подставит ссылку на коммит.
-Как было сказано выше, вы можете ссылаться на коммиты как в других, так и в ответвлённых репозиториях точно так же как делали это с Проблемами.
+Как было сказано выше, вы можете ссылаться на коммиты как в других, так и в ответвлённых репозиториях точно так же, как делали это с Проблемами.
 
 ==== Разметка
 
@@ -406,7 +406,7 @@ image::images/markdown-04-fenced-code.png[Отображение обрамле
 ====== Цитирование
 
 Если вы отвечаете только на часть большого комментария, то можно цитировать только выбранную часть, предваряя её символом `>`.
-Это на столько часто используется, что даже существует комбинация клавиш для этого.
+Это настолько часто используется, что даже существует комбинация клавиш для этого.
 Если в комментарии выделить текст, на который вы собираетесь ответить, и нажать клавишу `r`, то выделенный текст будет включён как цитата в ваш комментарий.
 
 Цитаты выглядят примерно так:

book/06-github/sections/3-maintaining.asc

@@ -15,15 +15,15 @@ image::images/newrepo.png[Раздел ``Your repositories''.]
 .Выпадающее меню ``New repository''.
 image::images/new-repo.png[Выпадающее меню ``New repository''.]
 
-Это приведёт к открытию формы ``new repository'':
+Это приведёт к открытию формы ``New repository'':
 
 .Форма ``new repository''
-image::images/newrepoform.png[Форма ``new repository''.]
+image::images/newrepoform.png[Форма ``New repository''.]
 
 Всё, что в действительности нужно сделать, так это указать название проекта, все остальные поля опциональны.
 Сейчас, просто нажмите кнопку ``Create Repository'' и ваш новый репозиторий с названием `<пользователь>/<имя_проекта>` готов.
 
-Так как в репозитории ещё нет кода, GitHub отобразит инструкции о том как создать совершенно новый репозиторий или подключить существующий Git проект.
+Так как в репозитории ещё нет кода, GitHub отобразит инструкции о том, как создать совершенно новый репозиторий или подключить существующий Git проект.
 Здесь мы не будем этого делать; если вам нужно освежить память, воспользуйтесь <<ch02-git-basics#ch02-git-basics>>.
 
 Теперь ваш проект хостится на GitHub и вы можете предоставить ссылку на него любому желающему.

book/07-git-tools/sections/advanced-merging.asc

@@ -561,7 +561,7 @@ image::images/undomerge-reset.png[История после `git reset --hard HE
 [[r_reverse_commit]]
 ===== Отмена коммита
 
-Если перемещение указателей ветки вам не подходит, Git предоставляет возможность сделать новый коммит, которая откатывает все изменения, сделанные в другой.
+Если перемещение указателей ветки вам не подходит, Git предоставляет возможность сделать новый коммит, который откатывает все изменения, сделанные в другом.
 Git называет эту операцию ``восстановлением'' (``revert''), в данном примере вы можете вызвать её следующим образом:
 
 [source,console]