Git Flow: mi ez, elágazási modell és használata projektekben

Mi az a Git Flow?

Git Flow — egy Git elágazási modell, amely szigorú ágstruktúrát és egyesítési szabályokat határoz meg a fejlesztés, kiadások és javítások kezelésére. Vincent Driessen 2010 januárjában publikálta az 'A successful Git branching model' című cikket, és azóta a Git Flow a de facto szabvánnyá vált a vállalati Java és .NET fejlesztésben. A fő ötlet — a kód felosztása öt ágtípusra különböző stabilitási szintekkel.

A Atlassian Git Tutorials, 2024 szerint a Git Flow két állandó ágra épül: main (korábban master) és develop. Az összes többi ág ideiglenes: feature, release, hotfix. Minden ágtípusnak egyértelműen meghatározott életciklusa és egyesítési szabályai vannak. A mobilfejlesztésben a Git Flow-t a rendszeres kiadási ciklusokkal (2–4 hét) és több verzió támogatásával rendelkező projektekben alkalmazzák.

Git Flow abban különbözik az egyszerű modellektől (GitHub Flow), hogy külön develop ágat igényel az integrációhoz. Ez egy lépéssel növeli az egyesítési folyamatot, de további elkülönítést biztosít a befejezetlen funkciók számára a kiadásra kész kódtól.

Vincent Driessen és a Git Flow története

2010-ben Vincent Driessen közzétette az 'A successful Git branching model' bejegyzést, amely a Git történetének egyik legtöbbet idézett bejegyzésévé vált. A modellt egy rögzített kiadásokkal és párhuzamos verziótámogatással rendelkező projekthez hozták létre. 2020-ban Driessen elismerte, hogy a Git Flow elavult a modern CI/CD gyakorlatokhoz, de a modell továbbra is releváns a hosszú kiadási ciklusú és régi verziók támogatását igénylő projektek számára.

# Git Flow inicializálása
git flow init

# Feature ág létrehozása
git flow feature start "add-auth"

# Feature ág befejezése (egyesítés a develop-ba)
git flow feature finish "add-auth"

# Release létrehozása
git flow release start "1.2.0"
git flow release finish "1.2.0"

Main ág: kiadási kód és címkézés

Main (korábban master) — a fő ág, amely csak az élesítésre kész kiadási kódot tartalmazza. Minden commit a main-ben a termék egy adott verziójának kell megfeleljen, amelyet a szemantikus verziókezelés formátumában lévő címkével (tag) jelölnek, például v1.0.0, v1.1.0. A main-ben nem folyik közvetlen fejlesztés — a változtatások csak release vagy hotfix ágakon keresztül kerülnek ide.

A semver.org, 2024 szerint a main-beli címkék a MAJOR.MINOR.PATCH formátumot használják. A MAJOR inkompatibilis API-változtatásoknál, a MINOR — visszafelé kompatibilis funkcionalitás hozzáadásánál, a PATCH — hibajavításoknál növekszik. A Git Flow-ban minden finish release automatikusan létrehoz egy commit-ot a main-ben egy verziócímkével.

Main — az egyetlen ág, amely éles környezetbe kerül. Mobil projektek esetén ez azt jelenti, hogy a main-be push-kor elindul az App Bundle vagy IPA buildelésének és a Google Play / App Store-ba történő publikálásnak a pipeline-ja. A GitLab CI/CD beállításaiban a main védve van a force-push és törlés ellen.

Szemantikus verziókezelés és címkék

Minden commit a main-ben egy címkével (tag) van ellátva SemVer formátumban: vMAJOR.MINOR.PATCH. MAJOR — inkompatibilis API-változtatásokhoz, MINOR — új, visszafelé kompatibilis funkcionalitáshoz, PATCH — hibajavításokhoz. Példa: a v2.1.0 a második nagy kiadást jelenti új funkciókkal és hibajavítások nélkül. A Git Flow-ban a címkék automatikusan jönnek létre a git flow release finish parancs segítségével a release vagy hotfix befejezésekor.

Develop ág: a fejlesztés integrációs vonala

Develop — a Git Flow második állandó ága, amely az összes befejezett funkció integrálására szolgál. A fejlesztők a kód felülvizsgálata és a CI/CD ellenőrzések után egyesítik a feature ágakat a develop-ba. A develop tartalmazza a kód legfrissebb stabil verzióját, amely az aktuális sprint összes megvalósított funkcióját magában foglalja.

A DataSift Git Flow Guide, 2024 szerint a develop átmenetileg instabil lehet a befejezetlen integrációk miatt. A problémák elkerülése érdekében a csapatok Continuous Integration (CI) alkalmaznak: minden funkció a develop-ba való egyesítés előtt egy teljes tesztsorozaton megy keresztül. Ha a CI meghiúsul — a fejlesztő kijavítja a kódot a következő egyesítésig. A develop mindig a main aktuális verziójához kapcsolódik: közvetlenül a kiadás után a develop szinkronizálódik a main-nel egyesítés útján.

Feature ágak: új funkcionalitás fejlesztése

Feature ágak — ideiglenes ágak egyedi funkciók, hibajavítások vagy kísérletek fejlesztéséhez. Minden feature ág a develop-ból jön létre, és befejezés után visszakerül a develop-ba. A feature ág neve általában tartalmazza a feladat számát vagy egy rövid leírást: feature/APP-123-add-oauth, feature/redesign-profile. A Git Flow-ban a feature ágak korlátlan ideig létezhetnek.

A Pro Git Book, 2024 szerint a feature ágak elkülönített fejlesztési környezetet biztosítanak: az egyik ágban végzett változtatások nem befolyásolják a többit az egyesítés pillanatáig. Mobil projektekben a feature ágakat rebase vagy merge segítségével szinkronizálják a develop-pal a nagy konfliktusok elkerülése érdekében. Javasolt a feature ág rebase-e a develop-ra az MR létrehozása előtt.

# Feature ág kézi létrehozása (git flow nélkül)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# MR létrehozása a GitLab-ban CLI-n keresztül
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Release ágak: kiadás előkészítése

Release ágak — ideiglenes ágak, amelyek a develop-ból jönnek létre a kiadás előkészítésére. Amikor a develop elegendő funkciót tartalmaz egy új verzióhoz, a csapat létrehozza a release/X.Y.Z ágat (például release/2.1.0). Ebben az ágban csak végső módosítások történnek: verziószám növelése, lokalizáció frissítése, végső tesztelés, kritikus hibák javítása.

A Atlassian Git Tutorials, 2024 szerint a release ág egy kulcsproblémát old meg: a végső módosítások elkülönítését a párhuzamos fejlesztéstől. Amíg a release készül a megjelenésre, a develop-ban továbbra is új funkciók egyesítése történik a következő kiadáshoz. Befejezés után a release ág beolvad a main-be (címkével) és a develop-ba (a verziószám növelésének szinkronizálásához).

Hotfix ágak: sürgős javítások az éles környezetben

Hotfix ágak — ideiglenes ágak a kritikus hibák sürgős javítására az éles környezetben. Az egyetlen Git Flow ágtípus, amely a main-ből jön létre, nem a develop-ból. Névformátum: hotfix/X.Y.Z+1 (például hotfix/2.1.1). Befejezés után a hotfix ág egyszerre olvad be a main-be (új javító kiadásként) és a develop-ba (hogy a javítás ne vesszen el a következő kiadások során).

A DataSift Git Flow Guide, 2024 szerint a hotfix ágaknak a lehető legrövidebbeknek kell lenniük — csak javítás és teszt. A hotfix nem tartalmazhat új funkciókat vagy refaktorálást. A mobilfejlesztésben a hotfix-et kritikus összeomlások (crash rate > 0.1%), biztonsági réseket vagy blokkoló hibák javítására használják az App Store-ban.

A Git Flow előnyei és hátrányai mobilfejlesztéshez

Git Flow világos struktúrát biztosít, amely különösen hasznos a nagy csapatok és a rendszeres kiadásokkal rendelkező projektek számára. Előnyök: a befejezetlen funkciók elkülönítése a feature ágakban, a kiadás előkészítésének lehetősége a fejlesztés blokkolása nélkül, több verzió támogatása hotfix segítségével. Hátrányok: bonyolultság a kezdők számára, a feature ágak rendszeres rebase-ének szükségessége, konfliktusok hosszú életű ágak esetén.

A Martin Fowler, 2024 szerint a Git Flow fő hátránya — a hosszú életű feature ágak. Ha egy funkciót 2+ hétig fejlesztenek a develop-pal való szinkronizálás nélkül, az egyesítéskor jelentős konfliktus alakul ki. Mobil projektek esetében javasolt a feature ág napi szinkronizálása rebase segítségével a develop-ra.

Git Flow nem ajánlott Continuous Deployment (minden commit a main-be → éles környezetbe) projektekhez. Az ilyen projektekhez a GitHub Flow vagy a Trunk-Based Development egyszerűbb és gyorsabb modellt kínál. De a kiadási ciklusokkal és régi verziók támogatásával rendelkező projektekhez a Git Flow továbbra is az optimális választás marad.

Mikor káros a Git Flow a csapat számára

A Git Flow három esetben válik problémává: a csapat kevesebb, mint 5 fő (túlzott bonyolultság), Continuous Deployment (szállítási késedelem), a rebase fegyelem hiánya (a hosszú életű feature ágak egyesítési konfliktusokat okoznak). Ha a csapat az ideje több mint 20%-át ágak egyesítésével és konfliktusok megoldásával tölti — a Git Flow nem megfelelő ennek a csapatnak, még nagy létszám esetén sem.

A Git Flow alternatívái: GitHub Flow és Trunk-Based Development

A Git Flow alternatívái egyszerűbb folyamatot kínálnak a CI/CD-t alkalmazó csapatok számára. GitHub Flow csak egy állandó ágat (main) és feature ágakat használ. Minden funkció a main-ből jön létre, felülvizsgálat és CI után visszakerül a main-be és azonnal élesítésre kerül. A GitHub Flow egyszerűbb, de nem támogatja a befejezetlen funkciók elkülönítését és a párhuzamos kiadás-előkészítést.

A GitHub Docs, 2024 szerint a Trunk-Based Development (TBD) még tovább megy: az összes fejlesztő egyetlen ágban (trunk) dolgozik, 1–2 napos rövid életű feature ágakat használva. A feature toggles (funkciókapcsolók) szabályozzák a befejezetlen kód láthatóságát. A TBD magas CI/CD fegyelmet és tesztautomataizációt igényel.

• GitHub Flow — egy main + feature ágak, ideális a CI/CD-hez és kis csapatokhoz
• GitLab Flow — továbbfejleszti a Git Flow-t környezeti ágakkal (staging, production)
• Trunk-Based Development — egy ág + feature toggles, maximális CI/CD, minimális egyesítés
• One Flow — egyszerűsített Git Flow develop ág nélkül, csak main + feature + release