4.2 Branch stratégiák – Git Flow, GitHub Flow, trunk-based

Áttekintő

Ahogy az előző alfejezetben láttuk, a Git nem fájl-diffekenként gondolkodik, hanem snapshotokban. A branch-ek erre épülnek: egy branch nem más, mint egy mutató egy adott commitra. Olcsó, gyors, és ebből következik, hogy szabadon kísérletezhetünk velük.

De a branch önmagában még nem stratégia. Az igazi kérdés: hogyan szervezi a csapat a munkát branch-ek segítségével?

Ez az alfejezet három elterjedt megközelítést mutat be, elmagyarázza, mikor melyiket alkalmazzák a cégek, és végigveszi egy feature branch teljes életútját – a létrehozástól a törléséig.

Részletes tartalom

Miért kell egyáltalán branch-elni?

Képzeld el, hogy a csapatban mindenki közvetlenül a main branch-re dolgozik. Az egyik kolléga egy félkész feature-t pushed, a másik egy bugfixet, te meg épp egy kísérletbe kezdtél. Az eredmény: instabil main, tönkrement deploy, összevissza history.

A branch-ek ezt oldják meg: minden egyes munkaszál saját, izolált ágon fut, és csak akkor kerül vissza a közös ágra, ha kész és átvizsgált.

A három fő stratégia

1. Git Flow

A Git Flow 2010-ben jelent meg, és sokáig iparági standardnak számított. Karakterisztikája: sok, hosszú életű branch.

A Git Flow-ban a következő ágak léteznek:

main (vagy master) – mindig production-ready állapot
develop – az aktív fejlesztés integrációs ága
feature/* – új funkciók (innen indul, ide kerül vissza)
release/* – release előkészítése (verziózás, utolsó javítások)
hotfix/* – production bugfix, közvetlenül a main-ből indul

Mikor alkalmazzák?

Klasszikus, ütemezhető release ciklussal dolgozó cégek (pl. mobilalkalmazások, embedded software)
Ahol a main mindig kiadható verziónak kell lennie
Ahol több párhuzamos release-t tartanak fenn egyszerre

Hátránya: bonyolult, sok overhead. A feature branch-ek sokáig élnek, ami merge conflicthoz vezet. A modern web-fejlesztésben egyre ritkábban használják.

2. GitHub Flow

A GitHub Flow egy egyszerűsített modell: csak egy hosszú életű branch van (main), minden más feature branch.

Működése:

Hozz létre egy branch-et main-ből
Dolgozz, commitelj rendszeresen
Nyiss egy Pull Requestet
Code review után merge-elj a main-be
Deploy közvetlenül a main-ből
Töröld a feature branch-et

Mikor alkalmazzák?

Webalkalmazások, ahol folyamatos deployment van (Continuous Delivery)
SaaS cégek, startupok, kisebb csapatok
Ahol a review a kapuőr, nem egy külön develop ág

Előnye: egyszerű, átlátható. A legtöbb junior fejlesztő ezzel találkozik először.

3. Trunk-Based Development (TBD)

A trunk-based development extrém: a fejlesztők közvetlenül a main-re (trunk-ra) pusholnak, vagy nagyon rövid életű (1-2 napos) feature branch-eket használnak.

A biztonságot nem az ágak adják, hanem:

Feature flag-ek (a kód bent van, de ki van kapcsolva)
Erős automatizált tesztek (CI minden pushra lefut)
Kis, inkrementális commitok

Mikor alkalmazzák?

Nagy, senior csapatok magas CI/CD kultúrával (Google, Facebook, Atlassian)
Ahol a csapat tagjai naponta több alkalommal integráljanak
Ahol a feature flag infrastruktúra megvan

Junior szempontból: valószínűleg nem ezzel fogod kezdeni, de hasznos tudni, hogy létezik, és megérteni, mi tartja össze.

Összehasonlítás egymás mellett

Jellemző	Git Flow	GitHub Flow	Trunk-Based
Hosszú életű ágak	Sok	Csak `main`	Csak `main`
Release ciklus	Ütemezett	Folyamatos	Folyamatos
Review kapuja	Igen	Igen (PR)	CI/CD + flags
Alkalmas mikor	Verzionált termék	SaaS, web	Magas CI kultúra
Konfliktus kockázat	Magas	Közepes	Alacsony
Komplexitás	Magas	Alacsony	Közepes

Feature branch életciklusa (GitHub Flow példán)

Ez az a folyamat, amit a legtöbb júnior fejlesztőként végig fog csinálni.

1. Branch létrehozása

A main legfrissebb állapotából indulsz:

git checkout main
git pull origin main
git checkout -b feature/user-profile-page

A branch neve sokat elmond: feature/, bugfix/, hotfix/ prefix, majd rövid, kebab-case leírás.

2. Fejlesztés és commitolás

Dolgozol, rendszeresen commitelj (erről bővebben a következő alfejezetben). A kulcs: ne gyűjts több napi munkát egyetlen commitba.

git add .
git commit -m "Add user profile page skeleton"
# ... több commit ...
git commit -m "Add avatar upload functionality"

3. Push és Pull Request megnyitása

git push origin feature/user-profile-page

Ezután a GitHub/GitLab felületen megnyitod a Pull Requestet. A PR az, ahol a csapat véleményezi a munkádat – erről a 4.4-es alfejezetben részletesebben.

4. Code review és visszajelzés

A reviewer-ek kommenteket írnak, te javítasz, újra push-olsz. Ezek a commitok automatikusan bekerülnek a nyitott PR-ba.

5. Merge

Ha minden rendben, a PR merge-elésre kerül a main-be. A merge stratégiáról (merge commit, squash, rebase) szintén a 4.4-es alfejezet szól.

6. Branch törlése

A merge után a feature branch-et törölni szokás – mind remote-on, mind lokálisan:

# Remote törlés (általában a GitHub felületen egy gomb)
git push origin --delete feature/user-profile-page

# Lokális törlés
git branch -d feature/user-profile-page

Ez nem veszteség: a commit history megmarad a main-ben.

Branch elnevezési konvenciók

A legtöbb csapat valamilyen konvenciót követ. Íme a leggyakoribbak:

Prefix-alapú:

feature/user-authentication
bugfix/login-redirect-loop
hotfix/payment-null-pointer
chore/update-dependencies
docs/api-documentation

Ticket-alapú (Jira, Linear):

PROJ-123-user-authentication
feature/PROJ-456-dashboard-redesign

Amit kerülj:

fix (mi a fix? melyik fix?)
test (mindenki test-et ír)
my-branch (ki a te?)
new-feature-v2-final-FINAL (ez már kódban is fájdalmas volt)

A jó branch név egyetlen olvasásból megmondja, mi van benne.

Életszerű példák

Példa 1: Az első PR

Tomi első napján kap egy feladatot: „Add hozzá a felhasználói profiloldalhoz a bio mezőt."

Rossz, amit sokan csinálnak:

git checkout main
# ... módosít a main-en ...
git push origin main

Helyes megközelítés:

git checkout -b feature/add-bio-field-to-profile
# ... módosítások ...
git commit -m "Add bio field to user profile form and model"
git push origin feature/add-bio-field-to-profile
# → Pull Request megnyitása

Miért számít az interjún? Mert ha megkérdezik, „hogyan dolgozol csapatban Git-tel?", és azt mondod, „mindenki a main-re push-ol", az azonnali piros lámpa.

Példa 2: Hosszú feature branch következménye

Anna egy hétig dolgozik a feature/new-payment-flow branch-en anélkül, hogy szinkronizálná a main-nel. Közben a kollégái 30 commitot push-oltak.

Amikor Anna végre merge-elni próbál: masszív merge conflict. Az egész napja elmegy a feloldással.

Megoldás: rendszeresen húzd be a main változásait a feature branch-edbe:

git checkout feature/new-payment-flow
git merge main
# vagy: git rebase main

Ez naponta 5 perc, és megspórol egy egész napot.

Példa 3: A névtelen branch büntetése

Krisztián a fix2 nevű branch-re dolgozik. Két hét múlva visszatér hozzá: mi volt ez? Melyik bug? A Git log sem segít, mert a commitok is homályosak.

Ha a branch neve bugfix/user-session-expires-on-page-refresh, azonnal tudja – és tudja mindenki más is.

Tesztfeladatok

1. feladat – Stratégia azonosítása (feleletválasztós)

Egy e-kereskedelmi webáruház negyedévente ad ki új verziót, egyszerre több patch verziót tart fenn, és van külön QA fázisuk. Melyik Git stratégia illik hozzájuk leginkább?

a) GitHub Flow
b) Trunk-Based Development
c) Git Flow
d) Bármelyik egyformán alkalmas

Helyes válasz: c) – A Git Flow ütemezett release ciklusra és több párhuzamos verzió kezelésére tervezték.

2. feladat – Branch életút sorrendbe állítása

Az alábbi lépések egy feature branch életciklusát írják le. Rendezd őket helyes sorrendbe:

a) Pull Request megnyitása
b) Branch törlése
c) git pull origin main a legfrissebb állapotért
d) Fejlesztés és commitolás
e) Branch létrehozása
f) Code review és javítás
g) Merge a main-be

Helyes sorrend: c → e → d → a → f → g → b

3. feladat – Branch név értékelése

Értékeld az alábbi branch neveket: melyik jó, melyik problémás és miért?

a) feature/add-user-authentication
b) fix
c) PROJ-234-shopping-cart-empty-state
d) johns-branch
e) hotfix/payment-null-pointer-exception
f) new-stuff-v3

Megoldás:

a) ✅ Jó – prefix + leíró, kebab-case
b) ❌ Problémás – semmit nem mond, melyik fix?
c) ✅ Jó – ticket ID + leírás, visszakereshető
d) ❌ Problémás – személynév, nem leíró
e) ✅ Jó – hotfix prefix, pontos leírás
f) ❌ Problémás – nem derül ki, mi az a „new stuff"

4. feladat – Szituáció: mi a teendő?

Elindítottál egy feature branch-et 5 napja. Megtudod, hogy a kollégád közben javított egy bugot a main-en, ami az általad is módosított fájlt érinti. Mit teszel?

a) Várod, amíg a feature kész, és akkor foglalkozol a konfliktussal
b) Törölöd a branch-et és elölről kezded
c) Behúzod a main változásait a feature branch-edbe (git merge main vagy git rebase main)
d) Commitolsz a main-re közvetlenül

Helyes válasz: c) – Minél hamarabb szinkronizálsz, annál kisebb a konfliktus.

5. feladat – Igaz/hamis állítások

Döntsd el, igaz vagy hamis az állítás:

a) „A Git Flow-ban a develop branch mindig production-ready állapotban van."
b) „A branch törlése után a benne lévő commitok is elvesznek."
c) „A GitHub Flow-ban minden munkát Pull Request előz meg."
d) „A trunk-based development csak nagy csapatoknál működik, feature flag infrastruktúra nélkül lehetetlen."
e) „Egy feature branch-et érdemes rendszeresen szinkronizálni a main-nel, hogy elkerüljük a nagy merge conflictokat."

Megoldás:

a) ❌ Hamis – develop az aktív fejlesztés ága, a main production-ready
b) ❌ Hamis – a commitok megmaradnak a main-ben, ahova merge-eltek
c) ✅ Igaz – ez a GitHub Flow lényege
d) ✅ Igaz – feature flag nélkül a TBD nehezen kivitelezhető production kódra
e) ✅ Igaz – ez az egyik legfontosabb preventív szokás

6. feladat – Melyik stratégiát alkalmazzák?

Kösd össze a szituációt a legvalószínűbb Git stratégiával:

Szituációk:

Egy mobilalkalmazás-csapat, akik az App Store-ba havonta adnak ki frissítést
Egy SaaS startup, ahol naponta több deploy is van
Egy nagy technológiai cég, ahol minden fejlesztő naponta push-ol a main-re és feature flag-ek szabályozzák a kiadást

Stratégiák:

A) Git Flow
B) GitHub Flow
C) Trunk-Based Development

Megoldás: 1-A, 2-B, 3-C

7. feladat – Hibaelem azonosítása

Az alábbi workflow-ban azonosítsd a problémát:

Péter elindít egy feature/new-dashboard branch-et. 3 hétig dolgozik rajta, közben soha nem szinkronizál a main-nel. Amikor kész, megnyit egy Pull Requestet. A reviewer azt látja, hogy a branch 47 committal le van maradva a main-től, és 12 fájlban van conflict. A review elhúzódik, Péter fél napot tölt a conflictok feloldásával.

Kérdések:

Mi volt a konkrét hiba?
Mi lett volna a helyes megközelítés?
Mit csinálhat Péter most, hogy minimalizálja a kárt?

Megoldás:

Hiba: 3 hetes izolált fejlesztés szinkronizálás nélkül
Helyes: napi vagy kétnapi git merge main / git rebase main a feature branch-en
Most: git merge main a konfliktusok feloldásával, majd szükség esetén pair programming a reviewerrel az összetett részeken