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

Удалить лишний пробел перед запятой Добавить пробел перед скобкой Удалить замыкающие пробелы Заменить двойные пробелы в одинарные между словами в не в коде
progit · Sep 9, 2024 · dcd5700 · dcd5700
1 parent f73deea
commit dcd5700
Show file tree

Hide file tree

Showing 14 changed files with 16 additions and 16 deletions.
diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/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]
 ----

diff --git a/book/02-git-basics/sections/recording-changes.asc b/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]

diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc
@@ -225,5 +225,5 @@ Changes to be committed:
 =====
 Важно понимать, что `git restore <file>` -- опасная команда.
 Любые локальные изменения, внесённые в этот файл, исчезнут -- Git просто заменит файл последней зафиксированной версией.
-Никогда не используйте эту команду, если точно не знаете, нужны ли вам эти несохранённые локальные изменения. 
+Никогда не используйте эту команду, если точно не знаете, нужны ли вам эти несохранённые локальные изменения.
 =====
diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/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 не позволит переключить ветки.

diff --git a/book/04-git-server/sections/protocols.asc b/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, нужно сделать что-то наподобие этого:
 

diff --git a/book/06-github/sections/1-setting-up-account.asc b/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]]
 .Почтовые адреса

diff --git a/book/06-github/sections/3-maintaining.asc b/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 `\[email protected]:<user>/<project_name>`.
+Все проекты на GitHub доступны как по HTTP `\https://github.com/<user>/<project_name>`, так по SSH `\[email protected]:<user>/<project_name>`.
 Git может получать и отправлять изменения по обоим указанным ссылкам, при этом производится контроль доступа на основании учётных данных пользователя, осуществляющего подключение.
 
 [NOTE]

diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc
@@ -22,7 +22,7 @@ Git упрощает повторные слияния с одной и той
 Если при выполнении слияния вы не сохраните сделанные изменения, то некоторые из описанных ниже приёмов могут привести к утрате этих наработок.
 
 Давайте рассмотрим очень простой пример.
-Допустим, у нас есть файл с исходниками на Ruby, выводящими на экран  строку 'hello world'.
+Допустим, у нас есть файл с исходниками на Ruby, выводящими на экран строку 'hello world'.
 
 [source,ruby]
 ----

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

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

diff --git a/book/10-git-internals/sections/transfer-protocols.asc b/book/10-git-internals/sections/transfer-protocols.asc
@@ -272,7 +272,7 @@ $ ssh -x git@server "git-upload-pack 'simplegit-progit.git'"
 0000
 ----
 
-Это очень похоже на использование `git-upload-pack` по SSH, вот только обмен данными производится отдельным запросом: 
+Это очень похоже на использование `git-upload-pack` по SSH, вот только обмен данными производится отдельным запросом:
 
 [source]
 ----

diff --git a/book/A-git-in-other-environments/sections/guis.asc b/book/A-git-in-other-environments/sections/guis.asc
@@ -31,8 +31,8 @@ Gitk принимает много различных опций, большин
 Возможно, наиболее полезная опция -- `--all`, которая указывает Gitk выводить коммиты, доступные из _любой_ ссылки, а не только HEAD.
 Интерфейс Gitk выглядит так:
 
-.`gitk`- инструмент  для просмотра истории
-image::images/gitk.png["`gitk`- инструмент  для просмотра истории"]
+.`gitk`- инструмент для просмотра истории
+image::images/gitk.png["`gitk`- инструмент для просмотра истории"]
 
 Интерфейс на картинке похож на вывод `git log --graph`; каждая точка соответствует коммиту, линии отражают родство коммитов, а ссылки изображены цветными прямоугольниками.
 Жёлтая точка обозначает HEAD, а красная -- изменения, которые попадут в следующий коммит.

diff --git a/book/B-embedding-git/sections/jgit.asc b/book/B-embedding-git/sections/jgit.asc
@@ -155,6 +155,6 @@ for (Ref ref : remoteRefs) {
 Это лишь небольшой пример всех возможностей JGit.
 Если вы заинтересованы в более детальной работе с JGit, вот список источников информации для старта:
 
-* Официальная документация по JGit API доступна в Интернете на  https://www.eclipse.org/jgit/documentation[^].
+* Официальная документация по JGit API доступна в Интернете на https://www.eclipse.org/jgit/documentation[^].
   Это обыкновенный Javadoc, так что ваша любимая IDE может скачать её и использовать оффлайн.
 * «Поваренная книга» JGit, расположенная по адресу https://github.com/centic9/jgit-cookbook[^], включает в себя много готовых рецептов использования JGit для решения тех или иных задач.
diff --git a/ch05-distributed-git.asc b/ch05-distributed-git.asc
@@ -16,5 +16,5 @@ include::book/05-distributed-git/sections/maintaining.asc[]
 === Заключение
 
 Теперь вы должны чувствовать себя достаточно свободно как внося свой вклад в проект под управлением Git, так и занимаясь поддержкой своего собственного проекта или интегрированием наработок других пользователей.
-Поздравляем, вы опытный Git-разработчик! 
+Поздравляем, вы опытный Git-разработчик!
 В следующей главе вы узнаете о том, как использовать самый большой и самый популярный Git хостинг -- GitHub.