Pull requesty na GitHubu a code review, které týmu pomáhá

Pull request (PR) je návrh na začlenění změn z jedné větve do druhé. Na GitHubu kolem něj probíhá diskuse, kontrola kódu a automatické testy. Dobře nastavený proces PR je jedna z nejlevnějších cest k menšímu počtu chyb v produkci.

Základní tok práce

git switch -c fix/kosik-prazdny
# úpravy, commity
git push -u origin fix/kosik-prazdny

Po pushi GitHub nabídne tlačítko Compare & pull request. Rychlejší je GitHub CLI:

gh pr create --base main --title "Opravit pád při prázdném košíku" --body "Fixes #87"
gh pr create --draft          # rozpracovaný PR
gh pr status                  # přehled vašich PR
gh pr checkout 123            # stáhnout cizí PR lokálně k vyzkoušení
gh pr merge 123 --squash --delete-branch

Co dělá PR dobrým

Malý rozsah. PR s 200 změněnými řádky projde pečlivou kontrolou, PR s 3 000 řádky dostane „LGTM“ bez čtení.
Jedno téma. Refaktoring a nová funkce patří do samostatných PR.
Popis „proč“ a „jak ověřit“. Recenzent nemá váš kontext.
Screenshoty u změn v UI.
Odkaz na issue (Fixes #87 – po sloučení se issue samo uzavře).
Draft, dokud není hotovo – recenzenti vědí, že ještě nemají reagovat.

Šablona PR

Vytvořte soubor .github/pull_request_template.md a GitHub ho předvyplní do každého nového PR:

## Co a proč
<!-- Stručný popis změny a motivace -->

## Jak otestovat
1.
2.

## Checklist
- [ ] Testy prochází
- [ ] Aktualizována dokumentace
- [ ] Žádné tajné údaje v kódu

Fixes #

CODEOWNERS: automatičtí recenzenti

Soubor .github/CODEOWNERS určí, kdo je odpovědný za jaké části kódu:

# výchozí vlastník
*                 @firma/backend
/frontend/        @firma/frontend
/infra/           @jana-devops
*.sql             @petr-dba

Při otevření PR, který mění tyto cesty, GitHub dané lidi automaticky přidá jako recenzenty. Platí poslední odpovídající pravidlo.

Ochrana větve main

V Settings → Branches (nebo novějších Rulesets) nastavte pro main:

Require a pull request before merging – nikdo nepushne přímo.
Required approvals: 1 (nebo víc).
Require review from Code Owners – pokud používáte CODEOWNERS.
Require status checks to pass – PR nejde sloučit, dokud neprojde CI (viz první workflow v GitHub Actions).
Dismiss stale approvals – nový commit zruší dřívější schválení.
Block force pushes.

Způsob sloučení

Metoda	Výsledek	Kdy
Create a merge commit	všechny commity + merge commit	chcete zachovat detailní historii
Squash and merge	jeden commit v `main`	běžná volba pro feature PR
Rebase and merge	commity přesazené lineárně, bez merge commitu	čisté, dobře rozdělené commity

V nastavení repozitáře můžete nepoužívané metody vypnout a zapnout Automatically delete head branches.

Code review: jak recenzovat

Na co se dívat, zhruba v pořadí důležitosti:

Dělá změna to, co má? Pochopili jste zadání stejně?
Správnost a hraniční případy: prázdné vstupy, null, chyby sítě, souběh.
Bezpečnost: validace vstupu, SQL injection, oprávnění, tajné údaje.
Návrh: patří kód sem? Nedá se použít existující funkce?
Testy: pokrývají novou logiku?
Čitelnost a pojmenování.

Formátování a styl nechte na nástrojích (Prettier, Black, ESLint, Ruff) v CI – lidský čas je na důležitější věci.

Jak psát komentáře

Ptejte se místo přikazování: „Co se stane, když items bude prázdné?“ funguje lépe než „Tohle je špatně.“
Označte váhu: nit: pro drobnost, blocker: pro nutnou opravu. Autor ví, co musí a co může.
Používejte Suggestions. V komentáři zvolte Add a suggestion a napište opravený kód:

```suggestion
if not items:
    return []
```

Autor ji přijme jedním kliknutím (i několik najednou přes Add suggestion to batch).

Chvalte dobré věci. Recenze není jen hledání chyb.
Shrňte výsledek: Approve, Request changes, nebo Comment.

Jak reagovat jako autor

Odpovězte na každý komentář – opravou, nebo vysvětlením.
Nové změny dávejte do nových commitů, ať recenzent vidí rozdíl (Changes since last review). Uklidit je můžete squash merge.
Konverzace po vyřešení označte Resolve conversation.

Rychlost

Recenze, která čeká tři dny, brzdí celý tým víc než pár drobných chyb. Domluvte se na rozumné době odezvy, třeba do jednoho pracovního dne.

Tip pro PR z ColdHost AI

Pokud upravujete kód v Projektu v ColdHost AI, můžete změny poslat na GitHub rovnou jako novou větev nebo pull request. Projde pak stejným review a CI jako jakýkoli jiný PR – což je přesně tak, jak to má být.