Pull Request: co to je, proces vytvoření a code review

Co je to Pull Request?

Pull Request (PR) — je formální žádost o začlenění změn z jedné větve do druhé v rámci distribuovaného systému správy verzí. PR je ústředním prvkem společné vývoje na platformách GitHub, GitLab a Bitbucket, který spojuje diskusi o kódu, automatické testování a proces schvalování změn.

Název „Pull Request“ odráží podstatu operace: vývojář žádá (request) vlastníka repozitáře, aby „vytáhl“ (pull) jeho změny. Termín zavedl GitHub v roce 2008 — před tím existoval podobný mechanismus ve formě patchů a merge request (termín GitLab). Dnes je PR de facto standardem pro týmový vývoj s Gitem.

Podle údajů GitHub Octoverse, 2025 vyžaduje 89 % open-source projektů vytvoření PR pro provedení změn. V podnikovém vývoji tento ukazatel dosahuje 95 %. PR se stal nejen technickým nástrojem, ale součástí vývojářské kultury: prostřednictvím PR probíhá předávání znalostí, odhalování chyb a odsouhlasování architektonických rozhodnutí.

Součásti Pull Requestu

Typický PR se skládá z nadpisu, popisu, seznamu změněných souborů (diff), komentářů recenzentů a stavů CI kontrol. Každý PR je vázán na konkrétní zdrojovou a cílovou větev a po sloučení může být automaticky odstraněn.

Jak vytvořit Pull Request

Vytvoření PR začíná publikováním feature větve ve vzdáleném repozitáři. Po pushi vývojář otevře PR přes rozhraní platformy nebo přes CLI (gh, glab). Podívejme se na proces na příkladu GitHubu.

Push větve a otevření PR

Prvním krokem je pushnout feature větev do vzdáleného repozitáře a vytvořit Pull Request přes webové rozhraní nebo příkazový řádek.

# Vytvoření a push feature větve
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# Vytvoření PR přes GitHub CLI
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

Po vytvoření PR GitHub automaticky spouští CI pipeline (GitHub Actions), kontroluje konflikty s cílovou větví a zve recenzenty. Šablonu popisu PR lze nastavit pomocí .github/PULL_REQUEST_TEMPLATE.md, aby všechny PR obsahovaly povinné sekce: účel, změny, testování, související úkoly.

Popis a tagování

Kvalitní popis PR zahrnuje: odkaz na úkol (issue/ticket), stručný popis změn, návod k testování a seznam souvisejících změn. Štítky (bug, feature, refactoring) pomáhají kategorizovat PR, zatímco assignees a reviewers jsou přiřazováni automaticky přes CODEOWNERS.

# Přiřazení recenzentů přes CODEOWNERS (soubor v kořenu repozitáře)
# Příklad .github/CODEOWNERS:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# Vytvoření PR s přiřazením recenzentů přes gh cli
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS — standardní mechanismus GitHub/GitLab pro automatické přiřazování recenzentů podle změněných souborů. Například jakékoli změny v adresáři src/auth/ automaticky přiřazují jako recenzenty team-auth a senior-dev. To urychluje proces a zajišťuje, že správní lidé uvidí PR.

Aktualizace PR podle recenze

Po obdržení komentářů recenzenta vývojář provádí opravy ve stejné feature větvi a pushuje nové commity — PR se automaticky aktualizuje. Je důležité nepřepisovat historii (rebase) v publikované feature větvi, pokud je PR již otevřeno, protože to narušuje odkazy na konkrétní commity v komentářích.

# Provedení změn podle komentářů recenzenta
git checkout feature/biometric-auth
# opravit kód
git commit -m "fix: handle biometric timeout per review"
git push

# PR se automaticky aktualizuje
# Po schválení — sloučit PR přes rozhraní GitHub

Proces code review

Code review — ústřední prvek Pull Requestu. Recenzent kontroluje změny z hlediska správnosti, stylu kódu, bezpečnosti a architektonické konzistence. Kvalitní recenze nejen předchází chybám, ale také šíří znalosti o kódové základně v rámci týmu.

Engineering Practices společnosti Google (2025) doporučují následující zásady code review: recenzent musí rozumět kontextu změn, dávat konkrétní doporučení místo obecných poznámek a oddělovat technické a stylistické komentáře. Doba kontroly by neměla přesáhnout 24 hodin od vytvoření PR.

Pro vývoj mobilních aplikací zahrnuje code review specifické kontroly: kompatibilitu s targetSdk, správné zpracování lifecycle (Android) / view lifecycle (iOS), absenci úniků paměti (LeakCanary, Instruments), podporu tmavého režimu a lokalizaci. Tyto kontroly lze automatizovat pomocí linterů a Detekt/ktlint.

Typy komentářů

Platformy PR podporují tři typy komentářů: obecné (k celému PR), řádkové (ke konkrétnímu řádku kódu) a návrhy (suggestions s kódem k nahrazení). Návrhy umožňují aplikovat změnu jedním kliknutím, což urychluje proces a snižuje počet iterací.

Poté, co jsou všechny komentáře vyřešeny a CI kontroly úspěšně dokončeny, recenzent odešle schválení (Approved). PR může být sloučen. GitHub a GitLab podporují pravidla ochrany větví: povinný počet schválení, povinné CI kontroly, zákaz push do main bez PR. Pro mobilní projekty zahrnuje ochrana větve také kontrolu sestavení: PR nelze sloučit, pokud se aplikace nezkompiluje (gradle build failed / xcodebuild failed).

Řešení konfliktů v PR

Merge konflikty v Pull Requestu jsou běžnou situací při aktivní týmové práci. Platformy nabízejí řešení konfliktů přes webové rozhraní (pro jednoduché konflikty) nebo doporučují lokální řešení. GitHub Actions automaticky kontroluje možnost sloučení při každém pushi do feature větve a označí PR jako konfliktní, pokud sloučení není možné.

Nejlepší postupy Pull Request

Efektivní Pull Requesty urychlují code review a snižují počet chyb. Studie SmartBear (2025) ukázala, že PR o velikosti do 200 řádků kódu obdrží 2krát více věcných komentářů než PR o velikosti nad 1000 řádků, přičemž doba recenze se zkracuje 3krát.

• Malé PR — optimální velikost 100–300 řádků. Velké PR rozdělujte na logické části: každý PR řeší jeden úkol. To zjednodušuje recenzi a snižuje pravděpodobnost konfliktů
• Srozumitelný popis — nadpis podle Conventional Commits (feat:, fix:, refactor:), tělo PR obsahuje „co a proč“, nikoli „jak“ (kód mluví sám za sebe). Šablona: účel → změny → testování → související úkoly
• Rychlá zpětná vazba — recenze do 24 hodin. Pokud PR čeká déle než den, tým ztrácí kontext a roste počet konfliktů při sloučení
• Automatizace — lintery, formatter a testy by se měly spouštět automaticky při vytvoření PR. Nedovolte sloučení PR s neúspěšnými CI kontrolami
• Draft PR — používejte pro včasnou diskuzi o architektuře. Draft PR nevyžaduje recenzi a nelze jej sloučit, ale umožňuje ukázat kód kolegům v rané fázi

Další postupy: nevytvářejte PR v pátek večer (nikdo neudělá recenzi do pondělí), žádejte recenzi od 1–2 osob (více zpomaluje proces bez zvýšení kvality), používejte squash merge pro kompresi historie před sloučením. Pro mobilní projekty se také doporučuje přidat do popisu PR odkaz na testovací sestavení (Firebase App Distribution / TestFlight), aby recenzent mohl zkontrolovat změny ve fungující aplikaci.

Pull Request na různých platformách

Hlavní platformy pro práci s Pull Request jsou GitHub, GitLab a Bitbucket. Přes společnou koncepci má každá své specifika, která je třeba zvážit při výběru nástroje pro tým.

GitHub — nejpopulárnější platforma s největší komunitou, Actions pro CI/CD a rozsáhlým ekosystémem aplikací (GitHub Marketplace). GitLab se vyznačuje vestavěným CI/CD a možností plného self-hosted nasazení. Bitbucket je úzce integrován s Jirou a ekosystémem Atlassian, populární v podnikovém prostředí.

Pro vývoj mobilních aplikací je výběr platformy často určen možnostmi CI/CD: GitHub Actions podporuje macOS runnery pro sestavení iOS, GitLab má vestavěné runnery pro iOS/Android, Bitbucket se dobře integruje s Firebase Test Lab. Bez ohledu na platformu zůstává proces PR stejný: větev → recenze → CI → merge.