Pull request od vytvoření po sloučení

V tomto článku se dozvíte, co je Pull Request (PR), proč slouží k diskusi o změnách a jak PR vytvářet i prohlížet přímo v IDE. Projdeme také tři pravidla dobrého commitu. Je to důležitý základ: Claude Code umí pull request připravit a okomentovat za vás, a abyste to mohli využívat s rozmyslem, potřebujete vědět, co PR je a k čemu slouží.

Příklady a snímky rozhraní pocházejí z IDE JetBrains; názvy a umístění akcí se ve vaší verzi mohou lišit. Pro cvičení použijte samostatný výukový repozitář. V pracovním projektu dodržujte jeho pravidla pro větve, commitování a odesílání změn.

Proč používat Pull Requests

V týmu se vyplatí probrat změny ještě před jejich začleněním do společné větve. Pull request spojuje navržený diff, připomínky a výsledky kontrol na jednom místě. Používá se i v osobních projektech, když si chcete před sloučením zkontrolovat vlastní práci.

Při práci s PR nejprve vytvoříte návrh na sloučení. Na GitHubu se mu říká Pull Request, na některých jiných platformách Merge Request. Konkrétní postup určuje tým.

Pull Request je oficiální žádost: "prosím, stáhněte (pull) moje změny z mé větve a přidejte (merge) je do hlavní větve". Není to ale jen žádost, nýbrž prostor pro diskusi, kontrolu a vylepšení kódu předtím, než se dostane do main.

Běžný postup při práci s Pull Requestem

Ukážeme si krok za krokem, jak obvykle vypadá práce na nové funkci.

Než vytvoříte větev, zkontrolujte zdrojovou větev a seznam jejích commitů vůči cílové větvi na GitHubu. Do nového PR se nesmějí dostat nesouvisející lokální commity. Neodesílejte je automaticky kvůli "synchronizaci": zvolte správný základ úkolu a předchozí práci si ponechte zvlášť.

Krok 1. Vytvořte větev pro nový úkol. Ukázkový postup s PR začíná samostatnou větví. Řekněme, že chceme přidat soubor s pravidly pro přispěvatele - vytvoříme větev feature/add-contribution-guide.

Krok 2. Proveďte změny a odešlete větev na GitHub. V nové větvi vytvořte soubor CONTRIBUTING.md (po vytvoření klikněte na Add) a napište do něj vzkaz ostatním vývojářům. Potom proveďte Commit and Push s výstižnou zprávou, například docs: Add contribution guide.

Tohle je zásadní krok. Pull Request vychází z větve, která už existuje na vzdáleném serveru. Než tedy PR vytvoříte, musíte novou větev odeslat (push) na GitHub.

Vytvoření Pull Requestu v IDE

Zkontrolujte obě strany porovnání: base je větev, do které změny navrhujete, compare/head je větev s vaší prací. Než PR vytvoříte, prohlédněte si seznam commitů a diff.

Teď, když už je vaše větev na GitHubu, můžete vytvořit Pull Request.

Krok 1. Otevřete kartu Pull Requests. Na levém postranním panelu IDE najděte kartu Pull Requests. Otevřete ji a klikněte na ikonu + (nebo na tlačítko Create Pull Request).

Krok 2. Vyplňte údaje PR. IDE otevře přehledné rozhraní. Vaším úkolem je ho pečlivě vyplnit. Hlavní pole:

1. nadpis - IDE sem často doplní název větve nebo text posledního commitu; ověřte, že je nadpis stručný, srozumitelný a vystihuje změny;
2. popis - podrobně kolegům vysvětlete, co přesně jste udělali a proč;
3. recenzenti (Reviewers) - lidé, které žádáte o kontrolu změn. Povinnost schválení určují pravidla repozitáře;
4. řešitelé (Assignees) - obvykle sem uvedete sebe jako autora a osobu odpovědnou za úpravy po review.

Než kliknete na Create Pull Request, ještě jednou zkontrolujte base, head a diff. Pokud práce ještě není připravená k review, můžete vytvořit Draft PR, je-li tato možnost dostupná. Běžný PR i draft už vidí lidé s přístupem k repozitáři.

Code review - kontrola a diskuse

Po vytvoření PR začíná nejdůležitější fáze - code review. Kolegové mohou PR otevřít, prohlédnout si všechny změny a přidat komentáře.

Všechny diskuse jsou dostupné přímo v IDE na kartě Pull Requests. Když někdo okomentuje řádek kódu, dostanete upozornění a můžete odpovědět, aniž byste přecházeli do prohlížeče.

Co dělat, když vás požádají o úpravy? Je to jednoduché: nový PR vytvářet nemusíte. Proveďte změny v kódu v původní větvi tohoto PR, vytvořte další commit a odešlete ho. Pull Request na GitHubu se automaticky aktualizuje a přidá nové commity do stávající diskuse.

Dokončení práce - sloučení a odstranění větve

Až budou všechny připomínky vyřešené a tým změny schválí (dostanete "approval"), můžete Pull Request sloučit. Obvykle to udělá zkušenější vývojář, případně vy, pokud máte v repozitáři potřebná oprávnění.

Krok 1. Sloučení. Zkontrolujte připomínky, povinná schválení a stav kontrol. Pokud pravidla a oprávnění sloučení dovolují, zvolte dostupný způsob (merge, squash nebo rebase) podle pravidel projektu a potvrďte ho. Změny se dostanou do cílové větve PR, v našem příkladu do main.

Krok 2. Odstranění větve. Po sloučení už feature větev není potřeba. Smažte ji, ať v repozitáři nepřekáží. GitHub vám to nabídne tlačítkem Delete branch.

Po sloučení se lokálně přepněte na main, stáhněte aktualizace a ověřte, že se výsledek PR projevil. Potom můžete odstranit místní větev úkolu, pokud v ní nezůstala práce, kterou potřebujete. Jestli vám ji IDE nedovolí smazat běžným způsobem, nejdřív zjistěte proč, zejména po squash nebo rebase.

Tři pravidla dobrého commitu

Dobrý commit nemá jen správnou zprávu, ale také správný obsah. Aby byla historie změn přehledná a užitečná, držte se tří jednoduchých pravidel.

Pravidlo 1 - pište srozumitelné zprávy

Vaše commity jsou zprávou týmu i vám samotným do budoucna. Historie plná samých "fix" nebo "update" je k ničemu. Jedním z rozšířených formátů jsou Conventional Commits, které navrhují tuto strukturu:

<typ>: <stručný popis>

Typ je krátké slovo, které popisuje kategorii změn:

• feat - nová funkce;
• fix - oprava chyby;
• docs - změny v dokumentaci;
• style - úpravy formátování bez vlivu na logiku;
• refactor - změny kódu bez nové funkce a bez opravy chyb;
• test - přidání nebo oprava testů;
• chore - rutinní práce (aktualizace závislostí, nastavení sestavení).

Příklady:

• Špatně: fixed bug
• Dobře: fix: Correct user login validation
• Špatně: readme
• Dobře: docs: Update installation instructions

Pravidlo 2 - jeden commit, jedna logická změna

Nesnažte se do jednoho commitu vměstnat opravu chyby, novou funkci a refactoring starého kódu. Takový commit se při review špatně kontroluje a téměř nejde bezbolestně vrátit. Každý commit má řešit jeden konkrétní úkol.

• Špatně: jeden commit "Update user page", který přidává pole pro avatar, opravuje ověřování jména a mění barvu tlačítek;
• Dobře: tři samostatné commity:
  1. feat: Add avatar upload to user profile
  2. fix: Correct username validation logic
  3. feat: Update button colors on user page

Pokud jste v zápalu práce změnili v jednom souboru příliš mnoho věcí, IDE umožňuje commitnout jen jeho část: v okně Commit můžete soubor rozbalit a zaškrtnout pouze ty úseky (chunks), které patří ke konkrétnímu úkolu.

Pravidlo 3 - ověřte výsledek změn

Před sloučením spusťte kontroly odpovídající změnám a prohlédněte si jejich skutečné výsledky. Pro úpravu dokumentace a novou logiku budou potřeba jiné kontroly.

Pokud už jsou v repozitáři nastavené automatické kontroly, PR zobrazuje jejich stavy. Zelená značka znamená, že konkrétní spuštěné kontroly uspěly, nikoli že v kódu nejsou žádné chyby. Podívejte se, co se spustilo a co zůstalo neověřené. Nastavení automatizace je samostatné téma.

Jak to funguje s Claude Code

PR je místo, kde je Claude Code obzvlášť užitečný. Na co se zaměřit:

• Claude umí vytvořit pull request z vaší větve s připraveným nadpisem a popisem - před vytvořením PR na GitHubu si text zkontrolujete;
• může projít změny PR a zanechat komentáře jako první kontrolu;
• pomáhá sestavit zprávy commitů podle pravidel projektu;
• může pomoct přečíst výsledky už nastavených kontrol a označit, co ověřené nebylo.

Předchozí článek: Větve a slučování v Gitu · Další článek: Vrácení a obnovení změn v Gitu