Trzy najpopularniejsze strategie branczowania
Ilu programistów traci swój cenny czas na merdżowaniu kodu, zamiast skupiać się na tworzeniu nowych funkcjonalności? Sporo. Grube legiony developerów postrzega gita jako przeszkodę, a nie jako pomocne narzędzie. By zmniejszyć tę ilość, przedstawiam trzy najpopularniejsze strategie branczowania. Poznaj je i zrozum, a następnie wyłuskaj z każdej to, co jest najlepsze dla Ciebie i Twojego projektu. Miej na uwadze, że każda z nich ma swoje wady i zalety. W pewnych sytuacjach sprawdzi się jedna, a do innych się nie nada.
GitFlow
Najpopularniejsze, a na pewno najbardziej medialne podejście do organizacji gałęzi. Preferuje ono tworzenie osobnego brancza w zależności, czy pracujemy nad nowym ficzerem, rilisem, czy łatamy buga. W teorii wygląda bardzo obiecująco i niczym syrena, swym pięknym śpiewem przyciąga programistów. Część z nich zaś topi się w morzu branczy. Jak nie utonąć? Poznaj założenia, wady i zalety tego podejścia oraz zachowaj zdrowy rozsądek.
Kiedy używać
- Gdy kod jest już na produkcji i wymaga stabilnego rozwoju.
- Gdy wszyscy członkowie zespołu rozumieją GitFlow.
- Gdy wiesz co mają zawierać poszczególne wydania i kiedy mają być wydane.
Kiedy nie używać
- Gdy projekt na wczesnym etapie życia.
- Gdy wykonywane są duże zmiany architektoniczne.
- Gdy nieznane są zależności pomiędzy poszczególnymi zadaniami.
- Gdy jest stosowany źle i przybiera jedną z chorobliwych postaci opisanych w poprzednim poście.
Trunk based development
Podejście numer dwa. Mniej skomplikowane. Nie wymusza tworzenia nadmiarowych branczy. Cały kod ląduje w głównej gałęzi. Brancza odbijasz dopiero, gdy nadchodzi czas rilisa. Istnieje on w celu stabilizacji i zamrożenia konkretnej wersji. Dzięki temu podejściu minimalizujesz czas potrzebny na merdże oraz trzymasz otwartą furtkę, by móc poprawić krytyczny błąd w opublikowanej wersji.
Kiedy używać
- W początkowej fazie życia aplikacji.
- Gdy program wymaga dynamicznego rozwoju.
- Gdy nie chcesz trzymać się sztywnych zasad GitFlow.
Kiedy nie używać
- Kiedy kod jest na produkcji i wymaga bardzo stabilnego, planowanego rozwoju.
- Kiedy poszczególne funkcjonalności mogą zostać napisane teraz, ale ich wdrożenie będzie odbywać się w przyszłości.
Master only
Założenie jest proste, chociaż trochę kontrowersyjne. Wszystko leci do mastera. Zawsze. Nie bawimy się w ficzer-brancze, rilis-brancze, czy inne cuda. Dzięki takiemu podejściu nie doświadczysz nadmiarowego merdża. Dodatkowo ten sposób wymusza stosowanie praktyk zgodnych z procesem ciągłego wdrażania. Czyli używanie rzeczy jak feature switche, auto release notes, czy canary deployment. Jest to oczywiście bardzo trudne do wdrożenia, ale to czyż nie brzmi zachęcająco.
Kiedy używać
- W początkowej fazie życia aplikacji, biorąc pod uwagę, że CD będzie cały czas rozwijany.
- Gdy konieczne jest częste i szybkie wdrażanie nowych wersji.
- Gdy masz dobrze skonfigurowany Continous Deployment.
Kiedy nie używać
- Gdy zespół jest niedoświadczony.
- Gdy wymagana jest bardzo duża stabilność aplikacji.
- Gdy konfiguracja CI nie jest wyśmienita.
Zdrowy rozsądek
Co zatem wybrać? To zależy. Wszystkie podejścia mają plusy i minusy. Nic nie zastąpi zdrowego rozsądku, wzmocnionego chwilą namysłu nad tym, co jest potrzebne. Miej na uwadze, że branczowanie to tylko jedna z wielu składowych całego procesu wytwarzania oprogramowania. Powinno być dopasowane do zespołu i projektu w taki sposób by było niezauważalne w codziennej pracy. Jeżeli merdże stają się tematem rozmów lub są dodawane do backlogu to znak, że coś się dzieje. A Ty powinieneś zmienić proces!
A może Ty masz coś do powiedzenia na ten temat? Jeżeli tak to najserdeczniej zapraszam do dyskusji.
3 Komentarze
Zbigniew · 2018-07-12 o 13:11
Jak robić code review w przypadku Trunk based development lub Master only? W GitFlow zwykle robię pull request z feature brancza do developa.
Jerzy Wickowski · 2018-07-12 o 16:15
Cześć Zbigniew.
Sprawa jest prostsza niż się początkowo może wydawać. Opisałem tutaj pewne podejścia do zarządzania gałęziami w projektach. Jednak miej na uwadze, że tyczy to się tylko branczy wysłanych do remota. Nic nie stoi na przeszkodzie, a nawet jest to wskazane, by w lokalnym repozytorium tworzyć krótkożyjące odgałęzienia dla zadań nad którymi właśnie pracujesz. Na merdżu jest dobre miejsce na review.
I jeszcze ważnym aspektem jest zrozumienie, że to co na masterze nie musi działać, ale równocześnie nie może nic psuć. Przykładowo, gdy dodasz jakąś metodę, która jeszcze działa niepoprawnie, ale nie jest nigdzie wywoływana to nic nie powinno stać na przeszkodzie, aby ją opublikować.
Artur · 2022-06-29 o 16:55
Na bieżąco, po prostu wyrzucić standardowy code review do kosza przechodząc na Mob Programming, dokoptowując do tego TDD (de facto TBD poprzez swoją konstrukcję mocno promuje TDD) oraz #NoEstimates co staje się możliwe po wciągnięciu Product Ownerów w proces wytwarzania oprogramowania.