Привести к единообразию "перебазирование"

Author: Viktor-Yegay

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

@@ -60,7 +60,7 @@ image::images/basic-rebase-4.png["Перемотка ветки `master`"]
 Учтите, что снимок, на который ссылается ваш последний коммит -- является ли он последним коммитом после перебазирования или коммитом слияния после слияния -- в обоих случаях это один и тот же снимок, отличаются только истории коммитов.
 Перебазирование повторяет изменения из одной ветки поверх другой в том порядке, в котором эти изменения были сделаны, в то время как слияние берёт две конечные точки и сливает их вместе.
 
-==== Более интересные перемещения
+==== Более интересные перебазирования
 
 Также возможно сделать так, чтобы при перебазировании воспроизведение коммитов применялось к совершенно другой ветке.
 Для примера возьмём <<rrbdiag_e>>.
@@ -83,8 +83,8 @@ $ git rebase --onto master server client
 В этой команде говорится: «Переключись на ветку `client`, найди изменения относительно ветки `server` и примени их для ветки `master`».
 Несмотря на некоторую сложность этого способа, результат впечатляет.
 
-.Перемещение тематической ветки, ответвлённой от другой тематической ветки
-image::images/interesting-rebase-2.png["Перемещение тематической ветки, ответвлённой от другой тематической ветки"]
+.Перебазирование тематической ветки, ответвлённой от другой тематической ветки
+image::images/interesting-rebase-2.png["Перебазирование тематической ветки, ответвлённой от другой тематической ветки"]
 
 Теперь вы можете выполнить перемотку (fast-forward) для ветки `master` (см <<rrbdiag_g>>):
 
@@ -133,21 +133,21 @@ $ git branch -d server
 image::images/interesting-rebase-5.png["Окончательная история коммитов"]
 
 [[r_rebase_peril]]
-==== Опасности перемещения
+==== Опасности перебазирования
 
 (((перебазирование, опасности)))
 Но даже перебазирование, при всех своих достоинствах, не лишено недостатков, которые можно выразить одной строчкой:
 
-**Не перемещайте коммиты, уже отправленные в публичный репозиторий**
+**Не перебазируйте коммиты, уже отправленные в публичный репозиторий**
 
 Если вы будете придерживаться этого правила, всё будет хорошо.
 Если не будете, люди возненавидят вас, а ваши друзья и семья будут вас презирать.
 
-Когда вы что-то перемещаете, вы отменяете существующие коммиты и создаёте новые, похожие на старые, но являющиеся другими.
+Когда вы что-то перебазируете, вы отменяете существующие коммиты и создаёте новые, похожие на старые, но являющиеся другими.
 Если вы куда-нибудь отправляете свои коммиты и другие люди забирают их себе и в дальнейшем основывают на них свою работу, а затем вы переделываете эти коммиты командой `git rebase` и выкладываете их снова, то ваши коллеги будут вынуждены заново выполнять слияние для своих наработок.
 В итоге, когда вы в очередной раз попытаетесь включить их работу в свою, вы получите путаницу.
 
-Давайте рассмотрим пример того, как перемещение публично доступных наработок может вызвать проблемы.
+Давайте рассмотрим пример того, как перебазирование публично доступных наработок может вызвать проблемы.
 Предположим, вы клонировали репозиторий с сервера и сделали какую-то работу.
 И ваша история коммитов выглядит так:
 
@@ -179,7 +179,7 @@ image::images/perils-of-rebasing-4.png["Вы снова выполняете с
 Логично предположить, что разработчик не хочет, чтобы `C4` и `C6` были в истории, и именно поэтому она перебазируется в первую очередь.
 
 [[r_rebase_rebase]]
-==== Меняя базу, меняй основание
+==== При перебазировании, перебазируйте
 
 Если вы попали в такую ситуацию, у Git есть особая магия чтобы вам помочь.
 Если кто-то в вашей команде форсирует отправку изменений на сервер, переписывающих работу, на которых базировалась ваша работа, то ваша задача будет состоять в определении того, что именно было ваше, а что было переписано ими.
@@ -199,8 +199,8 @@ image::images/perils-of-rebasing-4.png["Вы снова выполняете с
 Таким образом, вместо результата, который мы можем наблюдать на <<r_merge_rebase_work>>, у нас получилось бы что-то вроде <<r_rebase_rebase_work>>.
 
 [[r_rebase_rebase_work]]
-.Перемещение в начало force-pushed перемещённой работы
-image::images/perils-of-rebasing-5.png["Перемещение в начало force-pushed перемещённой работы"]
+.Перебазирование в начало force-pushed перебазированной работы
+image::images/perils-of-rebasing-5.png["Перебазирование в начало force-pushed перебазированной работы"]
 
 Это возможно, если `C4` и `C4'` фактически являются одним и тем же патчем, который был сделан вашим коллегой.
 В противном случае `rebase` не сможет определить дубликат и создаст ещё один патч, подобный `C4` (который с большой вероятностью не удастся применить чисто, поскольку в нём уже присутствуют некоторые изменения).
@@ -211,14 +211,14 @@ image::images/perils-of-rebasing-5.png["Перемещение в начало f
 Если вы используете `git pull` и хотите использовать `--rebase` по умолчанию, вы можете установить соответствующее значение конфигурации `pull.rebase` с помощью команды `git config --global pull.rebase true`.
 
 Если вы рассматриваете перебазирование как способ наведения порядка и работаете с коммитами локально до их отправки или ваши коммиты никогда не будут доступны публично -- у вас всё будет хорошо.
-Однако, если вы перемещаете коммиты, отправленные в публичный репозиторий, и есть вероятность, что работа некоторых людей основывается на этих коммитах, то ваши действия могут вызвать существенные проблемы, а вы -- вызвать презрение вашей команды.
+Однако, если вы перебазируете коммиты, отправленные в публичный репозиторий, и есть вероятность, что работа некоторых людей основывается на этих коммитах, то ваши действия могут вызвать существенные проблемы, а вы -- вызвать презрение вашей команды.
 
 Если в какой-то момент вы или ваш коллега находите необходимость в этом, убедитесь, что все знают, как применять команду `git pull --rebase` для минимизации последствий от подобных действий.
 
-==== Перемещение vs. Слияние
+==== Перебазирование в сравнении со слиянием
 
 (((перебазирование, против слияния)))(((слияние, против перебазирования)))
-Теперь, когда вы увидели перемещение и слияние в действии, вы можете задаться вопросом, что из них лучше.
+Теперь, когда вы увидели перебазирование и слияние в действии, вы можете задаться вопросом, что из них лучше.
 Прежде чем ответить на этот вопрос, давайте вернёмся немного назад и поговорим о том, что означает история.
 
 Одна из точек зрения заключается в том, что история коммитов в вашем репозитории -- это *запись того, что на самом деле произошло*.

book/09-git-and-other-scms/sections/client-svn.asc

@@ -233,7 +233,7 @@ ones (if any) seem to be successfully integrated into the working tree.
 Please see the above messages for details.
 ----
 
-Чтобы решить эту проблему запустите `git svn rebase`, которая заберёт все ревизии с сервера, которых у вас пока нет, и переместит (rebase) ваши локальные наработки на них:
+Чтобы решить эту проблему запустите `git svn rebase`, которая заберёт все ревизии с сервера, которых у вас пока нет, и перебазирует (rebase) ваши локальные наработки на них:
 
 [source,console]
 ----