Kihagyás

Merge Request

Ahhoz, hogy a feature, bugfix, task brancheinken elvégzett módosítások bekerülhessenek a megfelelő védett release, hotfix, develop, main branchekre, merge requestet (továbbiakban MR) kell nyitnunk.

A release, hotfix mergelése a develop illetve main branchekbe

A release és a hotfix branchek nem hagyományos MR-t és rebase-t használva, hanem a release folyamat részeként kerülnek mergelésre a main illetve develop branchekre. A Git release folyamatról itt olvashatsz részletesebben.

1. MR létrehozása

  1. A projekt GitLab repositoryjában bal oldalt válasszuk ki a Code, azon belül pedig a Merge requests menüpontot.
  2. Nyomjuk meg a jobb felső sarokban található New merge request gombot.
  3. Source branch-ként válasszuk ki a változásokat tartalmazó branchet. Target branch-ként pedig válasszuk ki a megfelelő cél branch-et. Pl.: develop.
  4. Ezt követően nyomjuk meg a Compare branches and continue gombot.
  5. A Title mezőbe adjuk meg az MR nevét majd nyomjuk meg a Create merge request gombot.

Merge options

Mindig ellenőrizzük, hogy az alábbi merge opciók legyenek bepipálva: MergeOptions

2. Elnevezési konvenció

MR Title-ként ugyanaz a formátum az elvárt ami a commit message-ek elnevezési konvenciójánál is.

Az MR címeknél természetesen azt is vegyük figyelembe, hogy a címnek tömören le kell írnia az MR-ben található változtatás miben létét.

Például ha a feladatunk a kliens regisztráció funkció bevezetése volt, akkor egy ideális MR title az alábbi: 

SEMI-1 Add client registration feature

Továbbá figyeljünk arra, hogy amennyiben nem squasholunk lokálisan, úgy a GitLab fogja elvégezni ezt helyettünk és automatikusan választja meg ehhez a commit message-et. Éppen ezért, amikor commit message-et írunk, fontos szem előtt tartanunk, hogy

  • amennyiben a branchünkön csak 1 commit van, úgy annak a commit message-je lesz a GitLab által választott squasholt commit message.
  • amennyiben a branchünkön több commit van, úgy a merge request title lesz a GitLab által választott squasholt commit message.

3. MR review folyamat

A review folyamat során a reviewer az MR Changes fül alatt nézi át a kódmódosításokat.

A reviewer az egyes észrevételeit kommentek formájában írja az MR-hez, így a fejlesztő is az MR-ben tudja ezeket áttekinteni és a review fixeket ugyanabban az MR-ben javítani.

Fontos

Az MR fixeket 1 db commit formájában kell a fejlesztőnek felpusholnia az MR-be. Ez azt jelenti, hogy amennyiben valamiért a review folyamat után több commit is keletkezik a branchen, akkor azokat, de csakis azokat a fejlesztőnek squasholnia kell mielőtt újra reviewra teszi az MR-t.

4. MR mergelése

Amennyiben a reviewer nem talált hibát, vagy minden review komment feloldásra került, az MR-t mergelelni lehet a védett branchre.

Ennek előfeltétele, hogy a mergelésre váró branch ne legyen lemaradva a cél branchhez képest. Egyszerűbb esetben ez feloldható a GitLab rebase funkciójával. Azonban ha a GitLab feloldásra váró conflictokat talál, akkor lokálisan kell kézzel rebaselnünk.

Fontos

Lokálisan is mindenképp rebaset használjunk merge helyett! Illetve, a fejlesztés során se használjuk a merge funkciót, kizárólag a rebaset. Amennyiben a reviewer merge commitokat lát egy MR-ben azt minden esetben vissza fogja dobni.

A rebase folyamat leírása megtalálható itt.