3.5 Галуження в git - Віддалені гілки

Коли ви хочете поділитися гілкою з навколишнім світом, надішліть (push) її на віддалене посилання, до якого маєте право запису. Ваші локальні гілки не синхронізуються з віддаленими автоматично — потрібно явно надсилати гілки, якими хочете поділитися. Таким чином, можете користуватися приватними гілками для роботи, якою не збираєтеся ділитися, а надсилати зміни тільки в тематичні гілки, над якими співпрацюєте.

Щоб поділитися з іншими своєю гілкою з назвою serverfix, надсилайте її так само як це робили із першою гілкою. Виконайте git push <remote> <branch>:

Це трохи скорочено. Git автоматично замінює назву гілки serverfix з refs/heads/serverfix:refs/heads/serverfix, що означає Візьми мою локальну гілку serverfix та надішли її для оновлення віддаленої гілки serverfix.'' Ми детальніше розглянемо refs/heads/ в Git зсередини, але, взагалі, можете зараз це пропустити. Також ви можете виконати git push origin serverfix:serverfix, що зробить те саме, тобто скаже Бери мій serverfix та шли на віддалений serverfix.'' Користуйтеся таким підходом щоб надсилати локальні гілки, що називаються інакше ніж віддалені. Якщо ви не хочете мати віддалену назву serverfix, виконайте натомість git push origin serverfix:awesomebranch, щоб надіслати локальну serverfix на віддалену з назвою awesomebranch.

Наступного разу, коли співпрацівники будуть отримувати зміни з сервера, — отримають вказівник на поточний стан серверного serverfix у віддалену гілку-посилання origin/serverfix:

Варто зауважити, що, коли ви отримуєте зміни (за допомогою fetch), — насправді це нові віддалено-відслідковувані гілки, а не автоматичні локальні копії цих гілок, які ви можете редагувати. Іншими словами, в цьому випадку, ви не маєте нової гілки serverfix, а просто вказівку на origin/serverfix, яку не можете змінювати.

Щоб злити ці отримані зміни в вашу поточну робочу гілку виконайте git merge origin/serverfix. Якщо хочете мати свою власну гілку serverfix і працювати над нею, можете створити її, базуючись на віддалено-відслідковуваній гілці:

За допомогою цього отримаєте гілку, де ви можете працювати, та котра відображає стан origin/serverfix.

Перемикання на локальну гілку з віддалено-відслідковуваної автоматично створює так звану відслідковувану гілку tracking branch'' (а гілка, за якою вона стежить називається upstream branch''). Відслідковувані гілки — це локальні гілки, що мають безпосередній зв’язок з віддаленою гілкою. Якщо ви знаходитеся на відслідковуваній гілці і потягнете зміни, виконуючи git pull, Git відразу знатиме з якого сервера брати та з якої гілки зливати зміни.

Коли ви клонуєте репозиторій, Git автоматично створює гілку master, яка слідкує за origin/master Проте, ви можете налаштувати й інші відслідковувані гілки — такі, що слідкують за іншими віддаленими посиланнями, або за гілкою, відмінною від master. Як у випадку, що ви бачили в прикладі, виконуючи git checkout -b <гілка> <назва віддаленого сховища>/<гілка>. Це досить поширена дія, Git має опцію --track для скороченого запису:

Насправді, це настільки поширено, що навіть для цього скорочення є скорочення. Якщо назва гілки, яку ви намагаєтеся отримати (а) не існує і (б) має таку саму назву, як і гілка тільки з одного віддаленого сховища, то Git створить стежачу гілку:

Щоб дати локальній гілці назву, що відрізняється від серверної, виконайте попередню повну команду, вказуючи бажане ім’я гілки:

Тепер локальна гілка sf буде автоматично витягувати зміни з origin/serverfix.

Якщо ж у вас вже є локальна гілка і ви хочете прив’язати її до віддаленої, чи змінити віддалену (upstream) гілку, можете використовувати опції -u чи --set-upstream-to до команди git branch.

Опція -vv до git branch дозволяє дізнатися, які у вас налаштовані відслідковувані гілки. Результатом буде список локальних гілок та інформація про них, включаючи, які гілки відслідковуються та деталі про те, чи вони випереджають чи відстають від локальних (чи те й інше).

Тут ми бачимо, що гілка iss53 слідкує за origin/iss53 та випереджає її (`ahead'') на два, тобто ми маємо локально два коміти, які ще не надіслані на сервер. Також ми бачимо, що `master слідкує за origin/master та її стан є актуальним. Далі бачимо, що serverfix слідкує за гілкою server-fix-good з сервера teamone та випереджає його на три й відстає на один, тобто існує один коміт на сервері, який ми ще не злили та три коміти локально, які ми ще не надіслали. Насамкінець бачимо, що локальна гілка testing не слідкує за жодною віддаленою.

Варто зауважити, що ці числа відображають стан віддалених гілок на час останнього оновлення з кожного сервера. Сама по собі команда не сягає серверів, вона просто відображає те, що збережено про ці сервери локально. Якщо ж ви хочете отримати найостаннішу інформацію про випередження чи відставання гілок, оновіть спочатку всі віддалені посилання. Можете це зробити ось як:

Команда git fetch, під час виконання, отримує всі оновлення, яких ви ще не маєте, але, зовсім не змінює вашу робочу директорію. Вона просто отримує дані для того, щоб ви могли самотужки злити зміни. Існує команда git pull, яка, по своїй суті та в більшості випадків, є послідовним виконанням команд git fetch та git merge. Якщо у вас є відслідковувана гілка, як ми показували у попередній секції, — створена та самостійно налаштована, чи як результат clone чи checkout, команда git pull буде звертатися до відслідковуваних сервера та віддаленої гілки, отримувати оновлення і тоді робити спробу зливання.

Переважно простіше користуватися fetch та merge явно, оскільки магічний git pull часом може збивати з пантелику.

Уявіть, що ви закінчили з віддаленою гілкою — тобто всі співпрацівники завершили свій вклад у нову функціональність та гілку було злито з віддаленою master (чи яка там у вас стабільна лінія коду). Для видалення віддаленої гілки користуйтеся опцією --delete до git push. Щоб видалити вашу serverfix виконайте таке:

Все, що відбулося, це видалення вказівника на сервері. Git сервер триматиме самі дані ще деякий час, до наступного збирання сміття (garbage collection), тому, якщо щось було видалено випадково, часто це досить легко відновити.