Git Flow: шта је то, модел гранања и употреба у пројектима

Шта је Git Flow?

Git Flow — модел гранања Git-а који поставља строгу структуру грана и правила спајања за управљање развојем, издањима и исправкама. Vincent Driessen је објавио чланак „A successful Git branching model” у јануару 2010. године и од тада Git Flow је постао дефакто стандард у корпоративном Java и .NET развоју. Основна идеја — подијела кода на пет типова грана са различитим нивоима стабилности.

Према Atlassian Git Tutorials, 2024, Git Flow се заснива на двије трајне гране: main (раније master) и develop. Све остале гране су привремене: feature, release, hotfix. Сваки тип гране има јасно дефинисан животни циклус и правила спајања. У мобилном развоју, Git Flow се примјењује у пројектима са редовним издавачким циклусима (2–4 недјеље) и подршком за више верзија.

Git Flow се разликује од једноставних модела (GitHub Flow) по томе што захтијева засебну develop грану за интеграцију. Ово додаје један корак у процесу спајања, али обезбјеђује додатну изолацију незавршених функција од кода спремног за издање.

Vincent Driessen и историја Git Flow-а

2010. године Vincent Driessen је објавио пост „A successful Git branching model”, који је постао један од најцитиранијих у историји Git-а. Модел је креиран за пројекат са фиксним издањима и паралелном подршком за верзије. 2020. године Driessen је признао да је Git Flow застарио за савремене CI/CD праксе, али модел остаје актуелан за пројекте са дугим издавачким циклусом и потребом за подршком старих верзија.

# Иницијализација Git Flow-а
git flow init

# Креирање feature гране
git flow feature start "add-auth"

# Завршетак feature гране (спајање у develop)
git flow feature finish "add-auth"

# Креирање release-а
git flow release start "1.2.0"
git flow release finish "1.2.0"

Main грана: издавачки код и означавање

Main (раније master) — главна грана која садржи само издавачки код спреман за имплементацију. Сваки комит у main-у мора одговарати одређеној верзији производа, обиљеженој ознаком (tag) у формату семантичког верзионисања, на примјер v1.0.0, v1.1.0. Никакав директни развој у main-у се не води — промјене доспјевају овдје само кроз release или hotfix гране.

Према semver.org, 2024, ознаке у main-у користе формат MAJOR.MINOR.PATCH. MAJOR се повећава при некомпатибилним промјенама API-ја, MINOR — при додавању функционалности са уназадном компатибилношћу, PATCH — при исправљању грешака. У Git Flow-у, сваки finish release аутоматски креира комит у main-у са ознаком верзије.

Main грана — једина која се имплементира у продукцију. За мобилне пројекте, ово значи да при push у main покреће се pipeline израде App Bundle или IPA и објављивања у Google Play / App Store. У подешавањима CI/CD GitLab-а, main је заштићена од force-push и брисања.

Семантичко верзионисање и ознаке

Сваки комит у main-у је праћен ознаком у SemVer формату: vMAJOR.MINOR.PATCH. MAJOR — за некомпатибилне промјене API-ја, MINOR — за нову функционалност са уназадном компатибилношћу, PATCH — за исправљање грешака. Примјер: v2.1.0 значи друго велико издање са новим функцијама и без исправки грешака. У Git Flow-у, ознаке се креирају аутоматски при finish release или hotfix путем команде git flow release finish.

Develop грана: интеграциона линија развоја

Develop — друга трајна грана Git Flow-а, намијењена интеграцији свих завршених функција. Програмери уливају feature гране у develop након проласка кроз преглед кода и CI/CD провјере. Develop садржи најновију стабилну верзију кода која укључује све реализоване функције текућег спринта.

Према DataSift Git Flow Guide, 2024, develop може бити привремено нестабилан због незавршених интеграција. Да би се спријечили проблеми, тимови практикују Continuous Integration (CI): свака функција прије спајања у develop пролази комплетан скуп тестова. Ако CI падне — програмер поправља код до сљедећег спајања. Develop је увијек везан за тренутну верзију main-а: одмах након издања, develop се синхронизује са main-ом кроз спајање.

Feature гране: развој нове функционалности

Feature гране — привремене гране за развој појединачних функција, исправки грешака или експеримената. Свака feature грана се креира из develop-а и након завршетка улива се назад у develop. Име feature гране обично садржи број задатка или кратак опис: feature/APP-123-add-oauth, feature/redesign-profile. У Git Flow-у, feature гране могу постојати неограничено вријеме.

Према Pro Git Book, 2024, feature гране су изоловано развојно окружење: промјене у једној грани не утичу на друге до тренутка спајања. У мобилним пројектима, feature гране се синхронизују са develop-ом кроз rebase или merge како би се избјегли велики конфликти при завршетку. Препоручује се rebase feature гране на develop прије креирања MR-а.

# Ручно креирање feature гране (без git flow-а)
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-а у GitLab-у преко CLI-ја
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Release гране: припрема издања

Release гране — привремене гране креиране из develop-а за припрему издања. Када develop садржи довољан скуп функција за нову верзију, тим креира грану release/X.Y.Z (на примјер, release/2.1.0). У овој грани се уносе само коначне измјене: повећање верзије, ажурирање локализације, коначно тестирање, исправка критичних грешака.

Према Atlassian Git Tutorials, 2024, release грана рјешава кључни проблем: изолацију коначних измјена од паралелног развоја. Док се release припрема за излазак, у develop-у се наставља уливање нових функција за сљедеће издање. Након завршетка, release грана се улива у main (са ознаком) и у develop (ради синхронизације повећања верзије).

Hotfix гране: хитне исправке у продукцији

Hotfix гране — привремене гране за хитно исправљање критичних грешака у продукцији. Једини тип гране Git Flow-а који се креира из main-а, а не из develop-а. Формат имена: hotfix/X.Y.Z+1 (на примјер, hotfix/2.1.1). Након завршетка, hotfix грана се улива истовремено у main (као ново издање закрпе) и у develop (како се исправка не би изгубила при сљедећим издањима).

Према DataSift Git Flow Guide, 2024, hotfix гране треба да буду максимално кратке — само исправка и тест. Hotfix не смије укључивати нове функције или преображај. У мобилном развоју, hotfix се примјењује за исправљање критичних падова (стопа crash > 0.1%), рањивости безбједности или блокирајућих грешака у App Store-у.

Предности и мане Git Flow-а за мобилни развој

Git Flow даје јасну структуру која је посебно корисна за велике тимове и пројекте са редовним издањима. Предности: изолација незавршених функција у feature гранама, могућност припреме издања без блокирања развоја, подршка за више верзија кроз hotfix. Мане: сложеност за почетнике, потреба за редовним rebase-ом feature грана, конфликти при дуготрајним гранама.

Према Martin Fowler, 2024, главни недостатак Git Flow-а су дуготрајне feature гране. Ако се функција развија 2+ недјеље без синхронизације са develop-ом, конфликт при спајању постаје значајан. За мобилне пројекте препоручује се дневна синхронизација feature гране кроз rebase на develop.

Git Flow се не препоручује за пројекте са Continuous Deployment (сваки комит у main → у продукцију). За такве пројекте, GitHub Flow или Trunk-Based Development дају једноставнији и бржи модел. Али за пројекте са издавачким циклусима и подршком за старе верзије, Git Flow остаје оптималан избор.

Када је Git Flow штетан за тим

Git Flow постаје проблем у три случаја: тим мањи од 5 људи (претјерана сложеност), Continuous Deployment (кашњење испоруке), недостатак rebase дисциплине (дуготрајне feature гране стварају конфликте спајања). Ако тим троши више од 20% времена на спајање грана и рјешавање конфликата — Git Flow није погодан за тај тим, чак и при великој величини.

Алтернативе Git Flow-у: GitHub Flow и Trunk-Based Development

Алтернативе Git Flow-у нуде једноставнији процес за тимове који практикују CI/CD. GitHub Flow користи само једну трајну грану (main) и feature гране. Свака функција се креира из main-а, након прегледа и CI-ја улива се назад у main и одмах имплементира. GitHub Flow је једноставнији, али не подржава изолацију незавршених функција и паралелну припрему издања.

Према GitHub Docs, 2024, Trunk-Based Development (TBD) иде још даље: сви програмери раде у једној грани (trunk), користећи краткотрајне feature гране од 1–2 дана. Feature toggles (заставице функција) управљају видљивошћу незавршеног кода. TBD захтијева високу CI/CD дисциплину и аутоматизацију тестирања.

• GitHub Flow — један main + feature гране, идеалан за CI/CD и мале тимове
• GitLab Flow — развија Git Flow са окружењским гранама (staging, production)
• Trunk-Based Development — једна грана + feature toggles, максимум CI/CD, минимум спајања
• One Flow — поједностављени Git Flow без develop гране, само main + feature + release