GitHub як система приймання та контролю змін

Агент повідомив: «Зміни готові, усі перевірки зелені». Але що саме він змінив? Яку версію перевірив GitHub? Хто переглянув різницю? Чи справді захищена основна гілка? І чи встановлено версію для користувачів? На GitHub ці питання зібрані поруч, але відповідь на одне не є відповіддю на решту.

Сторінка запиту на включення змін (Pull Request, PR) показує різницю у файлах, відгуки й автоматичні перевірки поруч. Щоб рекомендувати злиття, рецензент установлює, яку версію перевірили й що означає кожен статус.

Навчальний результат

Після цієї глави ви зможете перевірити ціль PR, diff, пов’язану ревізію, обговорення, reviews і checks. Ви розрізнятимете коментар, схвалення, результат перевірки, злиття, випуск версії та розгортання, а за наявними доказами зможете обґрунтувати одне з трьох рішень: зміну можна прийняти, її треба виправити або доказів поки недостатньо.

Передумови. Глави 2–4 пояснюють структуру репозиторію, роботу термінала та історію Git. Тут ми розглядаємо спільний процес у GitHub; детальна побудова автоматизованих процесів і перевірок належить главам 56–57, а методика читання коду — главі 50. Встановлювати інструменти чи виконувати вправи не потрібно.

Одне місце, кілька різних сутностей

У GitHub репозиторій зберігає файли, гілки та історію. Issue описує запит, дефект чи обговорення; Discussions призначені для окремих розмов громади або команди. PR пропонує зміну вихідної гілки для цільової та збирає поруч diff, опис наміру, посилання на роботу, коментарі, відгуки рецензентів і перевірки.

Загальну різницю між Git tag, release та deployment пояснює глава 4. Git tag — це іменоване посилання на об'єкт Git, часто на commit; він сам не публікує й не встановлює програму. Тут важлива GitHub-специфічна деталь: GitHub Release публікує версію на основі tag і може містити опис та файли (About Releases). Фактичне розгортання перевіряють за окремим записом deployment (deployment environments).

Ці об’єкти не доводять одне одного: закритий Issue не засвідчує, що код написано, а злитий PR — що функцію розгорнули. Назва production у Environments не показує, чи ввімкнено захист і чи успішним було останнє розгортання. Перевіряйте запис про дію та результат у потрібному контексті.

PR показує вихідну гілку, звідки надходять commits, і цільову гілку, куди їх пропонують включити. Наприклад, feature/new-invoice може бути джерелом, а main — ціллю. Неправильно вибрана ціль спотворює diff або спрямовує зміни не в той релізний потік (GitHub Docs: reviewing proposed changes).

У картці PR корисно простежити послідовність: спершу перевірити цільову гілку, потім зрозуміти намір з опису, зіставити його з diff і пов'язаною задачею, а тоді оцінити review та checks. Якщо змінено базову гілку, може змінитися сам diff; тому перед оцінкою зафіксуйте, який саме варіант коду переглядаєте.

Позначка Draft означає, що автор ще не просить повного review; Ready for review змінює очікування команди, але не підтверджує повноту чи безпеку. В описі варто назвати причину й межі зміни, пов’язану задачу, докази та ризики. PR-шаблон допомагає зібрати цю інформацію, але не засвідчує її правдивість (GitHub Docs: managing and standardizing pull requests).

Коментар, review та approval — різний зміст

Елемент	Що він означає
Коментар	Розмова про рядок diff або PR загалом; це ще не формальне рішення про готовність
Запит на review	Запрошення рецензентові; запрошений ще не подав результат
Поданий review (рецензування)	Один із результатів Comment, Approve або Request changes

Comment може містити блокувальне зауваження, а Approve — необов’язкову пораду. Схвалення (approval) — думка рецензента про побачений diff, не гарантія якості продукту й не заміна перевірки. Після нових commits захист гілки може позначити approval застарілим; навіть якщо він лишився на екрані, суттєву нову різницю треба переглянути (GitHub Docs: requesting a pull request review, protected branches).

Отже, рішення про включення не випливає з одного поля. Рецензент читає зміст коментарів, перевіряє, чи вони стосуються актуального diff, і співвідносить це з формальними воротами репозиторію. Якщо зауваження вказує на невідомий ризик, його треба з'ясувати або прийняти свідомо, навіть коли статус Approve формально дозволяє merge.

Чи блокує Request changes merge, залежить від активних правил і прав рецензента. Без обов’язкового review це може бути лише інформаційним станом; налаштоване правило може вимагати виправлення або належного зняття запиту уповноваженою людиною. Схвальний коментар не замінює approval від CODEOWNER, якщо цього вимагає правило. Сам статус є сигналом; ворота визначає конфігурація репозиторію (GitHub Docs: protected branches).

Коментар до рядка diff може поставити питання або запропонувати точну зміну саме в цьому місці; загальний коментар обговорює PR цілком. Автор може відповісти, додати commit і позначити розмову вирішеною, але сама позначка про вирішення не доводить, що виправлення достатнє: перевірте новий diff і відповідь на первісний ризик.

Почніть review з проблеми й того, чого зміна не має змінити. Переглядайте файли послідовно, прив’язуйте зауваження до відповідних рядків, а після перевірки подайте загальний результат review. Кнопка Viewed допомагає відстежувати прочитані файли, але лише позначає їх; вона не схвалює їхній зміст. Загальний результат review подавайте після перегляду фактичної різниці, а не лише після читання опису (GitHub Docs: reviewing proposed changes).

Checks та GitHub Actions: що саме було виконано

Continuous Integration (CI — безперервна інтеграція) означає часте включення змін у спільну гілку з автоматичним збиранням і перевіркою. Continuous Delivery (безперервне постачання) підтримує зміни в стані, придатному до випуску на вимогу; запуск може потребувати рішення людини. Continuous Deployment (безперервне розгортання) автоматично розгортає кожну зміну, що пройшла потрібні перевірки. Обидва останні поняття інколи скорочують до CD, тому тут важливо розрізняти їх за дією. DevOps Research and Assessment (DORA — дослідження та оцінювання практик DevOps) описує Continuous Delivery як можливість процесу (DORA: Continuous Delivery; Google Cloud: DevOps capabilities). Це не назви продукту GitHub Actions.

У GitHub Actions workflow визначає події запуску й jobs — групи кроків на runner-середовищі. Він може запускатися, коли PR відкрито, змінено, знову відкрито або вручну запущено. Один PR може активувати кілька workflow, у кожному з яких є кілька jobs; check може відповідати окремому job або зовнішньому сервісу. Журнал показує вивід кроків; artifact — файл, створений і збережений під час запуску, який можна завантажити для подальшого використання (GitHub Docs: workflows, workflow artifacts, події workflow).

Назва check не пояснює, що саме перевірено: відкрийте опис запуску та журнал і звірте їх зі зміненими файлами й ризиком. Наприклад, unit tests саме по собі не доводить, що перевіряли інтеграційний, доступовий чи користувацький сценарій. Якщо у PR три jobs, а один із них умовно запускається лише для документації, зелений підсумок не означає, що перевірено всі три напрямки зміни.

Ревізія	Що саме перевіряється
Head commit	Останній commit вихідної гілки, з яким рецензент зіставляє diff
Подія pull_request	Зазвичай тестовий merge commit у refs/pull/<номер>/merge, що поєднує актуальні head і base
Інша подія	Workflow може запуститися на head commit або іншій ревізії
Required check	Правило може вимагати результат для head commit або тестового merge commit; перевірте фактичне джерело SHA

SHA (Secure Hash Algorithm — алгоритм криптографічного хешування) у GitHub може бути показаний скорочено. Після зміни head або base перевірте статуси для поточної пари гілок: попередній успішний запуск може стосуватися іншого коду. Перевірка й approval — різні свідчення: перша є звітом workflow чи сервісу, друге — рішенням рецензента (GitHub Docs: events that trigger workflows, troubleshooting required status checks, protected branches).

На практиці з'ясуйте: який commit перевірено; чи всі обов’язкові jobs завершилися; хто опублікував статус; які логи підтверджують заяву; чи немає червоного, очікуваного або пропущеного job; чи стосувався він зміненого ризику. GitHub може зараховувати певні нейтральні або пропущені стани як успішні для правила; наприклад, пропущена перевірка документації нічого не доводить про авторизацію. У різних правилах required check може стосуватися head commit або тестового merge commit, тож назви статусу замало — перевірте SHA-джерело.

Успішний CI не підтверджує вимоги замовника, вміст секретів, стан production-даних або вигляд сайту користувачеві, якщо ці речі не перевіряв конкретний job. Відсутність check не означає автоматичний провал, але коли його вимагає правило або ризик потребує доказу, даних для рішення ще бракує.

Малі зміни легше переглядати й обговорювати; стаття IT Revolution, адаптована з Accelerate, пов’язує їх із практиками доставки. Це не гарантія якості: малий PR теж може порушити безпеку, а повну книгу Accelerate тут не заявляємо як прочитану (IT Revolution, “24 Key Capabilities”).

Захист гілки та відповідальність за код

Branch protection і rulesets. Гілка може вимагати PR, певну кількість approvals, approval від CODEOWNERS, named checks, вирішення розмов, актуальну базу, підписані commits або успішний deployment. Rulesets застосовують правила до вибраних гілок чи тегів. Доступність залежить від тарифу й типу репозиторію, а фактичний захист — від налаштувань: перевірте цільову гілку, а не лише список можливостей GitHub (GitHub Docs: protected branches, available rules for rulesets).

Перевірте також bypass actors — осіб або застосунки, для яких діє виняток. За замовчуванням обмеження branch protection не діють для адміністраторів і користувачів із власною роллю, що має дозвіл bypass branch protections; правило може охопити й їх. У ruleset список акторів обходу налаштовують явно (GitHub Docs: protected branches, rulesets).

Файл CODEOWNERS перелічує відповідальних за шляхи файлів. Він може автоматично надіслати власникові запит на review, тобто запросити перегляд; доки людина не подала результат, це не approval і не доказ виконаного review. Щоб approval від власника було обов'язковим, потрібне відповідне правило захищеної гілки або ruleset. Перевірте сам файл у цільовій гілці та діюче правило, а не припускайте з назви власника чи повідомлення «review requested» (GitHub Docs: about code owners, protected branches).

Дозволи й секрети. Перевірте роль агента або GitHub App окремо від прав GITHUB_TOKEN: цей токен визначає доступ workflow, а не самої App чи агента. Дотримуйтеся мінімальних прав; workflow, якому треба лише читати код, не потрібен запис у репозиторій (GitHub Docs: GITHUB_TOKEN).

Передавайте секрети лише потрібним крокам. Не вставляйте їх у логи, PR-коментарі, описи чи знімки екрана; маскування логів не гарантує безпечного поводження. Для PR із fork (окремої копії репозиторію, часто в іншому просторі власника) подія pull_request має обмежені права й не отримує звичайні secrets. Інші події можуть мати іншу модель доступу, тож не запускайте привілейований workflow на недовіреному коді без перевірки ризику (GitHub Docs: secrets, workflows in forked repositories, compromised runners).

Злиття PR і розгортання в GitHub

Після потрібних review і checks PR можна злити в цільову гілку. Для job із GitHub environment можна вимагати approval перед запуском, обмежити дозволені гілки й доступ до секретів. Станом на 10 жовтня 2026 року GitHub Docs обмежують required reviewers публічними репозиторіями на Free, Pro і Team; для приватного репозиторію перевіряйте чинні умови тарифу. Назва environment не означає, що ці правила ввімкнено, а запис deployment не доводить, що функція працює для користувача (GitHub Docs: deployment environments).

GitHub пропонує три способи merge PR, і вони по-різному формують історію:

Спосіб	Результат у цільовій історії
Merge commit	Зберігає commits гілки й додає окремий commit злиття
Squash	Створює один новий commit; вихідні commits не стають окремими предками цільової гілки
Rebase-and-merge	Повторно застосовує commits поверх актуальної цільової гілки з новими SHA, без merge commit

Вибір має відповідати домовленості репозиторію; загальну модель merge, release й deployment пояснює глава 4 (GitHub Docs: pull request merges).

Не змішуйте ці кроки у звіті: merge включає зміни в цільову гілку; release позначає версію для поширення; deployment встановлює її у вибране середовище. Залежно від процесу після merge може автоматично стартувати release або deployment, а може знадобитися окрема дія людини. Кожне твердження перевіряйте відповідним записом, журналом або перевіркою у потрібному середовищі.

Повністю розібрані приклади

Приклад 1. Малий PR з двома перевірками

Ситуація. Команда додає до рахунку підсумкову дату оплати. У прикладі PR має ціль main, посилається на задачу BILL-42 і змінює три файли: шаблон рахунку, функцію формування тексту та тест цього тексту. Усі назви та події вигадані для навчання.

Що написано в описі. Автор пояснює часовий пояс дати, перевірені випадки з датою та без неї, і зазначає, що формат інтерфейсу не змінюється. Опис також пов’язує PR із задачею та називає те, що не перевірено.

Що бачить рецензент. Він порівнює три файли з наміром: шаблон показує дату лише за її наявності, функція використовує погоджений часовий пояс, а тест покриває випадки з датою та без неї. Успішний format-and-unit-tests не доводить, що формат дати відповідає правилу; docs-links його взагалі не перевіряє. Рецензент знаходить неперевірений граничний випадок: дату, що припадає на межу доби після перетворення часового поясу. Автор уточнює очікуваний формат у вимозі, додає тест і змінює функцію, якщо результат тесту показує невідповідність. Відтак нова версія head отримує новий SHA, і команда звіряє результат checks саме з нею.

У змодельованому журналі format-and-unit-tests показує завершення потрібних тестів для commit 8ab31e2; docs-links теж успішний, але не перевіряє дату. Після нового commit перевірки запускаються повторно на новому SHA. Рецензент перечитує змінений рядок і відповідає в гілці первісного коментаря. Наведений SHA — частина вигаданого навчального сценарію, а не справжній запуск цього курсу.

У змодельованому продовженні доданий тест проходить, а рецензент перевіряє виправлення й подає approval для актуального diff. Це навчальний приклад, не звіт про справжній запуск чи approval. Якщо commit знову зміниться після цього review, слід перевірити, чи не потребує суттєва різниця нового огляду.

Результат. У змодельованому сценарії поточний head має два успішні checks і нове схвалення після повторного перегляду. Команда може рекомендувати merge, якщо ці докази відповідають обов’язковим правилам репозиторію; інакше PR чекає на решту умов. Це не доводить, що рахунковий сервіс уже випустили або розгорнули.

Чому такий порядок. Опис дає намір, diff показує реалізацію, review оцінює зміст, а check повідомляє про конкретне автоматизоване виконання. Після нових правок наступна перевірка має стосуватися оновленої ревізії; кожне твердження в PR має відповідне джерело доказу.

Інша можливість і межа. Для текстового файла команда може перевірити посилання й попередній перегляд замість тестового job. Назва all-green без відомого змісту мало що доводить. Жоден набір checks не підтвердить, що дата відповідає договору, якщо умови договору не перевіряють.

Приклад 2. Checks зелені, але доступ до звіту не перевірено

Ситуація. PR додає екран «Мої аналітичні звіти». Збірка та тести компонента успішні, але функція завантажує звіт за ідентифікатором організації.

Що ще має встановити рецензент. Він перевіряє, де сервер визначає поточного користувача, чи звіряє кожен запит із його організацією і як відхиляє чужий ідентифікатор. Тест рендерингу нічого з цього не доводить. Потрібен серверний тест: користувач А читає власний звіт, але не звіт організації Б.

Рішення. Merge передчасний, доки не підтверджено межу доступу. Автор додає серверну перевірку й позитивний та відмовний тести. У змодельованому продовженні користувач А читає свій звіт, а запит до звіту організації Б відхиляється.

Після нового commit команда не покладається на попередній статус: перевіряє актуальні head і base, SHA джерела check, журнал і змінений код. Успішний тест рендерингу може залишитися зеленим, хоча жоден тест не перевірив, кому належать дані; отже, наступний доказ має охопити серверну межу доступу, а не лише екран.

Результат. Тест підтверджує лише цю межу між двома організаціями, а не всі ролі й шляхи.

Інша можливість і межа. Доступ може контролювати спільний серверний шар або політика бази даних. Тоді перевірте цей контроль і тест, який його охоплює; не вимагайте дублювати захист у кожному екрані, якщо спільна межа діє й підтверджена конкретним доказом.

Приклад 3. Агент назвав задачу завершеною до deployment

Ситуація. Агент відкрив draft PR для сторінки тарифу, позначив задачу Jira як «готово» й навів зелений build check. Workflow зібрав сайт, але немає deployment для цієї ревізії. Згадка production у документації не підтверджує запуск.

Перевірка. Звірте цільову гілку й опис із diff; з’ясуйте, що зібрав workflow та до якого commit належить check. Без запису deployment команда повідомляє, що сайт ще не розгорнуто. Збірка не означає merge, release чи deployment.

Дія і результат. Коли PR готовий до формального review, агент позначає його Ready for review, змінює Jira на стан за командним workflow і зазначає невиконані кроки. Глава 6 докладніше розглядає статуси Jira та докази виконання. Після потрібного review і merge людина чи дозволений workflow запускає deployment; команда звіряє його запис і перевіряє сторінку тарифу. Лише тоді можна сказати, що її розгорнуто й перевірено у вибраному середовищі.

Якщо потрібний deployment не запускався, у звіті залиште його як незавершений крок і назвіть того, хто має дозволити або виконати його. Не переводьте Jira у Done лише через збірку: статус має відповідати командній домовленості про те, чи потрібні review, merge, розгортання й перевірка доступного користувачам результату.

Інша можливість і межа. Деякі команди автоматично розгортають кожну зміну після merge; інші вимагають ручного дозволу. Перевірте workflow і журнал запуску: слово «автоматично» чи зелений build не доводить, що потрібний deployment job стартував із правильною конфігурацією або змінив систему, доступну користувачам.

Короткий пакет доказів для рецензента

Перш ніж рекомендувати приймання, можна підсумувати PR так:

Питання	Який доказ шукати
Що змінюється й навіщо?	Опис PR, пов'язана задача, межі змін
Що саме змінив автор?	Diff head-гілки відносно цільової (base)
Який код переглянув рецензент?	Поточний head commit, diff і фактично поданий review
Яку ревізію перевірив workflow?	Повний SHA commit, на якому запущено check (head або тестовий merge commit), його статус для поточних head і base, журнал та артефакт за потреби
Хто переглянув зміну?	Поданий review і фактичне правило обов'язкового схвалення
Яких доказів бракує?	Непокриті ризики, залежності, доступи, невиконані кроки
Чи розгорнуто зміну?	Запис deployment для конкретного середовища та перевірка результату

Цей пакет відокремлює підтверджене від того, чого ще не доведено. Якщо опис каже, що кілька jobs пройшли, а на сторінці видно лише старі запускання або джерело check не відповідає поточним head і base, зафіксуйте різницю та повторіть потрібні перевірки. Рецензент має бачити не лише зелений підсумок, а й ревізію, результат і межі кожного доказу.

Реальний приклад із публічного PR

У публічному PR pallets/flask #6095 автор запропонував замінити використання приватного API pytest-fixture monkeypatch на публічні виклики. Рецензент порадив залишити fixture і обмежити її pytest.MonkeyPatch.context(); автор запитав, чи зміниться від цього поведінка очищення змін. PR злили до stable 30 липня 2026 року. Це приклад конкретного обговорення, не універсальна рекомендація; його CI-статуси й обговорення поза публічною історією тут не аналізували. Публічна історія показує предмет обговорення, відповідь автора, зміну коду й факт злиття, але не обов’язково всі розмови чи мотиви рішення поза GitHub. Тому цей випадок ілюструє форму review-обміну, а не доводить, що саме так треба діяти в кожній команді.

Коли рішення про merge має зачекати

Зачекайте з рекомендацією про merge, якщо:

• PR не відповідає задачі або суттєве зауваження рецензента лишилося без відповіді;
• обов’язковий review чи check очікується або стосується старої ревізії;
• гілка має конфлікт чи не відповідає правилу актуальності;
• є витік секрету, незрозуміла зміна прав або ризик неперевіреної міграції.

Назвіть, якого факту бракує і хто може його підтвердити. Якщо правила репозиторію невідомі, перевірте їх: позначка «можна merge» не замінює аналіз бізнесового чи безпекового ризику.

Джерела та подальше читання

• GitHub Docs, Requesting a pull request review та Reviewing proposed changes in a pull request, актуальні вебсторінки без зазначеної дати видання; прочитано 23 вересня 2026 року. Використано для різниці між запрошенням рецензента й поданим review, diff, коментарів, suggestions та трьох типів review. Інтерфейс може змінюватися.
• GitHub Docs, Managing and standardizing pull requests, актуальна вебсторінка; прочитано 23 вересня 2026 року. Використано для PR templates, CODEOWNERS, protected branches і rulesets; сама наявність опції не показує її ввімкнення.
• GitHub Docs, About protected branches та Available rules for rulesets, актуальні сторінки; прочитано 23 вересня 2026 року. Використано для правил approval, status checks, актуальності гілки, захисту й обходу; доступність залежить від плану й конкретної конфігурації.
• DevOps Research and Assessment (DORA — дослідження та оцінювання практик DevOps), Google Cloud: DevOps capabilities і Continuous Delivery, актуальні вебсторінки; прочитано 23 вересня 2026 року. Використано для визначення назви DORA та розрізнення здатності випускати версію на вимогу й автоматичного безперервного розгортання.
• GitHub Docs, Workflows та Workflow artifacts, актуальні вебсторінки; прочитано 23 вересня 2026 року. Використано для ролей workflow, job, runner та збережених артефактів.
• GitHub Docs, Events that trigger workflows та Troubleshooting required status checks, актуальні вебсторінки; прочитано 23 вересня 2026 року. Використано для різниці між head commit і тестовим merge commit для pull_request, а також прив’язки обов’язкової перевірки до правильної ревізії й вимоги актуальної базової гілки.
• GitHub Docs, About code owners, актуальна вебсторінка; прочитано 23 вересня 2026 року. Використано для різниці між запитом власника коду та обов'язковістю його approval, яку встановлюють правила.
• GitHub Docs, Use GITHUB_TOKEN for authentication in workflows, Secrets, Compromised runners та GitHub Actions runners, актуальні вебсторінки; прочитано 23 вересня 2026 року. Використано для різниці між дозволами workflow-токена й доступом установленої App, а також для секретів, меж fork-подій і середовищ запуску. Маскування секрету в логах не є гарантією безпечного поводження.
• GitHub Docs, Deployment environments, актуальна вебсторінка; прочитано 23 вересня та перевірено 10 жовтня 2026 року. Використано для environment, обмежень гілок, required reviewers, планів/видимості репозиторію та секретів середовища; назва environment не доводить успіх deployment.
• Git, git-tag, актуальна документація; прочитано 23 вересня 2026 року. Використано для пояснення tag як іменованого посилання на Git-об’єкт.
• GitHub Docs, About releases, актуальна вебсторінка; прочитано 23 вересня 2026 року. Використано для зв’язку GitHub Release з tag і додатковими нотатками чи файлами.
• GitHub Docs, About pull request merges, актуальна вебсторінка; прочитано 23 вересня 2026 року. Використано для наслідків merge commit, squash та rebase-and-merge.
• IT (Information Technology — інформаційні технології) Revolution, 24 Key Capabilities to Drive Improvement in Software Delivery, 1 вересня 2020 року; прочитано 23 вересня 2026 року. Стаття зазначає, що адаптує уривок із Accelerate. Використано для вузького зв'язку малих змін і короткого зворотного зв'язку з процесом розробки; це не гарантія коректності конкретного PR або автоматизованого check.
• Pallets Projects, Flask pull request #6095: Replace the use of private monkeypatch fixture API, відкритий публічний PR автора mgorny, 14–30 липня 2026 року; переглянуто 23 вересня 2026 року. Використано тільки як приклад конкретної пропозиції, коментаря рецензента, відповіді автора та merge. Відомостей про CI результат у цьому розборі не перевіряли.