-
Notifications
You must be signed in to change notification settings - Fork 1
Branching modell
Jobbára a successful branching modellt próbáljuk követni. Ez alapján a master branchen csak működő, v1.0.0-tól csak élesíthető állapot lehet. Innen ágazik le a develop branch, ahol a fejlesztés történik. Ebbe a két branchbe csak pull requestek által kerülhet kód.
Tényleges fejlesztés issue brancheken történik. Ezek develop-ról (vagy bizonyos tracking issuek esetén egymásról) ágaznak le és a kindulási branchükbe térnek vissza (szükség esetén PR által).
Sürgős hibajavítás végezhető master-ről leágaztatott hotfix brancheken, amik review és PR után visszakerülnek master-be. A hotfix változtatások master -> develop merge által kerülnek be a fejlesztői ágba.
Ezeken kívül megengedett ideiglenes, kísérleti branchek létrehozása is. Ha megőrzendő a tartalmuk, akkor cherry-pick (vagy hasonló) módszer segítségével átmozgathatók a megfelelő részek a vonatkozó issue/hotfix branchbe (ha lehet, az átláthatóság kedvéért kerüljük a kísérleti branchek merge-ölését). Igyekezzünk nem telerakni a központi repót kísérleti branchekkel; ha nem muszáj, ne pusholjuk őket; ha meg mégis, akkor ha már nincs szükség rájuk, töröljük. Éppen ezért, valaki más kísérleti branchére ne alapozzunk munkát (főleg ha nem beszéltük meg az illetővel), mert azt a szerzője szabadon törölheti, rebase-elheti, módosíthatja saját belátása szerint.
A release branchek is ideiglenes élettartamúak. develop-ról indulnak, amikor a következő verzió minden szükséges issueja megoldásra került, hogy a következő verzió fejlesztését ne tartsák fel az élesítés közben felmerülő problémák. A release branchekről is indíthatóak issue branchek, de ezek új funkcionalitást nem tartalmazhatnak, csak bugfix történik ezen az ágon. Amikor minden rendben van a release branchen lévő verzióval és élesíthető, akkor be kell merge-ölni master-be, és itt master-t meg kell tagelni a megfelelő verzióval. Ezután a release branchen végrehajtott esetleges módosításokat vissza kell vezetni develop-ba egy master -> develop merge által.
Az egyes verziókhoz szükséges issuekat milestone-ok alá rendezzük. Ha egy adott milestone minden issueja elkészül, és nem várható, hogy új igény merül fel vele kapcsolatban, akkor el lehet indítani a release folyamatot.
- Éles verzió:
master - Fejlesztői verzió:
develop - Issue branchek:
i-{issue id}-{rovid-leiras} - Hotfix branchek:
h-{issue id}-{rovid-leiras} - Kísérleti branchek:
e-{user name}-{rovid-leiras} - Ha lesz release branch, akkor:
r-{verzio}
A rövid leírás a mintának megfelelően dash-case-ben írandó (nem snake_case vagy camelCase).
Igyekezzünk tartani magunkat az 1 issue, 1 branch felálláshoz. Kivételt képezhetnek ezek az esetek:
-
ha külön ezzel a céllal írt kód írása nélkül egy issue megoldása egy másik issue megoldását eredményezi
-
két issue megoldása olyan szorosan kapcsolódik egymáshoz, hogy nem praktikus külön-külön megoldani őket
Védett branchekbe (master, develop) csak pull request és review után kerülhet kód. Akik a reviewt végzik, értsék meg az ellenőrzött módosítást (akár a szerzőnek feltett kérdések által), hogy egy-egy résztvevő ne váljon nélkülözhetetlenné a projekt bizonyos részeinek a fenntartásához (busz faktor és társai). Főleg, mivel side project jelleggel megy a dolog és senki sem kötelezhető a részvételének folytatására.
A repositoryban csak a master és a develop branch létezhet állandó jelleggel. Ha egy issue, hotfix vagy release branch merge-ölésre került, akkor utána töröljük a branchet, ne kelljen feleslegesen kerülgetni őket a webes vagy parancssoros felületeken. Ez elsősorban a branch létrehozójának a feladata, de bárki megteheti.
A jelenleg karbantartott git flow extension lehetőséget ad feature branchek mellett bugfix branchek használatára is. Ez pusztán kozmetikai különbség, mindkettő a develop branchen alapul, így nálunk mindkét szerepet az issue branchek töltik be. Ennek megfelelően a git flow inicializáló scriptünk mind a kettőnek az i- prefixet állítja be, ezért a két alparancs (git flow feature ..., git flow bugfix ...) ugyanazt a célt szolgálja.
Ezen felül létezik a support branchek fogalma is git flowban. Ezek jobbára legacy verziók fenntartását tennék lehetővé. Lévén átlagos weboldal projektről van szó, ezt a funkcionalitást jelenleg nem használjuk.
Vonatkozó issue(k):