Git Flow: co to jest, model rozgałęzień i zastosowanie w projektach

Co to jest Git Flow?

Git Flow — to model rozgałęzień Git, który określa ścisłą strukturę gałęzi i zasad scalania do zarządzania rozwojem, wydaniami i poprawkami. Vincent Driessen opublikował artykuł „A successful Git branching model” w styczniu 2010 roku i od tego czasu Git Flow stał się standardem de-facto w korporacyjnym rozwoju Java i .NET. Główną ideą jest podział kodu na pięć typów gałęzi o różnym poziomie stabilności.

Według Atlassian Git Tutorials, 2024, Git Flow opiera się na dwóch stałych gałęziach: main (wcześniej master) i develop. Wszystkie pozostałe gałęzie są tymczasowe: feature, release, hotfix. Każdy typ gałęzi ma ściśle określony cykl życia i zasady scalania. W rozwoju mobilnym Git Flow jest stosowany w projektach z regularnymi cyklami wydawniczymi (2–4 tygodnie) i obsługą wielu wersji.

Git Flow różni się od prostych modeli (GitHub Flow) tym, że wymaga oddzielnej gałęzi develop do integracji. Dodaje to jeden krok w procesie scalania, ale zapewnia dodatkową izolację niedokończonych funkcji od gotowego do wydania kodu.

Vincent Driessen i historia Git Flow

W 2010 roku Vincent Driessen opublikował post „A successful Git branching model”, który stał się jednym z najczęściej cytowanych w historii Git. Model został stworzony dla projektu ze stałymi wydaniami i równoległym wsparciem wersji. W 2020 roku Driessen przyznał, że Git Flow jest przestarzały dla nowoczesnych praktyk CI/CD, ale model pozostaje aktualny dla projektów z długim cyklem wydawniczym i koniecznością wsparcia starych wersji.

# Inicjalizacja Git Flow
git flow init

# Utworzenie gałęzi feature
git flow feature start "add-auth"

# Zakończenie gałęzi feature (scalenie z develop)
git flow feature finish "add-auth"

# Utworzenie release
git flow release start "1.2.0"
git flow release finish "1.2.0"

Gałąź Main: kod wydaniowy i tagowanie

Main (wcześniej master) — główna gałąź zawierająca tylko kod wydaniowy gotowy do wdrożenia. Każdy commit w main powinien odpowiadać określonej wersji produktu, oznaczonej tagiem w formacie wersjonowania semantycznego, na przykład v1.0.0, v1.1.0. Żaden bezpośredni rozwój w main nie jest prowadzony — zmiany trafiają tu tylko przez gałęzie release lub hotfix.

Według semver.org, 2024, tagi w main używają formatu MAJOR.MINOR.PATCH. MAJOR jest zwiększany przy niekompatybilnych zmianach API, MINOR — przy dodawaniu funkcjonalności z wsteczną kompatybilnością, PATCH — przy naprawianiu błędów. W Git Flow każde zakończenie release automatycznie tworzy commit w main z tagiem wersji.

Main — jedyna gałąź wdrażana na produkcję. Dla projektów mobilnych oznacza to, że przy push do main uruchamiany jest pipeline budowy App Bundle lub IPA i publikacji w Google Play / App Store. W ustawieniach CI/CD GitLab main jest chroniona przed force-push i usunięciem.

Wersjonowanie semantyczne i tagi

Każdy commit w main jest oznaczony tagiem w formacie SemVer: vMAJOR.MINOR.PATCH. MAJOR — dla niekompatybilnych zmian API, MINOR — dla nowej funkcjonalności z wsteczną kompatybilnością, PATCH — dla naprawiania błędów. Przykład: v2.1.0 oznacza drugie główne wydanie z nowymi funkcjami i bez poprawek błędów. W Git Flow tagi są tworzone automatycznie przy finish release lub hotfix przez polecenie git flow release finish.

Gałąź Develop: linia integracyjna rozwoju

Develop — druga stała gałąź Git Flow, przeznaczona do integracji wszystkich ukończonych funkcji. Programiści wlewają gałęzie feature do develop po przejściu przeglądu kodu i testów CI/CD. Develop zawiera ostatnią stabilną wersję kodu obejmującą wszystkie zrealizowane funkcje bieżącego sprintu.

Według DataSift Git Flow Guide, 2024, develop może być tymczasowo niestabilna z powodu niezakończonych integracji. Aby zapobiec problemom, zespoły praktykują Continuous Integration (CI): każda funkcja przed scaleniem z develop przechodzi pełny zestaw testów. Jeśli CI upadnie — programista naprawia kod przed kolejnym scaleniem. Develop jest zawsze powiązana z aktualną wersją main: zaraz po wydaniu develop jest synchronizowana z main przez scalenie.

Gałęzie Feature: tworzenie nowej funkcjonalności

Gałęzie feature — tymczasowe gałęzie do tworzenia poszczególnych funkcji, poprawek błędów lub eksperymentów. Każda gałąź feature jest tworzona z develop i po zakończeniu wlewana z powrotem do develop. Nazwa gałęzi feature zwykle zawiera numer zadania lub krótki opis: feature/APP-123-add-oauth, feature/redesign-profile. W Git Flow gałęzie feature mogą istnieć przez nieograniczony czas.

Według Pro Git Book, 2024, gałęzie feature to izolowane środowisko rozwoju: zmiany w jednej gałęzi nie wpływają na inne do momentu scalenia. W projektach mobilnych gałęzie feature są synchronizowane z develop przez rebase lub merge, aby uniknąć dużych konfliktów przy zakończeniu. Zaleca się rebase gałęzi feature na develop przed utworzeniem MR.

# Ręczne utworzenie gałęzi feature (bez 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

# Utworzenie MR w GitLab przez CLI
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Gałęzie Release: przygotowanie wydania

Gałęzie release — tymczasowe gałęzie tworzone z develop w celu przygotowania wydania. Gdy develop zawiera wystarczający zestaw funkcji dla nowej wersji, zespół tworzy gałąź release/X.Y.Z (na przykład release/2.1.0). W tej gałęzi wprowadzane są tylko końcowe poprawki: zwiększenie wersji, aktualizacja lokalizacji, końcowe testowanie, naprawa krytycznych błędów.

Według Atlassian Git Tutorials, 2024, gałąź release rozwiązuje kluczowy problem: izolację końcowych poprawek od równoległego rozwoju. Podczas gdy release jest przygotowywany do wydania, w develop nadal wlewane są nowe funkcje na następne wydanie. Po zakończeniu gałąź release jest wlewana do main (z tagiem) i do develop (aby zsynchronizować zwiększenie wersji).

Gałęzie Hotfix: pilne poprawki w produkcji

Gałęzie hotfix — tymczasowe gałęzie do pilnego naprawiania krytycznych błędów w produkcji. Jedyny typ gałęzi Git Flow tworzony z main, a nie z develop. Format nazwy: hotfix/X.Y.Z+1 (na przykład hotfix/2.1.1). Po zakończeniu gałąź hotfix jest wlewana jednocześnie do main (jako nowe wydanie poprawkowe) i do develop (aby poprawka nie zaginęła przy następnych wydaniach).

Według DataSift Git Flow Guide, 2024, gałęzie hotfix powinny być maksymalnie krótkie — tylko poprawka i test. Hotfix nie powinien zawierać nowych funkcji ani refaktoryzacji. W rozwoju mobilnym hotfix jest stosowany do naprawiania krytycznych awarii (wskaźnik crash rate > 0.1%), luk bezpieczeństwa lub blokujących błędów w App Store.

Zalety i wady Git Flow w rozwoju mobilnym

Git Flow daje jasną strukturę, która jest szczególnie przydatna dla dużych zespołów i projektów z regularnymi wydaniami. Zalety: izolacja niedokończonych funkcji w gałęziach feature, możliwość przygotowania wydania bez blokowania rozwoju, obsługa wielu wersji przez hotfix. Wady: złożoność dla początkujących, konieczność regularnego rebase gałęzi feature, konflikty przy długożyjących gałęziach.

Według Martin Fowler, 2024, główną wadą Git Flow są długożyjące gałęzie feature. Jeśli funkcja jest rozwijana 2+ tygodnie bez synchronizacji z develop, konflikt przy scalaniu staje się znaczący. Dla projektów mobilnych zaleca się codzienną synchronizację gałęzi feature przez rebase na develop.

Git Flow nie jest zalecany dla projektów z Continuous Deployment (każdy commit w main → na produkcję). Dla takich projektów GitHub Flow lub Trunk-Based Development dają prostszy i szybszy model. Ale dla projektów z cyklami wydawniczymi i obsługą starych wersji Git Flow pozostaje optymalnym wyborem.

Kiedy Git Flow szkodzi zespołowi

Git Flow staje się problemem w trzech przypadkach: zespół mniej niż 5 osób (nadmierna złożoność), Continuous Deployment (opóźnienie dostarczania), brak dyscypliny rebase (długożyjące gałęzie feature tworzą konflikty scalania). Jeśli zespół spędza więcej niż 20% czasu na scalanie gałęzi i rozwiązywanie konfliktów — Git Flow nie jest odpowiedni dla tego zespołu, nawet przy dużym rozmiarze.

Alternatywy dla Git Flow: GitHub Flow i Trunk-Based Development

Alternatywy dla Git Flow oferują prostszy proces dla zespołów praktykujących CI/CD. GitHub Flow używa tylko jednej stałej gałęzi (main) i gałęzi feature. Każda funkcja jest tworzona z main, po recenzji i CI wlewana z powrotem do main i natychmiast wdrażana. GitHub Flow jest prostszy, ale nie obsługuje izolacji niedokończonych funkcji i równoległego przygotowania wydania.

Według GitHub Docs, 2024, Trunk-Based Development (TBD) idzie jeszcze dalej: wszyscy programiści pracują w jednej gałęzi (trunk), używając krótkożyjących gałęzi feature na 1–2 dni. Feature toggles (flagi funkcji) zarządzają widocznością niedokończonego kodu. TBD wymaga wysokiej dyscypliny CI/CD i automatyzacji testowania.

• GitHub Flow — jedna main + gałęzie feature, idealnie nadaje się do CI/CD i małych zespołów
• GitLab Flow — rozwija Git Flow z gałęziami środowisk (staging, production)
• Trunk-Based Development — jedna gałąź + feature toggles, maksimum CI/CD, minimum scalań
• One Flow — uproszczony Git Flow bez gałęzi develop, tylko main + feature + release