W tym poście dowiesz się, czym jest podejście GitFlow do wytwarzania kodu. Zrozumiesz, jakie to ma znaczenie np. w skalowaniu rozwiązania, nad którym pracują zespoły.
Cześć :), trochę się nie widzieliśmy z mojej winy, ale postaram się nadrobić to dzisiejszym postem i kolejnymi.
W moim ostatnim poście tłumaczyłam, czym jest kontrola wersji, ale przyda się też wiedza o środowiskach. Przysłuchując się programistom, nieraz pewnie rzuciły Ci się w uszy takie hasła jak mergować, przejrzeć PRkę/MRkę, czy tajemniczy feature branch.
Wszystkie te terminy pochodzą od sposobu pracy z kodem, nazywanego GitFlow, o którym Ci dzisiaj opowiem. To jeden z najpopularniejszych systemów pracy i taka trochę metoda na "porządek w chaosie", który pomaga zespołom ogarnąć różne wersje kodu. Nie martw się, zaczniemy od podstaw, a wszystko wyjaśnię krok po kroku. Gotowy, gotowa? No to lecimy! 🚀
Git, co?
Wyobraź sobie, że remontujesz mieszkanie, 1 osoba zajmuje się gładziami, inna malowaniem ścian, glazurnik łazienką, a projektant mebli zdejmuje miary do projektu kuchni. W analogiczny sposób ekipa pracuje nad 1 produktem, zajmując się często kilkoma różnymi funkcjonalnościami (kawałkami projektu/produktu). Aby ogarnąć ten chaos i nie psuć sobie roboty, zespół korzysta z jasno określonych zasad.
Żeby zrozumieć Git Flow, musisz poznać te zasady i dowiedzieć się, czym są branche, które pojawiają się w tym podejściu. Spróbuję opisać to słowo muzycznie.
Aplikacja, z której korzystasz jako użytkownik, znajduje się na środowisku produkcyjnym. W repozytorium jej odpowiednikiem jest master, inaczej nazywany również main'em i jest to oficjalnie wydana wersja na produkcję. Kojarzysz te nieustające prośby o aktualizację, bądź np. o wyłączenie jakiejś kluczowej funkcjonalności, by wymusić na Tobie aktualizację apki na telefonie? Dzieje się to właśnie wtedy, kiedy wydawana jest nowa wersja aplikacji. Wymuszanie aktualizacji jest częste przy zmianach krytycznych, np. łatkach bezpieczeństwa.
Natomiast do prac w okopach developerskich służy jej "klon", często nazywany Developem, znajdujący się na środowisku developerskim. Zatem można powiedzieć, że Develop jest kopią produkcji, która posiada nowe funkcjonalności i poprawki planowane do nowego wydania.
Jak to działa?
Kiedy deweloper pracuje nad nową funkcjonalnością lub poprawia jakiś błąd, zaczyna od utworzenia nowego brancha (czyli odnogi kodu) na Developie. Jest to forma kopii kodu. Nigdy nie pracuje się bezpośrednio na Developie. Często takie branche nazywamy feature branchami, bo tworzy się je pod nowe funkcjonalności lub historyjki użytkownika. Na takim feature branchu programista może spokojnie pracować, bawić się, psuć i nie musi przejmować się, że to, co wytwarza, wpływa na aplikację używaną przez użytkowników, bądź psuje szyki swoim kolegom z zespołu.
W pewnym momencie programista dochodzi do wniosku, iż naprawił błąd lub napisał funkcjonalność zgodnie z wymaganiami. Wtedy wystawia swój kod innym programistom, najczęściej z zespołu produktowego, do przejrzenia. Praktykę tę nazywamy Code Review (CR). Jest to proces, w trakcie którego inni programiści przeglądają kod, dają swoje uwagi, a wnioskujący programista zapoznaje się z nimi i dostosowuje swój kod. Pamiętacie czasy sprzed autozapisu w wordzie? Trzeba było kliknać "zapisz" jeśli nie chcieliśmy stracić wprowadzonych zmian. Tak samo działa praca z kodem. Wszystkie ważne zmiany w trakcie tworzenia kodu i jego poprawkach są zapisywane, czyli commitowane. To bardzo ważny etap w całym procesie wytwarzania oprogramowania. Zapewnia jego jakość i utrzymanie standardów. Po poprawnym przejściu CR zapada decyzja o dołączeniu zmian do najnowszej wersji Developa, co nazywamy mergem. Jeśli pojawią się jakieś konflikty, to trzeba jeszcze popracować z dołączanym feature branchem, a po ich rozwiązaniu można domergować ten kod do Developa.
Aby programiści z zespołu mogli przejść Code Review, programista, który tworzył feature brancha, musi zgłosić go do przeglądu. Wystawia on Pull Request (PRkę) lub Merge Request (MRkę). Każdy zespół i firma mają swoje zasady w CR. Czasem kod potrzebuje dostać 2 okejki od zespołu, by można go było dołączyć do Developa, innym razem to Tech Lead musi dać zgodę (approval).
I tak idzie robota: tworzone są feature branche, później te zmiany są dołączane do Developa. W którymś momencie jest decyzja o przygotowaniu nowej wersji na produkcję. Tworzy się wtedy release brancha i na nim dopracowuje release. Nie raz pewnie zderzyliście się z sytuacją, że release się trochę przeciągnął? W tym czasie rozwiązywane są nowe konflikty, powstają nowe błędy, które zespół musi naprawić, odbywają się re-testy i weryfikacja środowisk. Jak już wszystko jest gotowe, zmiany przenosi się już do mastera/maina - czyli tego głównego kodu, który jest na produkcji.
Tworzony jest nowy tag na mainie - tag releasu x. Praktyka ta ma na celu zapewnienie możliwości cofnięcia się do wersji poprzedniej w razie problemów. Przykładowo: po releasie klienci sklepu e-commerce kupując buty, nie są w stanie zapłacić za swoje towary.
Możecie sobie wyobrazić poruszenie w biznesie, bo firma traci grube tysiące, a nawet miliony. Co robi zespół wtedy? Cofa wersję produkcyjną do wersji poprzedniej, nazywamy to w żargonie robieniem roll-backa, aby biznes nie tracił więcej pieniędzy. Zespół pracuje nad poprawkami na wersji, którą wycofał i ponownie po naprawie błędów wrzuca poprawiony kod na produkcję.
Roll-back to jednak rozwiązanie ostateczne. Najczęściej pracuje się nad błędami krytycznymi bez wycofywania wersji. Takie działanie nazywamy hot-fixem. Czyli prosto z mastera robi się odnogę brancha pod hot-fix, szybko przygotowuje poprawkę i dołącza się ją bezpośrednio do mastera. Potem należy tę poprawkę wgrać do developa po to, by main i develop były "równe".
GitFlow for dummies, czyli mała powtórka
No dobra, ale przynudziłam… ekhm znaczy rozpisałam się. Postaram się powyższe napisać w ultra skrótowej formie, coś jak przepis.
Załóżmy, że robisz aplikację do zamawiania pizzy. Product Owner przyszedł z nową historyjką mówiącą, że użytkownicy chcą móc zamówić swój ulubiony sos do pizzy.
Zaczynasz od developa i stwierdzasz, że trzeba dodać funkcję wyboru sosu.
Tworzysz nowy branch: feature/dodaj-wybór-sosu.
Kodujesz, testujesz, wszystko działa.
Wystawiasz PRkę (Pull Requesta) do kolegów z zespołu.
Przechodzisz Code Review po kilku zmianach i jest zielone światło na merge.
Wracasz z feature/dodaj-wybór-sosu do develop.
Gdy aplikacja jest gotowa na wypuszczenie, tworzysz branch release/v1.0. Tu dopracowujesz ostatnie szczegóły.
Po finalnych testach mergujesz release/v1.0 do main, oznaczasz wersję tagiem (np. v1.0), i... bam! Pizza z sosem wjeżdża na produkcję.
Ups, coś się jednak zepsuło? Tworzysz hotfix/poprawa-sosu, naprawiasz problem i wracasz z nim na main.
Voila! Teraz zamawiasz sos do swojej pizzy bez żadnego problemu.
Dlaczego warto korzystać z Git Flow?
Git Flow to coś jak dobrze zaprojektowana kuchnia – wszystko ma swoje miejsce. Dzięki temu:
Pracujesz w uporządkowany sposób: masz dedykowane branche do nowych funkcji, poprawek i stabilnych wersji. Ułatwia to zapoznanie z kodem dla nowych programistów, tworzy też historię aplikacji.
Unikasz chaosu: wiadomo, co jest stabilne, co można testować, a co jeszcze wymaga pracy.
Każdy wie, co robić: członkowie zespołu wiedzą, na którym branchu powinni pracować i jakie panują zasady pracy z kodem.
Zbyt piękne, aby było prawdziwe. Gdzie haczyk?
Jak to mówią, "nie ma róży bez kolców". Git Flow ma kilka wad, szczególnie w bardziej dynamicznych projektach lub bardziej złożonych:
Jest czasochłonny: cała ta zabawa z branchami (tworzenie, mergowanie, testowanie) zajmuje sporo czasu. To przekłada się na częstotliwość releasów.
Konflikty merge’ów: jeśli kilku programistów pracuje nad różnymi feature’ami, to szansa na konflikty przy scalaniu kodu rośnie. A im więcej programistów, tym więcej konfliktów, i czas wydań się wydłuża. Łapiesz, do czego dążę?
Nie nadaje się do szybkich wdrożeń: w erze DevOps i ciągłego wdrażania (CI/CD) GitFlow może być jak hamulec ręczny.
No to dla kogo jest ten cały Git Flow?
Git Flow sprawdzi się w projektach, które mają:
Dłuższe cykle wydawnicze (np. raz na kilka tygodni).
Zespół, który pracuje nad wieloma funkcjami jednocześnie.
Dużą potrzebę stabilności (np. w bankowości, medycynie czy projektach legacy).
Jeśli Twój projekt wymaga częstych, szybkich wdrożeń, może warto rozważyć inne podejście, np. Trunk-Based Development (ale to temat na inny artykuł 😉).
Podsumowanie
Git Flow to solidny fundament pracy zespołowej, szczególnie w bardziej złożonych projektach. Pomaga ogarnąć chaos i daje jasne zasady, które branche są do czego. Ale pamiętaj – nie jest to rozwiązanie idealne dla każdego. Zanim w Twoim produkcie zdecydujecie się na GitFlow, trzeba pochylić się nad tym, jak wygląda Twój projekt i jak pracuje Twój zespół.
Masz pytania? Daj znać w komentarzu! Chętnie pomogę albo przynajmniej pocieszę, gdy wpadniesz na swój pierwszy merge conflict (hłe, hłe).
Comments