Kihagyás

Branchelés

BranchStructure

Példa branch struktúra

1. A main vagy master branch

A main (korábbi nevén master) branch már a projekt indulásánál létre lesz hozva. Ez egy védett branch, melynek célja a production környezetre utoljára kiadott verzió kódbázisának megőrzése.

A main branchre kizárólag hotfix illetve release branchek mergelése esetén kerülhet be új kód.

2. A develop branch

A develop branch már a projekt indulásánál létre lesz hozva. Ez egy védett branch melynek célja, hogy az aktívan fejlesztés alatt álló verzióhoz tartozó elkészült fejlesztéseket tartalmazza.

A develop branch-re kizárólag merge requesteken keresztül kerülhet be új kód. Ezen kívül pedig hotfix illetve release branchek mergelése esetén.

3. A feature branchek

Amikor bármilyen új funkciót, igényt, technikai hiányosságot vagy egy korábbi funkció bővítését fejlesztjük, úgynevezett feature branchet nyitunk hozzá.

3.1 Elnevezési konvenció

A feature brancheket az alábbi formátum szerint kell elnevezni: 

feature/{ProjektNévAcronym}-{TicketID}-Fejlesztés-rövid-leírása
Pl.: 
feature/SEMI-1-Add-calculation-feature

Branchek neve és a CI

Ha szeretnénk, hogy a CI pipeline a megfelelő frontend és/vagy backend branchünket egy konkrét api branchet felhasználva fordítsa le, akkor ugyanazzal a névvel kell létrehozni az api branchet mint amilyen néven a frontend és/vagy backend branchünket létrehoztuk.

Épp ezért az 1 tickethez tartozó brancheinket minden repositoryban ugyanazzal névvel hozzuk létre!

Ha a CI nem talál a megfelelő frontend és/vagy backend branchünkkel megegyezű nevű api branchet, akkor defaultból a develop-al fog fordulni (kivéve a hotfix-ről ágazó brancheknél ahol a main lesz a default).

A CI pipeline-ról részletesebben itt olvashatsz.

3.2 A bugfix és task branchek

A bugfix és task branchek speciális feature branchek. Technikailag csak abban különböznek a hagyományos feature branchektől, hogy a nevük a feature/ prefix helyett a bugfix/ vagy task/ prefixszel indul.

Céljuk, hogy már a branch neve alapján is el tudjuk különíteni, hogy a branchen található fejlesztés ténylegesen új funkció fejlesztést vagy hibajavítást esetleg technika fejlesztést tartalmaz.

A bugfix és task brancheknél is kövessük a feature brancheknél leírt elnevezési konvenciót azzal a különbséggel, hogy előbbieknél a prefix bugfix/ vagy task/.

3.3 Az epic branchek

Az epic branchek olyan speciális feature branchek, amelyek olyan komplex feature fejlesztést tartalmaznak, amelyek csak egyben mergelhetőek vissza a develop vagy a megfelelő release branchre.

Ezen kívül az epic branchek használata azt is lehetővé teszi, hogy már azelőtt elkezdődhessen az epichez tartozó feature fejlesztés, mielőtt konkrét döntés születne arról, hogy az melyik jövőbeli alkalmazásverzióba fog bekerülni.

Az epic brancheknél is kövessük a feature brancheknél leírt elnevezési konvenciót azzal a különbséggel, hogy előbbinél a prefix epic/.

Az epic branchen történő fejlesztés módszertanáról részletesebben itt olvashattok.

4. A release branchek

Amikor egy verzióhoz tartozó összes fejlesztés elkészül akkor technikai release-t megelőzően készítünk egy release branchet az adott verzióhoz. A release branchek a develop branchből ágaznak le.

A release branch célja, hogy a develop branchen zavartalanul folyatódhasson az olyan funkciók fejlesztése/mergelése amiket már nem szeretnék ebbe a releasebe belerakni. Ezzel párhuzamosan viszont a tesztelés során kieső bugokat is ezen a release branchen tudjuk javítani.

Az adott verzióhoz tartozó release branch a technikai release elkészültekor szűnik meg, méghozzá oly módon, hogy előtte a main majd pedig a develop branchre is mergelésre kerül.

A release folyamatról részletesebben olvashatsz itt.

A release branch mergelése a develop-ra

Előfordulhat, hogy a technikai release olyan sokáig húzódik és olyan sok javítást tartalmaz már a release branch a develop-hoz képest, hogy a technikai release kiadása előtt szükségessé válik, hogy mergeljük a develop-ra.

Ilyen esetekben a technikai release kiadása nélkül, időközben akár többször is, mergelhető a release branch a develop-ra. Fontos azonban, hogy a release branch ilyenkor továbbra is nyitva kell maradjon és további kódmódosítások kerülhetnek be rá. Így ez nem helyettesíti a release adás során végrehajtandó merge lépéseket.

4.1 Elnevezési konvenció

A release brancheket az alábbi formátum szerint kell elnevezni: 

release/{VerzióSzám}
Pl.: 
release/1.0.0

5. A hotfix branchek

A hotfix branchek speciális release branchek. Akkor hozunk létre hotfix branchet, ha valamilyen hiba miatt hotfix release adása szükséges a production verzióhoz. A hotfix branchek a main branchből ágaznak le.

A hotfix brancheket azért hozzuk létre, mert semmilyen új fejlesztést nem szeretnénk a hotfix verzióba beletenni, kizárólag a production környezeten észlelt hiba (vagy hibák) javítását kell tartalmaznia.

Az adott hotfix verzióhoz tartozó hotfix branch a technikai release elkészültekor szűnik meg, méghozzá oly módon, hogy előtte a main majd pedig a develop branchre is mergelésre kerül.

Fontos

A hotfix branchből ágazó feature branchek minden esetben bugfix branchek lesznek.

Extrém kivételek persze itt is lehetnek, de normál esetben nem fogunk új funkciókat fejleszteni a hotfix verziókba, kizárólag hibajavításokat.

5.1 Elnevezési konvenció

A hotfix brancheket az alábbi formátum szerint kell elnevezni: 

hotfix/{VerzióSzám}
Pl.: 
hotfix/1.0.1

6. Branchek karbantartása több release/hotfix branch esetén

6.1 Időközi és hierarchikus merge folyamat

Előfordulhat, hogy a projekten több verzióhoz tartozó release/hotfix branch-et kell párhuzamosan karbantartani.

Például tegyük fel, hogy:

  • A 2.0.0 alkalmazás verzióhoz tartozó release/2.0.0 branchből még nem készülhet el a technikai release, ezért még nem mergelhető vissza a main és develop branchekre.
  • Eközben a 3.0.0-ás fejlesztések már elkészültek, és a fejlesztőknek a fejlesztési függőségek feloldása miatt szüksége van arra, hogy már a 4.0.0 alkalmazás verzióhoz tartozó fejlesztések is be tudjanak kerülni a develop branchre.
  • Emiatt el kell készíteni a 3.0.0 alkalmazás verzióhoz tartozó release/3.0.0 branchet is.

A fent taglalt szituációnak az lesz a következménye, hogy amikor elkészül a 2.0.0 verzió technikai release-je akkor a release/2.0.0 branch main és develop branchekre történő visszavezetése a következő forgatókönyv szerint kell történjen:

  1. A release/2.0.0 branchet elősször mergeljük a main branchre.
  2. Ezt követően a release/2.0.0 branchet mergeljük a release/3.0.0 branchre.
  3. Végül a release/3.0.0 branchet mergeljük a develop-ra.

A release branchek hierarchikus mergelése a develop-ra

Figyeljük meg, hogy a fenti példában mindig az egyel korábbi verziójú release branchet mergeljük a rákövetkező verziójú release branchbe.

Ezt természetesen tetszőleges számú release branch esetén is követni kell, és a mergelések végeztével csak az aktuálisan legnagyobb verziójú release branchet mergeljük a develop-ra.

A release branchek időközi visszamergelése develop-ra

Szélsőséges esetekben előfordulhat, hogy egy release branch viszonylag sok ideig él párhuzamosan a develop branch mellett. Ekkor azzal a problémával szembesülhetünk, hogy az adott release branchen már elkészültek olyan fejlesztések/javítások amiket szeretnénk, ha már a develop branchen is elérhetőek lennének.

Ez a probléma feloldható oly módon, hogy a release branchet a technikai release előtt visszamergeljük a develop-ra.

Több egyidejűleg létező release branch esetén ilyenkor is az előző dobozban taglalt hierarchikus mergelést kell követni.

Fontos azonban, hogy a main branchre viszont csak és kizárólag a technikai release kiadásakor mergelhető a release branch.

Ne squasholjunk, release/hotfix branchek visszamergelése során

Fontos, hogy a release/hotfix brancheken keletkezett commitokat szeretnénk a célbrancheken is histórikusan látni a mergelés után is. Épp ezért figyeljünk arra, hogy semmiképp se squasholjuk ezeket a commitokat a merge előtt.

Merge commitok rebase-elése

Amennyiben a merge commit után szükség van rebase-re, mert például:

  • Rosszul oldottuk fel a conflictokat és szeretnénk squasholni a javítások commitjait a merge committal.
  • Szeretnénk átnevezni a merge commit message-et.

Akkor a git rebase parancshoz adjuk hozzá a: --rebase-merges kapcsolót, hogy a merge commit is megjelenjen az interaktív rebase TODO listájában: 

git rebase -i --rebase-merges HEAD~${rebaselni-kívánt-commitok-száma}
Vagy használhatjuk a kapcsoló synonym-ját is: 
git rebase -i -r HEAD~${rebaselni-kívánt-commitok-száma}

Párhuzamosan létező hotfix/release branchek

A fenti példákban csak release brancheket említ a leírás, de természetesen a hotfix branchek esetén is a fenti analógia érvényes.

Pl.: Ha a hotfix release elkészül, és létezik párhuzamosan egy (vagy több) release branch akkor a hotfix branchet előbb a main branchre, majd a release branchekre (hierarchikusan, kisebb verziótól a nagyobb felé haladva), végül a develop branchre mergeljük.

6.2 Köztes branchek használata

Akár több release/hotfix branchet tartunk karban párhuzamosan, akár egy normál release folyamat során akarjuk visszamergelni az aktuális release/hotfix branchünket, a conflictok feloldása nehézkes lehet.

Éppen ezért célszerű egy köztes branchet létrehozni (a target branch-ből), ahol elvégezhetjük a conflictok feloldását. Ha a köztes branchen sikeresen feloldottuk a conflictokat, akkor az már egyszerűen mergelhető az eredeti target branch-re.

Például, ha a release/2.0.0 branchet mergelünk vissza develop-ra, akkor a következőképp járjunk el:

  1. Az aktuális develop-ról ágazzunk le egy új branchen. A branch neve legyen: merge-2.0.0-into-develop.
  2. Merge-eljük a release/2.0.0 branchet a merge-2.0.0-into-develop branchre.
  3. Vizsgáljuk meg, hogy mindent jól csináltunk:
    1. Lefordul-e a kód.
    2. Lefutnak-e a tesztek.
    3. Elindul-e az alkalmazás.
  4. Merge-eljük a merge-2.0.0-into-develop branchet a develop-ra.

Az Időközi és hierarchikus merge folyamat bekezdésben leírt példa forgatókönyve, köztes brancheket használva az alábbira módosul:

  1. A release/2.0.0 branchet elősször mergeljük a main branchre.
  2. A release/2.0.0 branchet mergeljük a merge-2.0.0-into-3.0.0 branchre.
  3. A merge-2.0.0-into-3.0.0 branchet mergeljük a release/3.0.0 branchre.
  4. A release/3.0.0 branchet mergeljük a merge-3.0.0-into-develop branchre.
  5. Végül a merge-3.0.0-into-develop branchet mergeljük a develop-ra.

Commit stop a merge folyamat idejére

Eléggé meg tudja nehezíteni a merge-elési folyamatot, még a köztes branchek használata ellenére is, ha az eredeti target branchre a köztes branch létrehozása után folyamatosan érkeznek be az újabb commitok. Ebből következően a merge végeztéig, függesszük fel a módosítások mergelését a target branchre.

Köztes branchek elnevezési konvenciója

A köztes branchek név formátuma a következő: 

merge-${forrás-verzió}-into-${cél-verzió}

  • A ${forrás-verzió} placeholder helyére értelemszerűen a forrás release/hotfix branch verziószámát kell behelyettesíteni.
  • A ${cél-verzió} placeholder helyére értelemszerűen a cél release/hotfix branch verziószámát kell behelyettesíteni. Amennyiben a célbranch a develop, úgy a ${cél-verzió} placeholder helyére a develop szót kell behelyettesíteni.