Исправить пробелы

Удалить лишний пробел перед запятой
Добавить пробел перед скобкой
Удалить замыкающие пробелы
Заменить двойные пробелы в одинарные между словами в не в коде

Author: Viktor-Yegay

book/02-git-basics/sections/getting-a-repository.asc

@@ -41,7 +41,7 @@ $ git init
 Подробное описание файлов, содержащихся в только что созданном вами каталоге `.git`, приведено в главе <<ch10-git-internals#ch10-git-internals>>(((команды git, init)))
 
 Если вы хотите добавить под версионный контроль существующие файлы (в отличие от пустого каталога), вам стоит добавить их в индекс и осуществить первый коммит изменений.
-Добиться этого вы сможете запустив команду `git add` несколько раз, указав индексируемые файлы, а затем выполнив `git commit`: 
+Добиться этого вы сможете запустив команду `git add` несколько раз, указав индексируемые файлы, а затем выполнив `git commit`:
 
 [source,console]
 ----

book/02-git-basics/sections/recording-changes.asc

@@ -168,7 +168,7 @@ Changes not staged for commit:
 Теперь `CONTRIBUTING.md` отображается как проиндексированный и непроиндексированный одновременно.
 Как такое возможно?
 Такая ситуация наглядно демонстрирует, что Git индексирует файл в точности в том состоянии, в котором он находился, когда вы выполнили команду  `git add`.
-Если вы выполните коммит сейчас, то файл `CONTRIBUTING.md` попадёт в коммит в том состоянии, в котором он находился, когда вы последний раз выполняли команду `git add` , а не в том, в котором он находится в вашем рабочем каталоге в момент выполнения `git commit`.
+Если вы выполните коммит сейчас, то файл `CONTRIBUTING.md` попадёт в коммит в том состоянии, в котором он находился, когда вы последний раз выполняли команду `git add`, а не в том, в котором он находится в вашем рабочем каталоге в момент выполнения `git commit`.
 Если вы изменили файл после выполнения `git add`, вам придётся снова выполнить `git add`, чтобы проиндексировать последнюю версию файла:
 
 [source,console]

book/02-git-basics/sections/undoing.asc

@@ -225,5 +225,5 @@ Changes to be committed:
 =====
 Важно понимать, что `git restore <file>` -- опасная команда.
 Любые локальные изменения, внесённые в этот файл, исчезнут -- Git просто заменит файл последней зафиксированной версией.
-Никогда не используйте эту команду, если точно не знаете, нужны ли вам эти несохранённые локальные изменения. 
+Никогда не используйте эту команду, если точно не знаете, нужны ли вам эти несохранённые локальные изменения.
 =====

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -53,11 +53,11 @@ $ vim index.html
 $ git commit -a -m 'Create new footer [issue 53]'
 ----
 
-.Ветка iss53 движется вперёд 
+.Ветка iss53 движется вперёд
 image::images/basic-branching-3.png["Ветка iss53 двигается вперёд"]
 
 И тут вы получаете сообщение об обнаружении на сайте уязвимости, и эту уязвимость устранить нужно немедленно.
-Благодаря Git вам не придётся ни пытаться реализовать исправление вместе с изменениями, которые вы сделали в ходе разработки `iss53`, ни прилагать усилия для отката этих изменений и возвращения к исходному состоянию перед началом разработки исправления. 
+Благодаря Git вам не придётся ни пытаться реализовать исправление вместе с изменениями, которые вы сделали в ходе разработки `iss53`, ни прилагать усилия для отката этих изменений и возвращения к исходному состоянию перед началом разработки исправления.
 Всё, что вам нужно -- переключиться на ветку `master`.
 
 Имейте в виду, что если рабочий каталог или индекс содержат незафиксированные изменения, конфликтующие с веткой, на которую вы хотите переключиться, то Git не позволит переключить ветки.

book/04-git-server/sections/protocols.asc

@@ -90,7 +90,7 @@ Git может работать через HTTP в двух различных 
 Если сервер не отвечает на умный запрос Git по HTTP, клиент Git попытается откатиться на более простой _Тупой_ HTTP-протокол.
 Тупой протокол ожидает, что голый репозиторий Git будет обслуживаться веб-сервером как набор файлов.
 Прелесть тупого протокола HTTP -- в простоте настройки.
-По сути, всё, что необходимо сделать -- поместить голый репозиторий в корневой каталог HTTP и установить обработчик `post-update`(смотри <<ch08-customizing-git#r_git_hooks>>).
+По сути, всё, что необходимо сделать -- поместить голый репозиторий в корневой каталог HTTP и установить обработчик `post-update` (смотри <<ch08-customizing-git#r_git_hooks>>).
 Теперь каждый может клонировать репозиторий, если имеет доступ к веб-серверу, на котором он был размещен.
 Таким образом, чтобы открыть доступ на чтение к вашему репозиторию посредством HTTP, нужно сделать что-то наподобие этого:
 

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

@@ -69,7 +69,7 @@ image::images/avatar-crop.png["Редактирование загруженно
 ==== Ваши почтовые адреса
 
 GitHub использует ваш почтовый адрес для привязки ваших Git коммитов к вашей учётной записи.
-Если вы используете несколько почтовых адресов в своих коммитах и  хотите, чтобы GitHub работал с ними корректно, то вам нужно будет добавить все используемые почтовые адреса в секцию под названием «Почтовые адреса» («Emails»), расположенную на вкладке «Администрирование» («Admin»).
+Если вы используете несколько почтовых адресов в своих коммитах и хотите, чтобы GitHub работал с ними корректно, то вам нужно будет добавить все используемые почтовые адреса в секцию под названием «Почтовые адреса» («Emails»), расположенную на вкладке «Администрирование» («Admin»).
 
 [[r_add_email_addresses]]
 .Почтовые адреса

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

@@ -27,7 +27,7 @@ image::images/newrepoform.png["Форма «New repository»"]
 Здесь мы не будем этого делать; если вам нужно освежить память, смотрите главу <<ch02-git-basics-chapter#ch02-git-basics-chapter>>.
 
 Теперь ваш проект хостится на GitHub и вы можете предоставить ссылку на него любому желающему.
-Все проекты на GitHub доступны как по HTTP `\https://github.com/<user>/<project_name>`, так  по SSH `\git@github.com:<user>/<project_name>`.
+Все проекты на GitHub доступны как по HTTP `\https://github.com/<user>/<project_name>`, так по SSH `\git@github.com:<user>/<project_name>`.
 Git может получать и отправлять изменения по обоим указанным ссылкам, при этом производится контроль доступа на основании учётных данных пользователя, осуществляющего подключение.
 
 [NOTE]

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

@@ -22,7 +22,7 @@ Git упрощает повторные слияния с одной и той 
 Если при выполнении слияния вы не сохраните сделанные изменения, то некоторые из описанных ниже приёмов могут привести к утрате этих наработок.
 
 Давайте рассмотрим очень простой пример.
-Допустим, у нас есть файл с исходниками на Ruby, выводящими на экран  строку 'hello world'.
+Допустим, у нас есть файл с исходниками на Ruby, выводящими на экран строку 'hello world'.
 
 [source,ruby]
 ----

book/07-git-tools/sections/replace.asc

@@ -112,7 +112,7 @@ Applying: fifth commit
 image::images/replace4.png[]
 
 Таким образом, мы переписали нашу свежую историю поверх вспомогательного базового коммита, который теперь содержит инструкции о том, как при необходимости восстановить полную историю.
-Мы можем отправить эту  историю в новый проект и теперь, когда люди клонируют его репозиторий, они будут видеть только два свежих коммита и после них базовый коммит с инструкциями.
+Мы можем отправить эту историю в новый проект и теперь, когда люди клонируют его репозиторий, они будут видеть только два свежих коммита и после них базовый коммит с инструкциями.
 
 Давайте представим себя на месте кого-то, кто впервые клонировал проект и хочет получить полную историю.
 Для получения исторических данных после клонирования усечённого репозитория, ему нужно добавить в список удалённых репозиториев исторический репозиторий и извлечь из него данные:

book/08-customizing-git/sections/policy.asc

@@ -376,7 +376,7 @@ access = get_acl_access_data('.git/acl')
 
 Второе отличие состоит в способе получения списка изменённых файлов.
 Если на сервере метод извлекает его из истории коммитов, то в данный момент на стороне клиента коммит ещё не создан, поэтому извлекать этот список необходимо из индекса.
-Вместо 
+Вместо
 
 [source,ruby]
 ----