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.