Kihagyás

Fejlesztés epic branch használatával

1. Miért/Mikor használunk epic brancheket?

Az epic branchek használatát részben az indokolja, hogy vannak olyan komplex feature fejlesztések, amelyek csak egyben mergelhetőek vissza a develop branchre.

Ez kifejtve azt jelenti, hogy bár az epic branchből további feature branchek ágazhatnak le, (hiszen a komplex fejlesztés valószínűleg további részfeladatokra bontható), de ezek az epic-ből ágazó feature branchek önmagukban nem feltétlenül hordoznak üzletileg értéket, ezért nem mergelhetőek vissza önállóan a develop-ra.

Ezen kívül az epic branchek használatát az is indokolhatja, ha szeretnénk, 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.

2. Az epic branch nyitása/megszűnése

2.1 epic branch nyitása

Az epic branch nyitható develop de bizonyos esetekben release branchekből is.

epic branch nyitása release branchből

Előfordulhat, hogy az üzleti igény szerint egy epicben leírt funkció a 8.0.0 verzióba kellene, hogy kerüljön.

Ilyenkor, amennyiben a release/8.0.0 branch már elkészült, és a develop branchen már a 9.0.0 verzióhoz tartozó fejlesztések zajlanak, akkor az említett epic fejlesztéshez szükséges epic branchet a release/8.0.0 branchből kell nyitni.

2.2 epic branch megszűnése

Amikor az epic branchhez tartozó összes fejlesztés elkészült:

  • merge request nyitása szükséges,
  • abba a branchbe kell mergelni amelyiken annak a verziónak a fejlesztése zajlik, amelyikben az epic fejlesztést is szállítani szeretnénk
  • squash-olni kell a commitokat, hogy a develop vagy release branchre a merge után 1 darab commit kerüljön.

Commitok megtartása az epic branchen

Felmerülhet a projekten, hogy nem szeretnénk squasholni az epic-hez tartozó commitokat amiatt, hogy a Git history-ban megmaradjanak az epicből nyíló feature branchek merge commitjai. Bizonyos esetekben ennek valóban lehetnek előnyei, de olyannyira megnehezítheti az epic branch karbantartását (pl.: a rebease-eket a célbranch-el), hogy a Semi ajánlás mindenképp a commitok squasholása az epic branchen.

release branchből nyitott epic branch mergelése develop-ra

Előfordulhat, hogy az üzleti igény szerint egy epicben leírt funkció a 8.0.0 verzióba kellene, hogy kerüljön.

Ilyenkor, amennyiben a release/8.0.0 branch már elkészült, és a develop branchen már a 9.0.0 verzióhoz tartozó fejlesztések zajlanak, akkor az említett epic fejlesztéshez szükséges epic branchet a release/8.0.0 branchből kell nyitni.

Amennyiben az a döntés születik, hogy az epicben leírt funkció mégsem kerül be a 8.0.0 verzióba, hanem a 9.0.0 verzióba kell kerüljön, akkor az epic branchet a develop-ra kell mergelni.

Értelemszerűen, ha az epic branch mergelése előtt időközben elkészült a release/9.0.0 branch, és a develop branchen már a 10.0.0 verzióhoz tartozó fejlesztések zajlanak, akkor a fent említett epic branchet a release/9.0.0-ra kell mergelni.

epic branch mergelése

Általánosan megfogalmazva az epic branchet mindig abba a branchbe kell visszamergelni, amelyiken annak a verziónak a fejlesztése zajlik, amelyikben az epic fejlesztést is szállítani szeretnénk.

A gyakorlatban:

  • Ha az epic fejlesztést tartalmazni kívánt verzióhoz már létezik release branch, akkor abba a release branchbe kell mergelni az epic branchet.
  • Ha az epic fejlesztést tartalmazni kívánt verzióhoz tartozó fejlesztések a develop-on zajlanak akkor a develop-ra kell mergelni az epic branchet.

3. Az epic fejlesztéséhez tartozó feature branchek nyitása/megszűnése

3.1 Az epic fejlesztéshez tartozó feature branch nyitása

Az epic-hez tartozó részfeladatokat feature brancheken szükséges lefejleszteni. Ezeket a feature brancheket minden esetben az epic branchből kell nyitni.

3.2 Az epic fejlesztéshez tartozó feature branch megszűnése

Amennyiben a fejlesztés elkészült:

  • merge request nyitása szükséges,
  • a feature branchet minden esetben az epic branchre kell mergelni,
  • squash-olni kell a commitokat, hogy az epic branchre a merge után 1 darab commit kerüljön.

4. Az epic branch karbantartása

Mivel az epic branchen hosszabb ideig tart a fejlesztés, így fokozatosan lemarad a cél branchez képest.

Épp ezért célszerű az epic branchet rendszeres időközönként rebase-elni a célbranchre, hogy ne a mergelés előtt kelljen bonyolult rebase-elést végezni. Ilyenkor squash-oljuk is az aktuálisan epic branchen lévő commitokat, ezáltal is könnyítve a rebaset.

Amennyiben a célbranch-hez képest jelentős lemaradásban van az epic branchünk, vagy összetett conflictok feloldása szükséges a rebase során, akkor célszerű a célbranchből egy ideiglenes branchet létrehozni, amit rebaselhetünk az epic branchre, és a rebase végeztével ezt az ideiglenes branchet mergeljük az epic branchre.

Példa az epic branch célbranchre történő rebaselésére ideiglenes branchet használva

Tegyük fel, hogy az epic branchet a develop-ból nyitottuk.

A rebase lépései:

  1. Ideiglenes branch létrehozása a célbranchből (jelen esetben develop-ból), amit pusholjunk is a remote repositoryba: 
    git checkout develop
git pull
git checkout -b develop-changes-temporary
git push --set-upstream origin develop-changes-temporary

  2. (Opcionális) Amennyiben számos committal le van maradva az epic branch a célbranchez (develop) képest, célszerű a célbranch commitjait squash-olni, mielőtt belekezdünk a rebase-be. 

    git rebase -i HEAD~{commitok-száma}
    A commitok-száma értelemszerűen a develop-changes-temporary branch, epic branch-hez képesti commitjainak számát jelenti. Pl.: Ha 5 commit található rajta, akkor a parancs: git rebase -i HEAD~5.

  3. Ideiglenes branch rebaselése az epic-re: 

    git fetch
git rebase origin/epic

  4. Az esetleges conflictok feloldása.
  5. A rebase eredményének pusholása: 
    git push --force-with-lease
  6. Merge request nyitása, és az develop-changes-temporary branch mergelése az epic branchre.

  7. Az eddigi lépések eredménye az lesz, hogy a develop-ra bekerült fejlesztések átkerülnek az epic branch-re. Azonban, mielőtt az epic branchet mergelni tudnánk a develop-ra, az epic branchet is rebaselni kell a develop-ra.

    Amennyiben az epic branch commitjait squasholjuk, úgy ez a második rebase könnyebben véghezvihető, ugyanis a conflictokat már feloldottuk a develop-changes-temporary branch rebaselése során, így az epic branch rebaselése során már elegendő az epic-ből érkező módosításokat elfogadnunk. Fontos, hogy ez csak akkor igaz, ha az epic branchen található commitokat squasholjuk a rebase előtt!

feature branchek rebase-elése, az epic branchek rebase-elése után

Miután az epic branchet rebase-eljük a célbranchre, az epic branchből ágazó feature brancheket is rebaselnünk kell az epic branchre.

Az, hogy rebase szükséges onnan is észrevehető, hogy a feature branchünkön olyan commitok jelennek meg, amelyek valójában már mergelve vannak az epic branchre.

Ilyenkor a feature rebase során azzal szembesülhetünk, hogy olyan kódban is conflictot kell feloldanunk, amelyet valójában nem érintettek a feature branchen zajló fejlesztéseink. Ebben az esetben NE ijedjünk meg, hanem amennyiben a kérdéses kódban nem végeztünk a feature branchen módosítást, egyszerűen fogadjuk el az epic branchen lévő állapotot (hiszen az már rebaselve van).

Fontos azonban, hogy azoknál a kódoknál amelyek valóban módosultak a feature branchen történő fejlesztés során, továbbra is fel kell oldanunk a conflictokat.