Merge pull request #200 from burlakvo/burlakvo

2/remotes: fixes

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

@@ -1,19 +1,18 @@
 [[_remote_repos]]
 === Взаємодія з віддаленими сховищами
 
-Задля співпраці з будь-яким проектом Git, вам необхідно знати, як керувати віддаленими сховищами.
-Віддалені сховища -- це версії вашого проекту, що розташовані в Інтернеті, або десь у мережі.
+Задля співпраці з будь-яким проєктом Git, вам необхідно знати, як керувати віддаленими сховищами.
+Віддалені сховища -- це версії вашого проєкту, що розташовані в Інтернеті, або десь у мережі.
 Їх може бути декілька, кожне зазвичай або тільки для читання, або для читання та змін.
-Співпраця з іншими вимагає керування цими віддаленими сховищами, надсилання (`pushing`) та отримання (`pulling`) даних до та з них, коли ви хочете зробити внесок.
-Керування віддаленими сховищами потребує знань про додавання віддалених сховищ, видалення сховищ, що більше не потрібні, керування різноманітними віддаленими гілками та визначення слідкування за ними, і багато іншого.
+Співпраця з іншими вимагає керування цими віддаленими сховищами, надсилання (`pushing`) та стягування (`pulling`) даних до та з них, коли ви хочете зробити внесок.
+Керування віддаленими сховищами потребує знань про додавання віддалених сховищ, вилучення сховищ, що більше не потрібні, керування різноманітними віддаленими гілками та визначення стежити за ними чи ні, і багато іншого.
 У цій секції, ми пройдемо ці вміння керування віддаленими сховищами.
 
 [NOTE]
 .Віддалені сховища можуть розташовуватися на вашій локальній машині.
 ====
 Цілком можливо, що ви працюватимете з ``віддаленим'' сховищем, що, насправді, міститься на тій саме машині, що ви за нею працюєте.
 Слово ``віддалений'' не обовʼязково означає, що сховище зберігається десь в мережі чи Інтернеті -- лише що воно деінде.
-Working with such a remote repository would still involve all the standard pushing, pulling and fetching operations as with any other remote.
 Взаємодія з таким віддаленим сховищем все одно включатиме звичні операції `push`, `pull` і `fetch` -- як і з будь-яким іншим віддаленим сховищем.
 ====
 
@@ -89,7 +88,7 @@ pb	https://github.com/paulboone/ticgit (push)
 ----
 
 Тепер ви можете використати рядок `pb` в командному рядку замість повного посилання.
-Наприклад, якщо ви хочете отримати (`fetch`) усю інформацію, яке є в Пола, проте її нема у вашому сховищі, ви можете виконати `git fetch pb`:
+Наприклад, якщо ви хочете здобути (`fetch`) усю інформацію, яке є в Пола, проте її нема у вашому сховищі, ви можете виконати `git fetch pb`:
 
 [source,console]
 ----
@@ -107,33 +106,45 @@ From https://github.com/paulboone/ticgit
 (Ми розповімо що таке гілки та як ними користуватися набагато докладніше в <<ch03-git-branching#ch03-git-branching>>.)
 
 [[_fetching_and_pulling]]
-==== Отримання (`fetching`) та затягування (`pulling`) з ваших віддалених сховищ
+==== Здобуття (`fetching`) та стягування (`pulling`) з ваших віддалених сховищ
 
-Як ви щойно побачили, щоб отримати дані з ваших віддалених проектів, ви можете виконати:(((git commands, fetch)))
+Як ви щойно побачили, щоб отримати дані з ваших віддалених проєктів, ви можете виконати:(((git commands, fetch)))
 
 [source,console]
 ----
 $ git fetch <remote>
 ----
 
-Ця команда заходить на віддалений проект та забирає звідти усі дані, котрих у вас досі нема.
+Ця команда заходить на віддалений проєкт та забирає звідти усі дані, котрих у вас досі нема.
 Після цього, у вас будуть посилання на всі гілки з того сховища, які ви можете зливати або оглядати в будь-який час.
 
 Якщо ви зробили клон сховища, команда автоматично додає це віддалене сховище під ім’ям ``origin''.
-Отже, `git fetch origin` отримує будь-яку нову працю, що її виклали на той сервер після того, як ви зробили його клон (або востаннє отримували зміни з нього).
+Отже, `git fetch origin` здобуває будь-яку нову працю, що її виклали на той сервер після того, як ви зробили його клон (або востаннє отримували зміни з нього).
 Важливо зауважити, що команда `git fetch` лише завантажує дані до вашого локального сховища -- вона автоматично не зливає їх з вашою роботою, та не змінює вашу поточну працю.
 Вам буде потрібно вручну її злити, коли ви будете готові.
 
-Якщо ваша поточна гілка налаштована слідкувати за віддаленою гілкою (докладніше в наступній секції та <<ch03-git-branching#ch03-git-branching>>), ви можете виконати команду `git pull` щоб автоматично отримати зміни та злити віддалену гілку до вашої поточної гілки.(((git commands, pull)))
-Це може бути легшим та зручнішим методом для вас. Та команда `git clone` автоматично налаштовує вашу локальну гілку master слідкувати за віддаленою гілкою master (хоча вона може називатись і по іншому) на віддаленому сервері, з якого ви зробили клон.
-Виконання `git pull` зазвичай дістає дані з серверу, з якого ви зробили клон, та намагається злити її з кодом, над яким ви зараз працюєте.
+Якщо ваша поточна гілка налаштована стежити за віддаленою гілкою (докладніше в наступній секції та <<ch03-git-branching#ch03-git-branching>>), ви можете виконати команду `git pull` щоб автоматично отримати зміни та злити віддалену гілку до вашої поточної гілки.(((git commands, pull)))
+Це може бути легшим та зручнішим методом для вас. Та команда `git clone` автоматично налаштовує вашу локальну гілку `master` стежити за віддаленою гілкою `master` (хоча вона може називатись і по іншому) на віддаленому сервері, з якого ви зробили клон.
+Виконання `git pull` зазвичай здобуває дані з серверу, з якого ви зробили клон, та намагається злити їх з кодом, над яким ви зараз працюєте.
+
+[NOTE]
+====
+Починаючи з версії Git 2.27 і вище, `git pull` повертатиме попередження, якщо параметр `pull.rebase` не встановлено.
+Git попереджатиме вас допоки ви не встановите значення для цього параметру.
+
+Якщо ви потребуєте типову поведінку від Git (перемотання, якщо можливе, або ж створення коміту злиття), виконайте команду:
+`git config --global pull.rebase "false"`
+
+Якщо ви бажаєте перебазовувати, коли стягуєте зміни:
+`git config --global pull.rebase "true"`
+====
 
 [[_pushing_remotes]]
 ==== Надсилання змін до ваших віддалених сховищ
 
-Коли ви довели свій проект до стану, коли хочете ним поділитись, вам треба надіслати (`push`) ваші зміни нагору (`upstream`).
+Коли ви довели свій проєкт до стану, що хочете ним поділитись, вам треба надіслати (`push`) ваші зміни нагору (`upstream`).
 Це робиться простою командою: `git push <назва сховища> <назва гілки>`.(((git commands, push)))
-Якщо ви бажаєте викласти свою гілку master до вашого серверу `origin` (клонування зазвичай налаштовує обидва імені для вас автоматично), ви можете виконати наступне для надсилання всіх зроблених комітів до сервера:
+Якщо ви бажаєте викласти свою гілку `master` до вашого серверу `origin` (клонування зазвичай налаштовує обидва імені для вас автоматично), ви можете виконати наступне для надсилання всіх зроблених комітів до сервера:
 
 [source,console]
 ----
@@ -167,8 +178,8 @@ $ git remote show origin
     master pushes to master (up to date)
 ----
 
-Вона виводить посилання для віддаленого сховища, а також інформацію про слідкування за гілками.
-Команда ґречно розповідає вам, що якщо ви на гілці master та виконаєте команду `git pull`, вона автоматично зіллє гілку master з віддаленою після того, як отримає всі дані з віддаленого сховища.
+Вона виводить посилання для віддаленого сховища, а також інформацію про стеження за гілками.
+Команда ґречно розповідає вам, що якщо ви на гілці `master` та виконаєте команду `git pull`, вона автоматично зіллє гілку `master` з віддаленою після того, як отримає всі дані з віддаленого сховища.
 Також видано список усіх віддалених посилань, які були забрані.
 
 Ви напевно зустрінете такий простий приклад.
@@ -198,10 +209,10 @@ $ git remote show origin
     master                         pushes to master                         (up to date)
 ----
 
-Ця команда показує, до яких гілок автоматично надсилаються ваші зміни, коли ви виконуєте `git push`, доки перебуваєте на певної гілці.
-Вона також показує, яких віддалених гілок з серверу у вас нема, які віддалені гілки, що у вас є, були видалені з серверу, і декілька локальних гілок, що можуть автоматично зливатися з віддаленими гілками, за якими стежать, коли ви виконуєте `git pull`.
+Ця команда показує, до яких гілок автоматично надсилаються ваші зміни, коли ви виконуєте `git push`, доки перебуваєте на певній гілці.
+Вона також показує, яких віддалених гілок з серверу у вас нема, які віддалені гілки, що у вас є, були вилучені з серверу, і декілька локальних гілок, що можуть автоматично зливатися з віддаленими гілками, за якими вони стежать, коли ви виконуєте `git pull`.
 
-==== Перейменування та видалення віддалених сховищ
+==== Перейменування та вилучення віддалених сховищ
 
 Ви можете виконати `git remote rename`, щоб перейменувати віддалене сховище.(((git commands, remote)))
 Наприклад, щоб перейменувати `pb` на `paul`, ви можете зробити це за допомогою `git remote rename`:
@@ -217,7 +228,7 @@ paul
 Варто зазначити, що це змінює і всі назви ваших віддалених гілок.
 Що раніше мало назву `pb/master`, тепер називається `paul/master`.
 
-Якщо ви з якоїсь причини бажаєте видалити віддалене сховище -- ви перемістили сервер або більше не використовуєте якесь дзеркало, або можливо хтось припинив співпрацю -- ви можете використати `git remote remove` або `git remote rm`:
+Якщо ви з якоїсь причини бажаєте вилучити віддалене сховище -- ви перемістили сервер або більше не використовуєте якесь дзеркало, або, можливо, хтось припинив співпрацю -- ви можете використати `git remote remove` або `git remote rm`:
 
 [source,console]
 ----
@@ -226,4 +237,4 @@ $ git remote
 origin
 ----
 
-Once you delete the reference to a remote this way, all remote-tracking branches and configuration settings associated with that remote are also deleted.
+Як тільки ви вилучаєте посилання на віддалене сховище в такий спосіб, усі віддалені гілки та налаштування, що пов'язані із цим віддаленим сховищем, також будуть вилучені.