Схвалити / Отримати схвалення: що це, схвалення та code review у Git

Що таке схвалення pull request

Схвалення — це позитивний відгук на pull request, що означає, що рев’ювер перевірив код, не знайшов критичних проблем і вважає зміни готовими до merge. У інтерфейсі GitHub це зелена кнопка «Approve» на сторінці PR. Після схвалення автор (або будь-який учасник з правами на запис) може виконати merge.

Процес схвалення є частиною Branch Protection Rules. Власники репозиторії налаштовують обов’язкові вимоги: мінімальна кількість схвалень (наприклад, 1 або 2), хто може схвалювати (власники коду, члени команди) та чи потрібен PR повторно схвалити після змін (Dismiss stale reviews). Без налаштування правил схвалення є необов’язковим, але в професійних командах воно обов’язкове.

GitLab використовує аналогічний механізм під назвою Approval Rules. У GitLab можна налаштувати, скільки схвалень потрібно від різних груп (наприклад, 2 від розробників бекенду та 1 від DevOps). Після отримання всіх обов’язкових схвалень PR автоматично розблоковується для merge за умови зеленого CI/CD пайплайну.

Типи рев’ю: Approve, Request Changes, Comment

GitHub та GitLab мають три типи рев’ю, які рев’ювер може залишити на pull request. Кожен тип має різний статус та наслідки для процесу merge. Approve — зелений, Request Changes — червоний, Comment — нейтрально-сірий. Вибір залежить від якості коду та готовності змін до прийняття.

Approve — рев’ювер підтверджує: код написано правильно, відповідає стандартам, не містить очевидних помилок і може бути злитий. Approve не означає, що код ідеальний — лише що він достатньо хороший для виробництва. Якщо є дрібні зауваження (стиль, найменування), їх можна залишити як коментарі без блокування PR.

Request Changes — рев’ювер знаходить проблеми, які необхідно виправити перед merge: логічні помилки, уязвивості, порушення архітектури, відсутність тестів. Після Request Changes PR блокується, і для розблокування потрібна повторна схвала того ж рев’ювера (якщо опцію Dismiss stale reviews увімкнено при нових комітах).

• Approve — код готовий до merge, можна зливати після проходження CI.
• Request Changes — обов’язкові виправлення, PR заблоковано до повторного рев’ю.
• Comment — загальне зауваження або пропозиція без блокування PR.

Налаштування правил схвалення в репозиторії

Branch Protection Rules — це механізм GitHub для контролю якості merge. Налаштовується в Settings → Branches для кожної захищеної гілки (main, develop, release/*). Основні параметри: кількість обов’язкових схвалень, власники коду (CODEOWNERS), обов’язкова перевірка CI/CD та заборона push без PR.

Параметр Dismiss stale pull request approvals автоматично скасовує схвалення, якщо до PR додано новий коміт. Це гарантує, що рев’ювери схвалюють саме ту версію коду, яка буде злита. Без цього налаштування автор міг би додати новий код після схвалення, і він потрапив би в main без повторної перевірки.

CODEOWNERS — файл в корені репозиторії, який призначає відповідальних за різні каталоги. Якщо PR зачіпає файли, що належать власнику коду, його схвалення стає обов’язковим. CODEOWNERS дозволяє розподілити зони відповідальності: iOS-розробники відповідають за Swift-файли, DevOps — за конфігурації Docker, тестувальники — за тестові сценарії.

# Приклад файлу CODEOWNERS в корені репозиторії

# iOS-розробники володіють Swift-кодом
*.swift @team/ios-developers

# DevOps володіє конфігурацією CI/CD
.github/workflows/* @devops-team

# QA-інженери перевіряють тести
**/tests/* @qa-engineers

# Типові власники для всього іншого
* @tech-leads

Code review перед схваленням: що перевіряти

Code review перед схваленням — це систематична перевірка коду, а не поверховий погляд на diff. Якісний code review включає перевірку архітектури, логіки, стилю, тестів та безпеки. Без цієї перевірки схвалення стає формальністю, а не інструментом контролю якості.

Що перевіряється в першу чергу: логіка змін — чи вирішує код поставлене завдання, чи є побічні ефекти, чи коректна обробка граничних випадків. Тести — чи покривають нові тести всі сценарії, чи проходять існуючі тести після змін. Безпека — чи немає SQL-ін’єкцій, XSS, витоків чутливих даних.

Що не має бути предметом рев’ю: стиль форматування (для цього є лінтери та форматувальники), архітектурні рішення, прийняті заздалегідь (вони обговорюються до написання коду). Якщо рев’ю перевищує 400 рядків або займає понад годину — це ознака, що завдання занадто велике і потребує декомпозиції. Найкращі практики рев’ю — порції по 200–400 рядків протягом 24 годин після створення PR.

• Логіка — правильність рішення, обробка помилок, граничні випадки.
• Тести — покриття нових сценаріїв, проходження існуючих тестів, відсутність flaky-тестів.
• Безпека — відсутність ін’єкцій, екранування виведення, контроль доступу до даних.
• Продуктивність — ефективність алгоритмів, надлишні запити, витоки пам’яті.
• Документація — чи оновлена документація, чи зрозумілі коментарі у складних місцях.

Робочий процес зі схваленням у команді

Типовий робочий процес зі схваленням у команді з 5–10 розробників виглядає так: розробник створює PR, призначає рев’юверів (зазвичай 1–2 осиби з команди або власників коду), CI/CD запускає автоматичні перевірки. Після отримання всіх обов’язкових схвалень та зеленого CI автор виконує merge. Час від створення PR до merge в середньому становить від 2 годин до 2 днів залежно від складності.

GitHub Actions дозволяють автоматизувати merge після схвалення. Якщо налаштовані правила гілок, GitHub автоматично блокує merge до виконання всіх умов. Деякі команди використовують bors-ng або Mergify — ботів, які автоматично зливають PR після отримання всіх схвалень та проходження CI. Це прискорює процес та усунає людський фактор при merge.

Сучасний підхід — trunk-based development з короткоживучими гілками. У цьому робочому процесі схвалення має бути отримане протягом кількох годин, інакше завдання вважається застарілим і потребує повторної синхронізації з main. Команди з високою культурою рев’ю прагнуть до часу схвалення не більше ніж 4 робочих годин.

Помилки при схваленні та як їх уникнути

Найпоширеніша помилка — формальне схвалення без реальної перевірки коду. Коли PR великий або дедлайн близько, рев’ювер може натиснути Approve, не вдаючись у зміни. Це знічує весь процес code review. Рішення: встановити ліміт на розмір PR (не більше 400 рядків) та використовувати інструменти аналізу коду (SonarQube, CodeClimate) для автоматичної перевірки.

Друга помилка — надмірно суворе схвалення. Очікування ідеального коду блокує розробку. Рев’ювери іноді вимагають виправити стилістичні зауваження, які не впливають на якість. Рішення: чітко розділяти обов’язкові зауваження (блокувальні) та опційні пропозиції (коментарі). GitHub дозволяє явно вказувати, чи є коментар блокувальним.

Третя помилка — схвалення без перевірки CI/CD. Навіть якщо код виглядає коректно, він може не компілюватися або падати на тестах. Налаштовані Branch Protection автоматично блокують merge при червоному CI, але деякі команди вимикають цей захист заради швидкості. Рішення: завжди перевіряти статус CI перед схваленням і ніколи не схвалювати PR з червоним пайплайном.

• Формальне схвалення — відсутність реальної перевірки коду. Рішення: ліміт 400 рядків на PR.
• Надмірна суворість — блокування через стилістичні зауваження. Рішення: поділ на blocking та optional.
• Ігнорування CI — схвалення при червоному пайплайні. Рішення: завжди перевіряти статус тестів.
• Призначення автора — схвалення від автора PR. Рішення: налаштування Branch Protection проти автора.