6.3 GitHub - Супроводжування проєкту

Хтось приходить, змінює ваш код та відправляє вам Запит на Пул. Вам має надійти лист з повідомленням про новий Запит на Пул, що має виглядати як Лист з повідомленням про новий Запит на Пул..

Варто звернути увагу на декілька речей у цьому листі. Він включає невелику статистику змін (diffstat) - список файлів, що були змінені в Запиті на Пул, та наскільки вони змінились. Також у ньому є посилання на сторінку GitHub Запиту на Пул. І ще декілька URL, які ви можете використовувати з командного рядка.

Якщо ви помітили рядок з текстом git pull <url> patch-1, то це простий метод злити зміни з віддаленої гілки без необхідності додавати віддалене сховище. Ми швидко це розглянули в Отримання віддалених гілок. Якщо ви бажаєте, то можете створити та перейти до тематичної гілки, а потім виконати цю команду, щоб злити зміни Запиту на Пул.

Інші цікаві посилання це .diff та .patch, які, як ви можете здогадатись, містять Запит на Пул у вигляді об’єднаних змін (unified diff) та патчу. Ви можете злити Запит на Пул навіть так:

Як ми вже бачили в Потік роботи GitHub, ви тепер можете спілкуватись з людиною, яка відкрила Запит на Пул. Ви можете коментувати окремі рядки коду, коментувати цілі коміти, чи коментувати весь Запит на Пул, за допомогою GitHub різновиду Markdown.

Щоразу хтось інший коментує Запит на Пул, ви знову будете отримувати лист з повідомленням, отже ви будете знати що відбувається. Кожен з листів буде містити посилання на Запит на Пул саме туди, де щось відбулося, а також ви можете відповісти прямо на лист, і коментар у Запиті на Пул буде створено автоматично.

Щойно код стає вам до вподоби та ви бажаєте його злити, ви можете або зробити пул коду та злити його локально, або використати git pull <url> <branch>, як ми бачили раніше, або можете додати форк як віддалене сховище, отримати з нього всі коміти, а потім вже злити зміни.

Якщо злиття тривіальне, ви також можете просто натиснути на кнопку Merge'' (злити) на сайті GitHub. Це зробить злиття не-швидко-вперед'' (non-fast-forward): створить коміт злиття навіть якщо злиття швидко-вперед можливе. Це означає що за будь-яких обставин, щоразу ви натискаєте на кнопку merge, буде створено коміт злиття. Як ви можете побачити на Кнопка злиття та інструкції щодо злиття Запиту на Пул вручну., GitHub надасть вам усю цю інформацію, якщо ви натиснете на посилання вказівки (hint).

Якщо ви вирішите не зливати Запит, ви також можете просто закрити Запит на Злиття, про що автора запиту буде повідомлено.

Якщо вам доводиться працювати з багатьма Запитами на Злиття, та ви не бажаєте додавати купу віддалених сховищ чи робити по одному пулу на кожен, є один дотепний засіб, який GitHub вам дозволяє використати. Це дещо складний засіб та ми дещо докладніше розглянемо подробиці того, що відбувається в Специфікація посилань (refspec), проте він може бути доволі корисним.

Насправді GitHub сприймає гілки Запитів на Злиття для сховища як щось на кшталт псевдо-гілок на сервері. Без додаткових дій ви не отримуєте їх при клонуванні, проте вони є в прихованому вигляді та ви можете доволі легко отримати до них доступ.

Щоб це продемонструвати, ми збираємося використати команду низького рівня (часто їх називають команди `plumbing'', про що ми прочитаємо більше в Кухонні та парадні команди) під назвою `ls-remote. Ця команда не потрібна при повсякденному використанні Git, проте вона корисна щоб показати нам, які посилання (references) присутні на сервері.

Якщо ми виконаємо цю команду на сховищі ``blink'', яке ми вже раніше використовували, ми отримаємо список усіх гілок та теґів, а також інших посилань у сховищі.

Авжеж, якщо ви у своєму сховищі виконаєте git ls-remote origin (замість origin може бути будь-яке віддалене сховище), ви отримаєте щось схоже на це.

Якщо сховище розміщене на GitHub та у вас є хоч один відкритий Запит на Пул, ви побачите посилання з префіксом refs/pull/. Це звичайні гілки, проте оскільки вони не мають префікса refs/heads/, ви не отримуєте їх при клонуванні або отриманні змін з серверу — процес отримання зазвичай повністю їх ігнорує.

Для кожного Запиту на Пул є по два посилання: те, що закінчується на /head вказує саме на останній коміт до гілки Запиту на Пул. Отже, якщо хтось відкриє Запит на Пул до вашого сховища, та їхня гілка називається bug-fix та вона вказує на коміт a5a775, то у вашому сховищі в нас не буде гілки bug-fix (адже це не у вашому форку), проте у нас буде pull/<pr#>/head, яке вказує на a5a775. Це означає, що ми легко можемо злити кожну гілку Запиту на Пул одразу, і не маємо для цього додавати купу віддалених сховищ.

Тепер ви можете отримати посилання явно наступним чином:

Ця команда каже Git: `Приєднайся до віддаленого сховища `origin, завантаж звідти посилання під назвою refs/pull/958/head.'' Git радісно це виконує, та завантажує все, що вам необхідно, щоб відновити це посилання, та записує вказівник до потрібного вам коміту в .git/FETCH_HEAD. Далі ви можете виконати git merge FETCH_HEAD, щоб злити зміни до гілки, в якій ви бажаєте перевірити зміни, проте повідомлення коміту зливання буде виглядати дещо дивно. Також, якщо ви переглядаєте багато запитів на пул, це стає марудним.

Існує також метод отримати всі запити на пул, та оновлювати їх кожен раз, коли ви з’єднуєтесь з віддаленим сховищем. Відкрийте .git/config у вашому улюбленому редакторі, та знайдіть там віддалене сховище origin. Воно має виглядати приблизно так:

Рядок, що починається з fetch = є `специфікацією посилань'' (`refspec). Це спосіб відображення імен у віддаленому сховищі в імена у вашій локальній директорії .git. Саме цей рядок з прикладу каже Git: "усе, що на віддаленому сховищі знаходиться під refs/head має опинитись у моєму локальному сховищі під `refs/remotes/origin`". Ви можете відредагувати цю секцію щоб додати іншу специфікацію посилань:

Цей останній рядок каже Git: `Усі посилання, що мають вигляд `refs/pull/123/head, мають бути збережені локально як refs/remotes/origin/pr/123.'' Тепер, якщо ви збережете файл та виконаєте git fetch:

Тепер усі віддалені запити на пул представлені локально посиланнями так само, як і інші віддалені гілки. У них не можна вносити зміни, та вони оновлюються при отриманні змін. Це робить локальну перевірку коду із запиту на пул супер легкою:

Найуважніші з вас помітили head наприкінці імені віддаленої частини специфікації посилання. У сховищі GitHub також є посилання refs/pull/#/merge, що вказують на коміт, який ви би отримали при натисканні на кнопку ``merge'' сайту. Це дозволяє вам протестувати зливання до власно натискання на кнопку.

Ви можете відкривати Запити на Пул не тільки до головної (master) гілки, ви насправді можете відкривати Запит на Пул до будь-якої гілки в мережі. Ви дійсно можете навіть відкрити його навіть до іншого Запиту на Пул.

Якщо ви побачили Запит на Пул, що рухається у вірному напрямку, та у вас є ідеє зміни, що залежить від цього запиту, або ви невпевнені, що думка гарна, або у вас просто немає прав на запис до гілки запиту, ви можете відкрити Запит на Пул прямо до неї.

Коли ви відкриваєте Запит на Пул, нагорі сторінки є поле, що задає гілку, до якої ви створюєте запит на пул, та поле, що задає гілку, з якої ви просите взяти зміни. Якщо ви натиснете на кнопку ``Edit'' (редагувати) праворуч від поля, ви зможете вибрати не тільки гілки, а й форк.

Як бачите, доволі просто запросити зливання вашої нової гілки до іншого Запиту на Пул або до іншого форку проєкту.

Коли ми кажемо повідомлення'' (notification) тут щодо GitHub, ми маємо на увазі окремий метод, яким GitHub намагається вам повідомити про якісь події. У вас є декілька різних методів їх налаштувати. Якщо ви перейдете до вкладки Notification center'' (центр повідомлень) зі сторінки налаштувань, ви побачите деякі доступні вам опції.

У вас є дві можливості отримувати повідомлення: через Електронну пошту'' або через Веб'' та ви можете вибрати один з них, жодного, або обидва для Запитів/Завдань та для активності в сховищах, за якими ви слідкуєте.

======= Веб повідомлення

Веб повідомлення існують тільки на GitHub і ви можете їх перевіряти виключно на GitHub. Якщо ця опція ввімкнута у ваших налаштуваннях та вам надійшло повідомлення, ви побачите маленьку синю точку над іконкою повідомлень нагорі вашого екрану, як видно на Центр повідомлень.

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

Усі ці інструменти дуже корисні для роботи з великою кількістю повідомлень. Багато досвідчених користувачів GitHub просто вимикають усі поштові повідомлення та працюють з ними виключно через цю сторінку.

Якщо ви використовуєте не гілку master'' як головну, тобто гілку, до якої ви бажаєте щоб люди відкривали Запити на Пул, ви можете це змінити на сторінці налаштуваньсвого сховища на вкладці Options'' (опції).

Просто змініть типову гілку в випадному віконці та без окремої вказівки всі головні операції будуть відбуватися над нею, зокрема яку гілку буде отримувати сховище при клонуванні.

Якщо ви бажаєте передати проєкт іншому користувачу або організації на GitHub, для цього є опція Transfer ownership'' (передача власності) наприкінці тої самої вкладки Options'' на сторінці налаштувань вашого сховища.

Це корисно якщо ви покидаєте проєкт та хтось бажає його продовжити, або якщо ваш проєкт стає більшим і ви бажаєте перемістити його до організації.

Це не тільки переміщує сховище разом з усіма глядачами (watcher) та зірками до іншого місця, а ще й налаштує перенаправлення з вашого URL до нового місця. Також будуть перенаправлені клонування та отримання змін з Git — не тільки веб запити.