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) — основният клон, съдържащ само кода на версията, готов за внедряване. Всеки commit в main трябва да съответства на определена версия на продукта, маркирана с таг във формат на семантично версиониране, например v1.0.0, v1.1.0. Никаква пряка разработка в main не се води — промените попадат тук само чрез release или hotfix клонове.

Според semver.org, 2024, таговете в main използват формат MAJOR.MINOR.PATCH. MAJOR се увеличава при несъвместими промени в API, MINOR — при добавяне на функционалност с обратна съвместимост, PATCH — при поправяне на грешки. В Git Flow всеки finish release автоматично създава commit в main с таг на версията.

Main — единственият клон, който се внедрява в продукция. За мобилни проекти това означава, че при push в main се стартира pipeline за изграждане на App Bundle или IPA и публикуване в Google Play / App Store. В настройките на CI/CD на GitLab, main е защитен от force-push и изтриване.

Семантично версиониране и тагове

Всеки commit в 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 съдържа последната стабилна версия на кода, включваща всички реализирани функции от текущия sprint.

Според 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 rate > 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 (всеки commit в 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