Апрувовати / Одобрити: шта је то, 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 пајплајна.

Врсте ревизије: 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, цурење осјетљивих података.

Шта не би требало бити предмет ревизије: стил форматирања (за то постоје linteri и formatteri), архитектурне одлуке донете унапред (о њима се расправља пре писања кода). Ако је у ревизији више од 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 против аутора.