pul rikvestTakéPR, merge requestPokročilý
Definice
Pull request je návrh změny v repozitáři, který žádá ostatní členy týmu o kontrolu a případné sloučení do cílové větve. Obvykle obsahuje diff, popis záměru, komentáře reviewerů, stav automatických testů a historii úprav, takže se rozhodnutí o změně neodehrává jen v chatu nebo e-mailu.
Proč pull request vzniká až po commitech
Pull request navazuje na práci ve verzovacím systému, typicky v Gitu. Vývojář si založí větev, udělá commity, pošle větev na sdílený server a otevře návrh na sloučení. Samotný Git umí větve, commity a merge, ale pull request je hlavně pracovní objekt nad repozitářem: spojuje technickou změnu s debatou, kontrolami a rozhodnutím.
Název pochází z distribuovaného vývoje, kde autor změny žádá správce projektu, aby si jeho práci „přitáhl“ do své větve. Moderní hostingové platformy z toho udělaly běžný týmový proces. Pull request proto není jen tlačítko před mergem, ale dohledatelná stopa, proč se změna do kódu dostala.
Co v pull requestu kontroluje tým
Pull request obvykle ukazuje rozdíl proti cílové větvi, popis záměru, seznam dotčených souborů a komentáře k jednotlivým řádkům. Reviewer při code review nehledá pouze syntaktické chyby. Kontrola se často týká čitelnosti, bezpečnosti, kompatibility API, dopadu na výkon, testovatelnosti a souladu s architekturou projektu.
Automatické kontroly doplňují lidské posouzení. Pipeline v CI/CD může spustit testy, linting, typovou kontrolu, build nebo sken zranitelností. Stav těchto kontrol se pak stává součástí rozhodnutí, zda lze změnu sloučit. Tým si může nastavit pravidlo, že merge není povolen bez zelených testů a schválení určeným počtem reviewerů.
Větev, diff a diskuse drží změnu pohromadě
Pull request pomáhá oddělit rozpracovanou práci od stabilní větve, například main. Diff dává reviewerovi konkrétní podklad, diskuse zachycuje otázky a doplňující commity ukazují, jak autor reagoval. Oproti komentářům v chatu je výhoda v tom, že kontext zůstává u změny i po měsících.
Dobře napsaný pull request má úzký rozsah. Popis vysvětluje problém, zvolený postup, způsob ověření a případná rizika. Velký pull request s mnoha nesouvisejícími úpravami se kontroluje hůř, vede k povrchním schválením a zvyšuje šanci, že se do cílové větve dostane chyba.
Kdy pull request tým spíš zdržuje
Pull request není vždy nejlepší nástroj pro každou změnu. V malém experimentálním prototypu může přísný schvalovací proces zpomalit učení. V kritickém produkčním systému naopak příliš volná pravidla vytvářejí riziko, protože změny obcházejí kontrolu i auditní stopu.
Rozumný tým proto ladí pravidla podle rizika. Oprava překlepu v dokumentaci může projít rychle, změna platebního toku nebo migrace databáze si zaslouží detailnější kontrolu. Pull request má podporovat odpovědnost a sdílení znalostí, ne sloužit jako formální překážka bez technického přínosu.
Příklady z praxe
Oprava chyby před mergem
Vývojář opraví přesměrování po přihlášení v samostatné větvi a otevře pull request do větve main. Reviewer si všimne, že chybí test pro návratovou URL, takže autor doplní další commit. Pull request se sloučí až po zelených testech a schválení.
git checkout -b fix-login-redirect git commit -am "Fix redirect after login" git push origin fix-login-redirect # Pull request se potom otevře v nástroji pro hosting repozitáře.Malý diff s velkým dopadem
Tým mění odpověď uživatelského API, aby neposílala celou e-mailovou adresu. Pull request ukáže malý diff, ale reviewer upozorní na dopad na mobilní aplikaci a dokumentaci. Autor doplní poznámku k verzi API a změna se sloučí až po úpravě klienta.
- return user.email + return maskEmail(user.email)
Časté omyly
- MýtusPull request je jen formalita před kliknutím na merge.
- Ve skutečnostiPull request má zachytit důvod změny, kontrolu, automatické ověření a reakce autora. Bez této části se z něj stane jen dražší způsob přímého commitu do hlavní větve.
- MýtusČím víc souborů v pull requestu, tím líp je vidět odvedená práce.
- Ve skutečnostiVelký pull request se kontroluje pomaleji a revieweři v něm snáze přehlédnou chybu. Menší související změny obvykle vedou k přesnější kontrole a rychlejšímu sloučení.
Časté dotazy
- Má smysl otevírat pull request i pro malou opravu?
- Pull request nemusí být velký, aby měl hodnotu. Pull request pro malou opravu dává týmu auditní stopu, možnost automatických testů a prostor pro rychlou kontrolu. U banálních změn ale může tým zvolit lehčí pravidla, například jedno schválení nebo automatický merge po úspěšných kontrolách. Důležitý je poměr mezi rizikem změny a náklady na kontrolu.
- Co napsat do popisu pull requestu?
- Pull request by měl obsahovat jasný cíl změny, stručný popis řešení, postup ověření a upozornění na rizika nebo kompromisy. Pull request s textem typu „oprava“ nutí reviewera hádat souvislosti z diffu. U složitější změny pomáhá přidat screenshot, odkaz na issue, migraci databáze nebo poznámku, které části systému mohou být ovlivněné.
- Proč pull request dlouho čeká na sloučení?
- Pull request může čekat na autora, reviewera nebo automatické kontroly. Pull request se často zasekne kvůli nejasnému rozsahu, červeným testům, konfliktu s cílovou větví nebo chybějícímu rozhodnutí vlastníka kódu. Praktické je napsat konkrétní otázku, označit správného reviewera a po větší úpravě shrnout, co se od poslední kontroly změnilo.
- Je pull request totéž co merge?
- Pull request před mergem ukazuje návrh změny, diskusi a kontroly. Pull request po schválení obvykle vede k merge commitu, squash commitu nebo rebase podle pravidel repozitáře. Merge je samotné začlenění změny do cílové větve, zatímco pull request je proces a záznam rozhodnutí okolo této změny.
Zdroje
- Git - Distributed Workflows(otevře se v novém okně)
- Git - Contributing to a Project(otevře se v novém okně)
- About pull requests and permissions(otevře se v novém okně)
- Git - git-request-pull Documentation(otevře se v novém okně)
Související pojmy
