Jan Mikoláš
Slovník pojmů
Pull request
Pull request neznamená příkaz git pull. Je to pracovní prostor pro návrh, kontrolu a vědomé sloučení změny do cílové větve; po merge se nic automaticky nemusí nasadit.
Stručná definice
Návrh změny, který dostane kontext, kontrolu a rozhodnutí.
Pull request je funkce platforem jako GitHub. GitLab používá pro stejný princip název merge request. Autor porovnává zdrojovou větev s cílovou větví, přidá popis a požádá o code review. V jednom místě jsou pak vidět změněné soubory, commity, komentáře, approval, requested changes a výsledky kontrol.
Git je distribuovaný verzovací systém. Commit je lokální záznam historie, větev je odkaz do historie a push odešle větev do vzdáleného repozitáře. Pull request není součást Git protokolu ani synonymum pro některý z těchto kroků; je to objekt spolupráce, který nad Git historií vytváří hostingová služba.
Příkaz git pull obvykle stáhne změny z remote a podle konfigurace je integruje do lokální větve. Pull request naopak nenatahuje nic do pracovního adresáře. Merge přijme návrh do cílové větve podle zvoleného způsobu integrace. Deployment je pak samostatný provozní krok, který může po merge spustit pipeline, ale nemusí se stát vůbec.
K čemu slouží
Jedno místo pro změnu, kontext a její ověření
Dobře připravený pull request zkracuje dobu review a dává týmu podklady, podle kterých může rozhodnout o bezpečném merge.
- porovnání změny vůči cílové větvi přes čitelný diff
- popis problému, řešení, testů, omezení a očekávaného dopadu
- vyžádání review od lidí, kteří rozumějí dané části systému nebo business pravidlu
- spuštění CI, testů, statické analýzy a případně bezpečnostních kontrol nad konkrétní změnou
- dohledání komentářů, rozhodnutí a souvislosti s issue, incidentem nebo release
- ochrana hlavní větve pomocí povinných approvals a merge checks
Praktický příklad
Malý pull request pro změnu výpočtu dopravy
Autor vytvoří větev feature/free-shipping-threshold, přidá několik commitů a otevře pull request proti main. Popis neříká jen „upraveno doručení“, ale uvádí nové pravidlo, komu platí, jaké objednávky jsou výjimka, jaké testy proběhly a zda se mění administrace nebo veřejné API.
Reviewer v diffu zkontroluje, zda se cena dopravy nepočítá dvakrát, zda změna neobchází měnu nebo slevový voucher a zda test zahrnuje hranici přesně na limitu. Po zeleném CI a vyřešení připomínek může dát approval. Merge spojí změnu do main; teprve workflow projektu rozhodne, zda vznikne release a kam se artefakt nasadí.
Text
Title: Free shipping from CZK 1,500
Problem: Shipping should be free for orders of CZK 1,500 and above.
Solution: The rule belongs in ShippingPriceCalculator, not the checkout controller.
Verification: Unit tests below, at, and above the threshold; manual checkout in CZK.
Risk: Does not apply to oversized shipping. No database migration in this release.Typický průběh
Od větve k merge, ne automaticky až do produkce
Textový diagram: větev a commity → pull request → diff, popis a CI → review → approval či requested changes → merge → samostatný release nebo deployment.
- Zdrojová a cílová větev Autor navrhne sloučení konkrétní zdrojové větve do například main. Systém vypočítá diff vůči zvolené cílové větvi.
- Popis a kontext Pull request uvádí proč změna existuje, jak se ověřila, co není součástí a zda má dopad na data, bezpečnost nebo vydání.
- Automatické checks CI přiřadí výsledky testů, buildu a statické analýzy ke konkrétnímu commitu nebo výsledku merge.
- Review a rozhodnutí Reviewer dává komentář, approval nebo requested changes. Potřebná schválení a blokující checks určuje pravidlo repozitáře, ne samotný název pull request.
- Merge a další životní cyklus Merge vytvoří či aktualizuje historii cílové větve. Release, databázová migrace, deploy, smoke test i monitoring jsou následující samostatné kroky.
Důležité části
Pull request drží pohromadě kód, kontext a pravidla merge.
Platforma ukazuje mnoho informací najednou. Jejich smysl je v tom, aby tým mohl udělat lepší rozhodnutí, ne zaplnit formulář.
Diff a commity
Diff ukazuje rozdíl mezi zdrojovou a cílovou větví. Commit je jednotlivý záznam Git historie; pull request jich může obsahovat více a není jejich kopií.
Autor a reviewer
Autor poskytuje kontext a reaguje na feedback. Reviewer kontroluje návrh a diff; oprávnění k merge, required reviews a code owners jsou pravidla konkrétního repozitáře.
Komentář, approval a requested changes
Komentář nemusí blokovat merge. Approval potvrzuje připravenost v daném review rozsahu. Requested changes upozorňuje na změnu před dalším schválením; zda technicky blokuje merge, závisí na nastavení platformy.
Draft a připravenost k review
Draft sdílí rozpracovanou práci bez požadavku na konečné rozhodnutí. Až když autor doplní popis, stabilizuje diff a dokončí základní ověření, označí změnu jako ready for review.
Checks nejsou review
Testy a PHPStan umí zablokovat známou chybu. Nevyhodnotí ale automaticky produktový kompromis, nejasné zadání, nevhodnou odpovědnost třídy nebo dopad na zákaznický proces.
Merge není deployment
Merge integruje změnu v Git historii. Deployment přenese artefakt do konkrétního prostředí a vyžaduje vlastní pravidla, secrets, migrace a ověření. Push ani merge samy o sobě nejsou release.
Výhody a limity
Spolupráce nad změnou za cenu disciplíny a čekání na rozhodnutí.
Přínosy
- transparentní diff a důvod změny před integrací
- spojení review, automatických checks a rozhodnutí do jednoho záznamu
- ochrana hlavní větve před nahodilým mergem
- snazší dohledání, proč se změnil konkrétní kontrakt nebo pravidlo
Časté chyby
- zaměňovat pull request za git pull, commit nebo samotnou branch
- otevřít velký pull request bez popisu a čekat, že reviewer domyslí produktový kontext
- merge považovat za automatické nasazení do produkce
- schválit změnu se zelenou CI bez čtení diffu a rizikového scénáře
- míchat funkci, refaktoring, formátování a závislostní update bez vysvětlení do jednoho návrhu
Kdy dává smysl
Pro změny, které mají být pochopitelné a bezpečně integrované.
Pull request se hodí pro týmovou práci i pro jednotlivce, který chce před mergem získat dohledatelný kontext a automatické kontroly. Rozsah procesu přizpůsob riziku: změna platby, oprávnění, cen nebo databázové migrace potřebuje více vysvětlení a zkušenější review než drobná oprava textu.
Není náhradou za návrhové rozhodnutí u rozsáhlého problému ani za release plán. Pokud se tým neshodne na pravidle nebo hranici systému, má se to vyjasnit dřív než ve stovkách řádků diffu. Pull request pak zachytí konkrétní realizaci tohoto rozhodnutí.
Praktická pravidla
Pull request má šetřit čas reviewerovi, ne ho přenášet na něj.
Autor může výrazně zvýšit kvalitu review ještě před prvním komentářem.
- název a popis napsat jako problém, řešení, ověření, omezení a riziko, ne jen jako technický úkol
- udržet diff sourodý; samostatně poslat formátování, závislosti nebo mechanický refaktoring
- před vyžádáním review projít vlastní diff a dokončit lokální i povinné automatické kontroly
- zvolit reviewera podle znalosti domény, bezpečnosti, databáze nebo integrace, ne jen podle dostupnosti
- po důležité změně odpovědět na komentář, označit vlákno za vyřešené podle pravidel týmu a vyžádat další review
- před mergem ověřit required approvals, stav checks, konflikty, release poznámku a vliv na kompatibilitu
Časté otázky
Pull request bez častých záměn
Je pull request totéž co git pull?
Ne. git pull je lokální Git příkaz pro získání a obvykle integraci změn z remote. Pull request je návrh na merge a prostor pro spolupráci ve službě nad Git repozitářem.
Je pull request commit nebo branch?
Ne. Commit je záznam Git historie a branch je reference do historie. Pull request obvykle porovnává zdrojovou a cílovou branch a může obsahovat více commitů, komentáře i checks.
Je merge automatický deployment?
Ne. Merge integruje změnu do cílové Git větve. Nasazení je samostatný proces; může ho automatizace spustit, může čekat na schválení, nebo se nemusí spustit vůbec.
Je zelené CI dostatečný důvod pro merge?
Ne. CI potvrzuje jen spuštěné automatické kontroly. Tým stále potřebuje review záměru, bezpečnostního a business dopadu, požadovaná approvals a připravenost na vydání.
Kdy použít draft pull request?
Když chce autor včas sdílet směr práce nebo získat neformální feedback, ale změna ještě není připravená k finálnímu review a merge.
Jak pracuji s kvalitou
Pull request používám jako spojení mezi změnou, kontrolou a vědomým vydáním.
Pro udržovatelný vývoj propojuji malé diffs, CI, testy, review a jasná pravidla pro integraci změn do hlavní větve.