GitFlow – jak zarządzać branchami w zespole developerskim

GitFlow to jeden z najpopularniejszych modeli pracy z branchami w Gicie. Powstał w 2010 roku i przez lata uchodził za standard w zespołach wydających oprogramowanie w cyklach. Dziś wiele firm odchodzi od niego na rzecz prostszych podejść, ale przez cały czas sprawdza się w konkretnych projektach.

W tym artykule wyjaśniamy, co to jest GitFlow, jak działa każdy typ brancha i kiedy warto go używać. Porównujemy też GitFlow vs trunk-based i pokazujemy, jak dobrać git workflow do swojego zespołu.

GitFlow – co to jest?

GitFlow to model git branching opisany w styczniu 2010 roku przez Vincenta Driessena w artykule A successful Git branching model. Nie jest funkcją Gita ani narzędziem. To zestaw konwencji: jakie branche tworzysz, jak je nazywasz i kiedy łączysz je ze sobą.

Model powstał w czasach, gdy większość zespołów wydawała oprogramowanie w wersjach, np. 2.1 czy 3.0. Nie istniało jeszcze powszechne continuous delivery. Driessen potrzebował sposobu, by równolegle rozwijać nowe funkcje, stabilizować wydanie i gwałtownie łatać błędy na produkcji.

Warto pamiętać o jednej rzeczy. W 2020 roku sam autor dodał do swojego artykułu notkę. Napisał w niej, iż dla aplikacji webowych wdrażanych w trybie ciągłym lepszy jest prostszy workflow. GitFlow zaprojektował z myślą o oprogramowaniu wersjonowanym i wydawanym w cyklach.

Dwa branche długożyjące

GitFlow opiera się na dwóch branchach, które istnieją przez cały czas życia projektu.

main (dawniej master)

Na main leży kod, który trafił lub może trafić na produkcję. Każdy commit na tym branchu to nowe wydanie, oznaczone tagiem z numerem wersji. Dzięki temu zawsze wiesz, co dokładnie działa u klientów.

Nazwa master była przez lata domyślna. Od 2020 roku GitHub i inne platformy ustawiają jako domyślną nazwę main. Sam model działa tak samo, zmienia się wyłącznie nazewnictwo.

develop

Na develop trafia kod przygotowany do następnego wydania. To branch integracyjny. Łączysz tu gotowe funkcje i sprawdzasz, czy współpracują ze sobą. Develop zawiera najnowsze zmiany, ale nie musi być jeszcze gotowy na produkcję.

Trzy branche pomocnicze

Poza dwoma głównymi branchami GitFlow wprowadza trzy typy branchy krótkożyjących. Każdy ma jasno określone zadanie.

feature/*

Branch feature tworzysz dla każdej nowej funkcji lub zadania. Odchodzi od develop i wraca do develop. Przykładowa nazwa to feature/logowanie-sso albo feature/JIRA-123-koszyk.

Typowy przebieg wygląda tak:

bash git checkout develop git pull origin develop git checkout -b feature/logowanie-sso # ... praca, commity ... git checkout develop git merge --no-ff feature/logowanie-sso git branch -d feature/logowanie-sso

Flaga –no-ff wymusza utworzenie osobnego commita scalającego. Dzięki temu w historii widać, które commity należały do jednej funkcji. Zespoły często zastępują ten krok pull requestem z code review.

release/*

Gdy na develop jest już komplet funkcji na kolejne wydanie, tworzysz release, np. release/2.4.0. Odchodzi od develop. Na tym branchu nie dodajesz nowych funkcji. Poprawiasz tylko błędy, aktualizujesz numer wersji i przygotowujesz dokumentację.

Dzięki temu zespół może dalej pracować nad kolejnymi funkcjami na develop, a QA testuje stabilną wersję. Po zakończeniu stabilizacji scalasz release do main i oznaczasz tagiem. Następnie scalasz go także z powrotem do develop, żeby poprawki nie zginęły.

hotfix/*

Hotfix służy do pilnych poprawek na produkcji. Odchodzi bezpośrednio od main, np. hotfix/2.4.1. Po naprawie scalasz go do main z nowym tagiem oraz do develop. jeżeli akurat istnieje branch release, hotfix scalasz także do niego.

Dzięki hotfixom nie musisz czekać na koniec cyklu wydawniczego, by naprawić krytyczny błąd. Nie blokujesz też pracy nad nowymi funkcjami.

Jak wygląda cykl wydania w praktyce

Spójrzmy na przykład zespołu, który wydaje wersję co dwa tygodnie:

1. Programiści tworzą branche feature/* z develop i pracują nad zadaniami ze sprintu.
2. Gotowe funkcje wracają do develop przez pull request po code review.
3. Pod koniec sprintu lider tworzy release/1.8.0.
4. QA testuje wersję. Błędy poprawiasz bezpośrednio na branchu release.
5. Po akceptacji scalasz release do main, dodajesz tag v1.8.0 i scalasz zmiany z powrotem do develop.
6. Jeśli na produkcji wyjdzie błąd, tworzysz hotfix/1.8.1 z main.

Cały proces jest przewidywalny. Każdy w zespole wie, gdzie szukać kodu na danym etapie.

Narzędzia: git-flow i automatyzacja

Do GitFlow powstały skróty w postaci rozszerzenia git-flow. Zamiast kilku komend wpisujesz jedną, np. git flow feature start nazwa. Oryginalne narzędzie autora nie jest już rozwijane. Popularną kontynuacją była wersja AVH, ale jej status warto sprawdzić w repozytorium przed wdrożeniem, bo projekt mógł zostać zarchiwizowany.

Wiele zespołów rezygnuje z rozszerzenia i stosuje konwencję manualnie. Pomagają w tym:

• reguły ochrony branchy (branch protection) w GitHubie, GitLabie lub Bitbuckecie, które blokują bezpośrednie pushe na main i develop,
• wymagane code review i przechodzące testy CI przed scaleniem,
• konwencje nazewnictwa egzekwowane przez hooki lub reguły w repozytorium,
• automatyczne tagowanie i generowanie changelogu na podstawie commitów.

Zalety GitFlow

GitFlow ma kilka mocnych stron, dla których wciąż go wybierają:

• Jasna struktura. Każdy branch ma swoją rolę, więc nowa osoba gwałtownie rozumie reguły.
• Wsparcie dla wielu wersji. Możesz utrzymywać stare wydania i łatać je niezależnie.
• Izolacja niedokończonych funkcji. Kod w trakcie pracy nie trafia do głównej linii.
• Kontrolowane wydania. Etap release daje czas na testy i stabilizację.
• Czytelna historia. Tagi na main pokazują, co i kiedy trafiło do klientów.

Wady i ryzyka

Model ma też wyraźne minusy, dlatego coraz więcej zespołów go porzuca.

Długo żyjące branche. Im dłużej branch feature jest odizolowany, tym trudniejsze staje się późniejsze scalenie. Konflikty rosną, a integracja przesuwa się na koniec pracy. To tzw. merge hell.

Opóźniona integracja. Błędy wynikające ze współpracy różnych funkcji wychodzą późno. Continuous integration traci sens, gdy kod trafia do wspólnej linii dopiero po kilku dniach.

Złożoność. Pięć typów branchy i trzy kierunki scalania to dużo reguł. Łatwo o pomyłkę, np. zapomnienie o scaleniu hotfixa do develop.

Wolniejsze dostarczanie. Model utrudnia wdrażanie kilka razy dziennie. Etap release i dwa branche główne dodają tarcia.

GitFlow vs trunk-based development

Najważniejsze porównanie dotyczy dziś GitFlow vs trunk-based. To dwa skrajnie różne podejścia do zarządzania branchami.

W trunk-based development wszyscy programiści pracują na jednym głównym branchu, zwanym trunk (zwykle main). jeżeli używają branchy, są one bardzo krótkie, najlepiej do jednego dnia. Zmiany scalasz do głównej linii często, choćby kilka razy dziennie.

Cecha	GitFlow	Trunk-based
Branche długożyjące	main, develop	tylko main
Czas życia brancha funkcji	dni lub tygodnie	godziny, maksymalnie 1-2 dni
Częstotliwość integracji	rzadka	wielokrotnie dziennie
Wydania	cykliczne, z branchem release	ciągłe lub z krótkiego brancha release
Niedokończone funkcje	w osobnym branchu	ukryte za feature flagami
Ryzyko konfliktów	wysokie	niskie
Złożoność procesu	wysoka	niska
Wymagania wobec CI/testów	umiarkowane	bardzo wysokie

Trunk-based wymaga dojrzałej automatyzacji. Bez solidnych testów automatycznych i szybkiego CI częste scalanie do głównej linii jest ryzykowne. Potrzebujesz też feature flag, czyli przełączników, które pozwalają wdrożyć niedokończony kod na produkcję, ale go nie aktywować.

Badania DORA (DevOps Research and Assessment), znane z książki Accelerate, wskazują trunk-based development wśród praktyk powiązanych z wysoką wydajnością dostarczania oprogramowania. Zwracają uwagę na krótkie branche i częstą integrację. To korelacja, nie gwarancja. Samo przejście na trunk-based nie uczyni zespołu szybszym, jeżeli brakuje automatyzacji i kultury testowania.

Inne modele git workflow

GitFlow i trunk-based to nie są jedyne opcje. Warto znać jeszcze dwa inne popularne podejścia.

GitHub Flow

To uproszczony model z jednym branchem głównym. Tworzysz branch z main, otwierasz pull request, przechodzisz review i testy, scalasz i wdrażasz. Nie ma tu develop ani release. Dobrze pasuje do aplikacji webowych wdrażanych często.

GitLab Flow

To rozwinięcie GitHub Flow. Dodaje branche środowiskowe, np. staging i production, lub branche wersji stabilnych. Pomaga zespołom, które nie mogą wdrażać każdej zmiany od razu na produkcję, ale nie potrzebują pełnego GitFlow.

Kiedy wybrać GitFlow?

GitFlow przez cały czas ma sens, gdy:

• wydajesz wersje oprogramowania, np. aplikacje desktopowe, mobilne, biblioteki czy oprogramowanie wbudowane,
• utrzymujesz kilka wersji równolegle, np. klienci korzystają z różnych wydań,
• masz formalny etap testów i zatwierdzania wydania, np. w regulowanych branżach,
• zespół ma mieszany poziom doświadczenia i potrzebuje jasnych reguł,
• nie masz dojrzałego CI/CD i nie możesz bezpiecznie wdrażać zmian ciągle.

Dobrym przykładem jest aplikacja mobilna. Nie wdrożysz poprawki natychmiast, bo każde wydanie przechodzi przez sklep z aplikacjami. Kontrolowany branch release ma tu duży sens.

Kiedy lepiej wybrać coś prostszego?

Rozważ GitHub Flow lub trunk-based, jeśli:

• wdrażasz aplikację webową lub SaaS, w której produkcyjna jest zawsze jedna wersja,
• chcesz wdrażać codziennie lub kilka razy dziennie,
• masz dobrze rozwinięte testy automatyczne i pipeline CI/CD,
• zespół jest mały i zgrany, a komunikacja działa bez dodatkowych procedur,
• chcesz ograniczyć koszty integracji i konflikty przy scalaniu.

Wiele zespołów w polskich software house’ach i startupach pracuje właśnie w ten sposób. Przy produktach webowych narzut GitFlow rzadko się opłaca.

Dobre praktyki zarządzania branchami

Niezależnie od wybranego modelu znajomość kilku zasad poprawia zarządzanie branchami git.

1. Trzymaj branche krótko. Dziel zadania na małe części. Im szybciej scalasz, tym mniej konfliktów.

2. Synchronizuj się często. Regularnie aktualizuj swój branch o zmiany z głównej linii (git merge lub git rebase). Unikniesz dużych niespodzianek na końcu.

3. Stosuj jasne nazwy. Prefiksy feature/, bugfix/, hotfix/ i numer zadania w Jirze ułatwiają orientację i automatyzację.

4. Chroń główne branche. Zablokuj bezpośrednie pushe. Wymagaj pull requestów, review i zielonego CI.

5. Pisz czytelne commity. Dobry opis oszczędza czas przy code review i szukaniu błędów. Wiele zespołów stosuje konwencję Conventional Commits.

6. Usuwaj stare branche. Martwe branche zaśmiecają repozytorium i wprowadzają w błąd. Włącz automatyczne usuwanie po scaleniu.

7. Ustal strategię scalania. Zdecyduj w zespole, czy używasz merge commit, squash czy rebase. Spójność jest ważniejsza niż sam wybór.

8. Udokumentuj workflow. Krótki opis w README lub CONTRIBUTING.md oszczędzi nowym osobom wielu pytań.

Merge, squash czy rebase?

W GitFlow tradycyjnie stosuje się merge z flagą –no-ff, bo zachowuje strukturę historii. W praktyce zespoły często łączą podejścia:

• merge commit zachowuje pełną historię i pokazuje, kiedy dana funkcja weszła do linii głównej,
• squash merge zamienia cały branch w jeden commit, co daje czystą historię, ale gubi szczegóły,
• rebase układa commity liniowo, ale przepisuje historię. Nie stosuj go na branchach współdzielonych z innymi.

Nie ma jednej poprawnej odpowiedzi. Liczy się, żeby zespół używał tej samej strategii i rozumiał jej konsekwencje.

Jak wdrożyć GitFlow w zespole

Jeśli zdecydowałeś/-aś się na GitFlow, wprowadzaj go krok po kroku:

1. Ustal nazwy branchy i reguły scalania. Zapisz je w dokumentacji.
2. Utwórz branch develop z aktualnego main i ustaw go jako domyślny w repozytorium, jeżeli zespół tak woli.
3. Skonfiguruj ochronę branchy w platformie, z którą pracujecie.
4. Podepnij CI do develop, release i main, żeby każdy merge uruchamiał testy.
5. Przeprowadź warsztat z zespołem na przykładowym repozytorium. Przećwiczcie feature, release i hotfix.
6. Zbieraj feedback po kilku sprintach i dostosuj reguły do potrzeb.

Nie musisz stosować modelu dosłownie. Wiele zespołów upraszcza go, np. rezygnuje z osobnych branchy release przy małych wydaniach.

Podsumowanie

GitFlow to dojrzały i przewidywalny model git workflow, który świetnie sprawdza się przy wydawaniu systemu w cyklach i utrzymywaniu wielu wersji. Jego największe wady to złożoność i późna integracja. W projektach webowych z dobrym CI/CD prostsze podejścia, takie jak GitHub Flow czy trunk-based development, zwykle działają lepiej.

Wybór modelu powinien wynikać z tego, jak wydajesz oprogramowanie, jak dojrzałą masz automatyzację i jak duży jest zespół. Nie z mody ani przyzwyczajeń.