В русском языке нет слова «склонировать»

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

@@ -119,15 +119,15 @@ $ git fetch [remote-name]
 После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта, которые вы можете просмотреть или слить в любой момент.
 
 Когда вы клонируете репозиторий, команда `clone` автоматически добавляет этот удалённый репозиторий под именем «origin».
-Таким образом, `git fetch origin` извлекает все наработки, отправленные на этот сервер после того, как вы его склонировали (или получили изменения с помощью fetch).
+Таким образом, `git fetch origin` извлекает все наработки, отправленные на этот сервер после того, как вы его клонировали (или получили изменения с помощью fetch).
 Важно отметить, что команда `git fetch` забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент.
 Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.
 
 Если у вас есть ветка, настроенная на отслеживание удалённой ветки (обратитесь к главе 3 <<ch03-git-branching#ch03-git-branching>> за более подробной информацией), то вы можете использовать команду `git pull` чтобы автоматически получить изменения из удалённой ветки и слить их со своей текущей.(((git commands, pull)))
 Этот способ может для вас оказаться более простым или более удобным.
 К тому же, по умолчанию команда `git clone` автоматически настраивает вашу локальную ветку `master` на отслеживание удалённой ветки `master` на сервере, с которого вы клонировали репозиторий.
 Название веток может быть другим и зависит от ветки по умолчанию на сервере.
-Выполнение `git pull`, как правило, извлекает (fetch) данные с сервера, с которого вы изначально склонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.
+Выполнение `git pull`, как правило, извлекает (fetch) данные с сервера, с которого вы изначально клонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.
 
 [NOTE]
 ====

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

@@ -216,7 +216,7 @@ To git@github.com:schacon/simplegit.git
  * [new tag]         v1.4-lw -> v1.4-lw
 ----
 
-Теперь, если кто-то склонирует (clone) или выполнит `git pull` из вашего репозитория, то он получит вдобавок к остальному и ваши метки.
+Теперь, если кто-то клонирует (clone) или выполнит `git pull` из вашего репозитория, то он получит вдобавок к остальному и ваши метки.
 
 [NOTE]
 .`git push` отправляет оба типа тегов

book/02-git-basics/sections/viewing-history.asc

@@ -1,18 +1,18 @@
 [[r_viewing_history]]
 === Просмотр истории коммитов
 
-После того, как вы создали несколько коммитов или же склонировали репозиторий с уже существующей историей коммитов, вероятно вам понадобится возможность посмотреть что было сделано – историю коммитов.
+После того, как вы создали несколько коммитов или же клонировали репозиторий с уже существующей историей коммитов, вероятно вам понадобится возможность посмотреть что было сделано – историю коммитов.
 Одним из основных и наиболее мощных инструментов для этого является команда `git log`.
 
 Следующие несколько примеров используют очень простой проект «simplegit».
-Чтобы склонировать проект, используйте команду:
+Чтобы клонировать проект, используйте команду:
 
 [source,console]
 ----
 git clone https://github.com/schacon/simplegit-progit
 ----
 
-Если вы запустите команду `git log` в папке склонированного проекта, вы увидите следующий вывод:(((git commands, log)))
+Если вы запустите команду `git log` в папке клонированного проекта, вы увидите следующий вывод:(((git commands, log)))
 
 [source,console]
 ----

book/03-git-branching/sections/rebasing.asc

@@ -148,7 +148,7 @@ image::images/interesting-rebase-5.png["Окончательная истори
 В итоге, когда вы в очередной раз попытаетесь включить их работу в свою, вы получите путаницу.
 
 Давайте рассмотрим пример того, как перемещение публично доступных наработок может вызвать проблемы.
-Предположим, вы склонировали репозиторий с сервера и сделали какую-то работу.
+Предположим, вы клонировали репозиторий с сервера и сделали какую-то работу.
 И ваша история коммитов выглядит так:
 
 .Клонирование репозитория и выполнение в нём какой-то работы

book/03-git-branching/sections/remote-branches.asc

@@ -16,7 +16,7 @@
 
 Возможно, всё это сбивает с толку, поэтому давайте рассмотрим на примере.
 Скажем, у вас в сети есть свой Git-сервер с адресом `git.ourcompany.com`.
-Если вы с него что-то склонируете, команда `clone` автоматически назовёт его `origin`, заберёт оттуда все данные, создаст указатель на то, на что там указывает ветка `master`, и назовёт его локально `origin/master`.
+Если вы с него что-то клонируете, команда `clone` автоматически назовёт его `origin`, заберёт оттуда все данные, создаст указатель на то, на что там указывает ветка `master`, и назовёт его локально `origin/master`.
 Git также создаст вам локальную ветку `master`, которая будет начинаться там же, где и ветка `master` в `origin`, так что вам будет с чего начать.
 
 [NOTE]

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

@@ -16,7 +16,7 @@
 $ git daemon --reuseaddr --base-path=/srv/git/ /srv/git/
 ----
 
-Опция `--reuseaddr` позволит серверу перезапуститься без ожидания таймаута существующих подключений, `--base-path` позволит людям не указывать полный путь, чтобы склонировать проект, а путь в конце указывает демону Git где искать экспортируемые репозитории.
+Опция `--reuseaddr` позволит серверу перезапуститься без ожидания таймаута существующих подключений, `--base-path` позволит людям не указывать полный путь, чтобы клонировать проект, а путь в конце указывает демону Git где искать экспортируемые репозитории.
 Если у вас запущен сетевой экран, вы должны проколоть в нём дырочку, открыв порт 9418 на машине, где всё это запущено.
 
 Вы можете демонизировать этот процесс несколькими путями, в зависимости от операционной системы.

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

@@ -333,7 +333,7 @@ image::images/small-team-flow.png["Общий вид последователь
 При таком сценарии вся работа ведётся в отдельных ветках для каждой команды, а затем объединяется интегратором.
 
 Давайте рассмотрим рабочий процесс Джессики, так как она работает над двумя функциями, параллельно сотрудничая с разными разработчиками.
-Предположим, что репозиторий уже склонирован и она решает работать сначала над функцией `featureA`.
+Предположим, что репозиторий уже клонирован и она решает работать сначала над функцией `featureA`.
 Джессика создаёт новую ветку для этой функции и некоторое время работает над ней:
 
 [source,console]
@@ -504,7 +504,7 @@ image::images/managed-team-flow.png["Основная последователь
 Большинство сайтов Git хостинга поддерживают такую функцию (включая GitHub, BitBucket, repo.or.cz и другие), как и большинство тех, кто сопровождает проекты, ожидают такого же стиля участия.
 Следующий раздел посвящен проектам, которые предпочитают принимать исправления в виде патчей по электронной почте.
 
-Для начала, вам следует склонировать основной репозиторий, создать тематическую ветку для одного или нескольких патчей и работать в ней.
+Для начала, вам следует клонировать основной репозиторий, создать тематическую ветку для одного или нескольких патчей и работать в ней.
 Обычно, последовательность действий выглядит так:
 
 [source,console]

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

@@ -17,7 +17,7 @@
 .Централизованный рабочий процесс
 image::images/centralized_workflow.png["Централизованный рабочий процесс"]
 
-Это означает, что если два разработчика склонируют репозиторий и каждый внесёт изменения, то первый из них сможет отправить свои изменения в репозиторий без проблем.
+Это означает, что если два разработчика клонируют репозиторий и каждый внесёт изменения, то первый из них сможет отправить свои изменения в репозиторий без проблем.
 Второй разработчик должен слить изменения, сделанные первым разработчиком, чтобы избежать их перезаписи во время отправки на сервер.
 Эта концепция верна как для Git, так и для Subversion(((Subversion))) (или любой ЦСКВ), и прекрасно работает в Git.
 

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

@@ -494,7 +494,7 @@ v1.6.2-rc1-20-g8c5b85c
 ----
 
 Таким образом, вы можете сделать снимок или собрать сборку и дать ей понятное для человека название.
-К слову, если вы склонируете репозиторий Git и соберете его из исходного кода, то вывод команды `git --version` будет примерно таким же.
+К слову, если вы клонируете репозиторий Git и соберете его из исходного кода, то вывод команды `git --version` будет примерно таким же.
 Если попытаться получить имя коммита, которому назначен тег, то результатом будет название самого тега.
 
 По умолчанию, команда `git describe` поддерживает только аннотированные теги (созданные с использованием опций `-a` или `-s`); если вы хотите использовать легковесные (не аннотированные) метки, то укажите команде параметр `--tags`.

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

@@ -46,12 +46,12 @@ Total 6 (delta 0), reused 0 (delta 0)
 
 В результате вы получили файл `repo.bundle`, в котором содержатся все данные, необходимые для воссоздания ветки `master` репозитория.
 Команде `bundle` необходимо передать список или диапазон коммитов, которые вы хотите добавить в пакет.
-Если вы намереваетесь использовать пакет для того, чтобы склонировать репозиторий где-нибудь ещё, вы должны добавить в этот список HEAD, как это сделали мы.
+Если вы намереваетесь использовать пакет для того, чтобы клонировать репозиторий где-нибудь ещё, вы должны добавить в этот список HEAD, как это сделали мы.
 
 Вы можете отправить файл `repo.bundle` кому-нибудь по электронной почте или скопировать его на USB-диск, тем самым легко решив исходную проблему.
 
 С другой стороны, допустим, вы получили файл `repo.bundle` и хотите поработать над этим проектом.
-Вы можете склонировать репозиторий из бинарного файла в каталог, почти также как вы делаете это при использовании URL.
+Вы можете клонировать репозиторий из бинарного файла в каталог, почти также как вы делаете это при использовании URL.
 
 [source,console]
 ----
@@ -83,7 +83,7 @@ b1ec324 first commit
 
 Для того, чтобы сделать это, вы должны вычислить различия.
 Как мы рассказывали в <<r_commit_ranges>>, вы можете указать диапазон коммитов несколькими способами.
-Для того, чтобы получить три коммита из нашей основной ветки, которые отсутствовали в изначально склонированной ветке, мы можем использовать запись вида `origin/master..master` или `master ^origin/master`.
+Для того, чтобы получить три коммита из нашей основной ветки, которые отсутствовали в изначально клонированной ветке, мы можем использовать запись вида `origin/master..master` или `master ^origin/master`.
 Вы можете проверить ее с помощью команды `log`.
 
 [source,console]

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

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

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

@@ -14,7 +14,7 @@
 
 Git решает эту проблему, предоставляя функциональность подмодулей.
 Подмодули позволяют вам сохранить один Git-репозиторий, как поддиректорию другого Git-репозитория.
-Это даёт вам возможность склонировать в ваш проект другой репозиторий, но коммиты при этом хранить отдельно.
+Это даёт вам возможность клонировать в ваш проект другой репозиторий, но коммиты при этом хранить отдельно.
 
 [[r_starting_submodules]]
 ==== Начало работы с подмодулями