Пошук уроків, статей та іншого контенту
Як команди насправді зливають код через код-рев'ю, а не прямими комітами в main.
Пряме комітування в main обходить будь-яку можливість перегляду коду перед тим, як він потрапить у стабільну гілку, — жодного шансу зловити помилку, обговорити підхід чи попросити роз'яснення до того, як зміна стане частиною основної історії. Pull Request (PR, на GitLab — Merge Request) — стандартний робочий процес, що вставляє крок код-рев'ю між «код готовий» і «код у main».
git switch -c feature/add-search # 1. Нова гілка від main
# ...робота, коміти...
git push -u origin feature/add-search # 2. Відправити гілку на remoteДалі — через веб-інтерфейс GitHub/GitLab:
Відкрити Pull Request із feature-гілки в main, з описом того, що й навіщо змінено.
Автоматизовані перевірки (CI, стаття «CI/CD простими словами») запускаються на PR — типи, лінтер, тести.
Колеги рев'юють зміни, залишають коментарі, просять правки чи схвалюють.
Після схвалення й проходження перевірок — злиття PR у main (fast-forward, merge commit чи squash, залежно від налаштувань команди).
Окрім звичайного merge (усі коміти гілки зберігаються в історії) багато команд налаштовують squash merge — усі коміти PR об'єднуються в один єдиний коміт у main. Це тримає історію main чистою (один коміт на одну завершену задачу), ціною втрати дрібнішої історії окремих комітів усередині PR — прийнятний компроміс, коли проміжні коміти гілки самі по собі не несуть цінності (наприклад, «wip», «fix typo»).
Багато сервісів дозволяють відкрити «чернетковий» (draft) PR ще до завершення роботи — сигналізує команді «робота в процесі, ще не готова до фінального рев'ю», але дозволяє отримати ранній фідбек щодо напрямку підходу, не чекаючи повного завершення.
Практика для сфокусованого, легкого для рев'ю PR: невеликий, логічно завершений обсяг змін (одна функціональність чи один баг-фікс — та сама ідея, що й із гілками в попередньому модулі), змістовний опис PR («що» і, головне, «навіщо»), самостійний перегляд власного diff перед запитом рев'ю в колег.
Величезні PR із тисячами змінених рядків і десятками незв'язаних змін — практично неможливо якісно рев'ювити, і рев'юери або витрачають години, або (частіше на практиці) схвалюють поверхово, не читаючи все уважно.
Ігнорувати провалені CI-перевірки на PR і просити злити «все одно» — саме ці автоматизовані перевірки й існують, щоб зловити проблему до того, як вона потрапить у main.
Пряме force-push поверх гілки PR, над якою вже хтось інший залишив коментарі до конкретних рядків, — контекст коментарів може загубитись, якщо історія гілки значно змінюється.
Pull Request workflow вставляє явний крок код-рев'ю між «зміну код готова» і «зміна злита в main»: feature-гілка, пуш на remote, PR з описом, автоматизовані перевірки (CI), рев'ю колегами, і лише тоді злиття — звичайне, squash чи rebase, залежно від конвенцій команди. Невеликі, сфокусовані PR зі змістовним описом рев'юються якісніше й швидше, ніж великі, розпливчасті зміни.