Schválit / Aprobovat: co to je, approval a code review v Gitu

Co je schválení pull requestu

Schválení (approval) — je pozitivní recenze pull requestu, což znamená, že recenzent zkontroloval kód, nenašel kritické problémy a považuje změny za připravené ke sloučení. V rozhraní GitHubu je to zelené tlačítko «Approve» na stránce PR. Po schválení může autor (nebo jakýkoli účastník s právy zápisu) provést merge.

Proces schválení je součástí Branch Protection Rules. Majitelé repozitáře nastavují povinné požadavky: minimální počet schválení (např. 1 nebo 2), kdo může schvalovat (vlastníci kódu, členové týmu) a zda musí být PR znovu schváleno po změnách (Dismiss stale reviews). Bez nastavení pravidel je schválení volitelným krokem, ale v profesionálních týmech je povinné.

GitLab používá podobný mechanismus s názvem Approval Rules. V GitLabu lze nastavit, kolik schválení je vyžadováno od různých skupin (např. 2 od backend vývojářů a 1 od DevOps). Po obdržení všech povinných schválení je PR automaticky odblokováno pro merge za předpokladu zeleného CI/CD pipeline.

Typy recenzí: Approve, Request Changes, Comment

V GitHubu a GitLabu existují tři typy recenzí, které může recenzent zanechat na pull requestu. Každý typ má jiný stav a důsledky pro proces slučování. Approve — zelená, Request Changes — červená, Comment — neutrální šedá. Výběr typu závisí na kvalitě kódu a připravenosti změn k přijetí.

Approve — recenzent potvrzuje: kód je napsán správně, odpovídá standardům, neobsahuje zřejmé chyby a může být sloučen. Approve neznamená, že kód je ideální — pouze že je dostatečně dobrý pro produkci. Pokud existují drobné připomínky (styl, pojmenování), lze je zanechat jako komentáře bez blokování PR.

Request Changes — recenzent nachází problémy, které je třeba opravit před mergem: logické chyby, zranitelnosti, porušení architektury, chybějící testy. Po Request Changes je PR blokováno a k odblokování je vyžadováno nové schválení od stejného recenzenta (pokud je zapnuta možnost Dismiss stale reviews při nových commitech).

• Approve — kód je připraven ke sloučení, merge je možný po průchodu CI.
• Request Changes — povinné opravy, PR blokováno do nové recenze.
• Comment — obecná připomínka nebo návrh bez blokování PR.

Nastavení pravidel schválení v repozitáři

Branch Protection Rules — je mechanismus GitHubu pro kontrolu kvality slučování. Nastavuje se v Settings → Branches pro každou chráněnou vğrev (main, develop, release/*). Hlavní parametry: počet povinných schválení, vlastníci kódu (CODEOWNERS), povinná kontrola CI/CD a zákaz push bez PR.

Parametr Dismiss stale pull request approvals — automaticky odstraňuje schválení, pokud je do PR přidán nový commit. To zaručuje, že recenzenti schvalují přesně tu verzi kódu, která bude sloučena. Bez tohoto nastavení může autor přidat nový kód po schválení a ten se dostane do main bez nové kontroly.

CODEOWNERS — soubor v kořeni repozitáře, který určuje odpovědné osoby za různé adresáře. Pokud PR zasahuje do souborů patřících vlastníku kódu, jeho schválení se stává povinným. CODEOWNERS rozděluje oblasti odpovědnosti: iOS vývojář odpovídá za Swift soubory, DevOps — za Docker konfigurace, testeři — za testovací scénáře.

# Příklad souboru CODEOWNERS v kořeni repozitáře

# iOS vývojáři vlastní Swift kód
*.swift @team/ios-developers

# DevOps vlastní konfiguraci CI/CD
.github/workflows/* @devops-team

# QA inženýři kontrolují testy
**/tests/* @qa-engineers

# Výchozí vlastníci pro všechno ostatní
* @tech-leads

Code review před schválením: co zkontrolovat

Code review před schválením — je systematická kontrola kódu, nikoli povrchní pohled na diff. Kvalitní code review zahrnuje kontrolu architektury, logiky, stylu, testů a zabezpečení. Bez této kontroly se schválení stává formalitou, nikoli nástrojem kontroly kvality.

Co se kontroluje jako první: logika změn — řeší kód daný úkol, existují vedlejší účinky, je správné zacházení s okrajovými případy. Testy — pokrývají nové testy všechny scénáře, procházejí stávající testy po změnách. Zabezpečení — existují SQL injekce, XSS, úniky citlivých dat.

Co by nemělo být předmětem recenze: styl formátování (k tomu slouží lintery a formatter y), architektonická rozhodnutí učiněná předem (ta se projednávají před psaním kódu). Pokud má recenze více než 400 řádků nebo trvá déle než hodinu — to je signál, že úkol je příliš velký a vyžaduje dekompozici. Nejlepší praxí recenzí jsou porce 200–400 řádků do 24 hodin po vytvoření PR.

• Logika — správnost řešení úkolu, ošetření chyb, okrajové případy.
• Testy — pokrytí nových scénářů, průchod stávajících, absence flaky testů.
• Zabezpečení — absence injekcí, escapování výstupu, přístup k datům.
• Výkon — efektivita algoritmů, nadbytečné dotazy, úniky paměti.
• Dokumentace — je dokumentace aktualizována, jsou komentáře ve složitých částech srozumitelné.

Pracovní postup se schválením v týmu

Typický pracovní postup se schválením v týmu 5–10 vývojářů vypadá následovně: vývojář vytvoří PR, určí recenzenty (obvykle 1–2 osoby z týmu nebo vlastníky kódu), CI/CD spustí automatické kontroly. Po obdržení všech povinných schválení a zeleného CI provede autor merge. Doba od vytvoření PR do merge je v průměru 2 hodiny až 2 dny v závislosti na složitosti.

GitHub Actions umožňují automatizaci merge po schválení. Pokud jsou pravidla větve nastavena, GitHub sám blokuje merge, dokud nejsou splněny všechny podmínky. Některé týmy používají bors-ng nebo Mergify — boty, které automaticky slučují PR po obdržení všech schválení a průchodu CI. To urychluje proces a eliminuje lidský faktor při mergi.

Moderním přístupem je trunk-based development s krátce žijícími vğtvemi. V tomto pracovním postupu musí být schválení získáno během několika hodin, jinak je úkol považován za zastaralý a vyžaduje novou synchronizaci s main. Týmy s vysokou kulturou recenzí usilují o dobu schválení ne více než 4 pracovních hodin.

Chyby při schválení a jak se jim vyhnout

Nejčastější chyba — formální schválení bez skutečné kontroly kódu. Když je PR velké nebo se blíží termín, recenzent může stisknout Approve, aniž by se ponořil do změn. To znehodnocuje celý proces code review. Řešení: nastavit limit velikosti PR (ne více než 400 řádků) a používat nástroje pro analýzu kódu (SonarQube, CodeClimate) pro automatickou kontrolu.

Druhá chyba — příliš přísné schválení. Očekávání ideálního kódu blokuje vývoj. Recenzenti někdy požadují opravu stylistických připomínek, které neovlivňují kvalitu. Řešení: jasně oddělit povinné připomínky (blokující) a volitelné návrhy (komentáře). GitHub umožňuje výslovně učest, zda je komentář blokující.

Třetí chyba — schválení bez kontroly CI/CD. I když kód vypadá správně, může se nezkompilovat nebo selhat v testech. Nastavená Branch Protection automaticky blokuje merge při červeném CI, ale některé týmy tuto ochranu vypínají kvůli rychlosti. Řešení: vždy kontrolovat stav CI před schválením a nikdy neschvalovat PR s červeným pipelinem.

• Formální schválení — absence skutečné kontroly kódu. Řešení: limit 400 řádků na PR.
• Přílišná přísnost — blokování kvůli stylistickým připomínkám. Řešení: rozdělení na blocking a optional.
• Ignorování CI — schválení při červeném pipelině. Řešení: vŽy kontrolovat stav kontrol.
• Určení autora — schválení od autora PR. Řešení: nastavení Branch Protection proti autorovi.