Апруввам / Заапруввам: какво е това, approval и code review в Git

Какво е апрув на pull request

Апрув (approval) е положителна рецензия за pull request, която означава, че ревюърът е проверил кода, не е открил критични проблеми и смята промените за готови за обединяване. В интерфейса на GitHub това е зеленият бутон „Approve" на страницата на PR. След апрува авторът (или всеки участник с права за запис) може да извърши merge.

Процесът на апрува е част от Branch Protection Rules. Собствениците на хранилището задават задължителни изисквания: минимален брой апруви (например 1 или 2), кой може да апрувва (собственици на кода, членове на екипа) и дали PR-то трябва да бъде апрувнато отново след промени (Dismiss stale reviews). Без настройка на правилата апрувът е незадължителна стъпка, но в професионалните екипи той е задължителен.

GitLab използва подобен механизъм с наименование Approval Rules. В GitLab можете да настроите колко апрува се изискват от различни групи (например 2 от разработчиците на бекенда и 1 от DevOps). След получаването на всички задължителни апруви PR-то автоматично се отключва за merge при условие, че CI/CD pipeline е зелен.

Видове ревю: Approve, Request Changes, Comment

В GitHub и GitLab съществуват три вида ревю, които ревюърът може да остави на pull request. Всеки вид има различен статус и последствия за процеса на обединяване. 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 за контрол на качеството на обединяванията. Настройва се в 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 тестове.
• Сигурност — липса на инжекции, ескейпване на изхода, достъп до данни.
• Производителност — ефективност на алгоритмите, излишни заявки, изтичане на памет.
• Документация — обновена ли е документацията, разбираеми ли са коментарите в сложните участъци.

Workflow с апрув в екипа

Типичният workflow с апрув в екип от 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 с краткоживущи клонове. В този workflow апрувът трябва да бъде получен в рамките на няколко часа, в противен случай задачата се счита за остаряла и изисква повторна синхронизация с main. Екипите с висока култура на ревю се стремят към време за апрув не повече от 4 работни часа.

Грешки при апрув и как да ги избегнем

Най-честата грешка е формалният апрув без реална проверка на кода. Когато PR-то е голямо или крайният срок е близо, ревюърът може да натисне Approve, без да се задълбочи в промените. Това обезценява целия процес на code review. Решение: да се зададе лимит за размера на PR (не повече от 400 реда) и да се използват инструменти за анализ на кода (SonarQube, CodeClimate) за автоматична проверка.

Втората грешка е прекалено строгият апрув. Очакването за идеален код блокира разработката. Ревюърите понякога изискват да се коригират стилистични забележки, които не влияят на качеството. Решение: ясно да се разделят задължителните забележки (блокиращи) от незадължителните предложения (коментари). GitHub позволява изрично да се посочи дали даден коментар е блокиращ.

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

• Формален апрув — липса на реална проверка на кода. Решение: лимит от 400 реда за PR.
• Прекомерна строгост — блокиране заради стилистични забележки. Решение: разделяне на blocking и optional.
• Игнориране на CI — апрув при червен pipeline. Решение: винаги да се проверява статусът на проверките.
• Определяне на автора — апрув от автора на PR. Решение: настройка на Branch Protection срещу автора.