Přeskočit na hlavní obsah

Merge requesty

Merge requesty jsou velmi důležitou součástí vývoje pro projekty, na kterých se podílí více lidí. Prakticky s daty nedělají nic víc, než klasický merge. Rozšiřují ale tuto funkci o kontrolu obsahu před mergem jiným členem projektu. Merge requesty mají ale mnohem více výhod, o kterých si nyní povíme.

Co všechno merge request obsahuje​

Název​

Princip názvu merge requestu je podobný jako v commit message. Mělo by se jednat o výstižný popis toho, co se v rámci tohoto merge requestu změnilo. Jen s tím rozdílem, že commit message popisuje změny v rámci jednoho commitu, zde popisujete změny, které nastaly v celé větvi.

Jak má vypadat název MR
  • Fix analog measuring
  • Chore: Add support for API v2
  • Add automated testing

Popis​

Popis by měl obsahovat všechny potřebné detaily ohledně změn, které ve větvi nastaly. Měl by obsahovat následující informace:

  • Co se změnilo
  • Proč se to změnilo
  • Co to zlepšilo
  • Ideálně reference na issue nebo jiné MR, pokud jsou potřeba
Označování issue

Stejně jako lze zavírat issue pomocí specifického označení v commit message, lze je uzavírat i pomocí specifického označení v merge requestu. Toto označení je úplně stejné a více se o něm dozvíte zde.

Issue se automaticky uzavře, jakmile bude MR mergnutý.

Assignee​

Assignee je osoba, která je zodpovědná za merge request. Ve většině případů je to autor merge requestu. V některých případech se ale může jednat o architekta projektu nebo podobnou osobu. Pokud nevíte koho nastavit, nastavte sebe.

Assignee nesmí zůstat prázdný

Reviewer​

Reviewer je člověk, který celý MR zkontroluje a posoudí. Ve většině případů by se mělo jednat o maintainera projektu.

Review nesmí zůstat prázdný

Milestone​

Milestone umožňuje seskupovat merge requesty a vytvářet tak seznamy feature, bugfixů apod. v rámci nějaké várky. Většinou se milestony používají pro specifikaci vydání určité verze projektu. Pokud tedy MR souvisí s nějakou konkrétní verzí, měl by mít přiřazen příslušný milestone. Více o milestonech se dozvíte zde.

Jak a kdy vytvořit merge request​

MR vytvořte pokaždé, pokud potřebujete nechat zkontrolovat změny před mergem do nějaké větve. Pokud mergujete pracovní větev do mainu, je vhodné vždy vytvořit MR.

MR můžete vytvořit až, když je větev připravena na merge, ale je vhodné MR vytvořit ihned při vytvoření pracovní větve. Díky tomu je v seznamu ihned vidět kdo na čem aktuálně pracuje. V tomto případě označte MR jako draft.

Co to znamená, pokud je MR draft?

Znamená to, že ještě není dokončen, a ve větvi, ke které je MR vytvořen, stále probíhá aktivní vývoj. Pokud je MR draft, reviewer nedostane notifikaci o tom, že má něco kontrolovat, ale je vidět v seznamu MR. V tomto stavu by se stav neměl kontrolovat (provádět review).

Jakmile je MR připraven na review, stačí kliknout na tlačítko Mark as Ready. V tu chvíli reviewer dostane notifikaci a může provést review.

Vytvoření MR v GitLabu​

Pro vytvoření MR je nutné, aby existovala větev, kterou chcete mergnout. Tu můžete vytvořit pomocí standardních nástrojů nebo, pokud se jedná o MR, který bude řešit nějaké issue, můžete vytvořit větev v rozhraní issue.

Jakmile máte větev, stačí MR vytvořit v projektu pomocí: Code -> Merge Request -> New merge request. Objeví se formulář, kde vyberete z jaké větve chcete mergnout do jaké větve (většinou z nějaké pracovní větve do mainu). Nyní vyplníte formulář (viz výše) a poté kliknete na Create.

Merge requesty uzavírají větve

Je to sice zřejmé, ale i tak je dobré to zmínit. Merge request by měl být to poslední, co zažije pracovní větev. Jakmile je nějaká pracovní větev dokončena, vytvoří se merge request a po review se mergne do hlavní větve.

Jak a kdo merge requesty uzavře​

Merge request může být ukončen dvěma způsoby:

  • Merge - Pokud je schválen a následně mergnut
  • Close - Pokud byl zamítnut

Merge request může být mergnutý až ve chvíli, když jej reviewer schválí. O celém review procesu se více dozvíte v kapitole review.

Více reviewerů

V některých případech si může reviewer zažádat ještě o další review, pokud je to nutné. V takovém případě nejdříve schválí MR on a poté přiřadí dalšího uživatele jako reviewera. (může být vždy jen jeden) V historii MR je poté vidět posloupnost jednotlivých review.

Kdo provede Merge po schválení

Merge request může mergnout vždy pouze uživatel, který má práva do větve, do které se merguje. To většinou bývá main, takže se většinou jedná o maintainera. Pokud mají tato práva assignee i reviewer, tak merguje vždy assignee.