Git flow – sposób pracy z gitem

git flow

W dwóch poprzednich wpisach skupiliśmy się na systemach kontroli wersji i jeszcze dokładniej przyjrzeliśmy się gitowi. Dzięki nim zdobyłeś podstawową wiedzę na temat zarządzania wersją oprogramowania. Na końcu poprzedniego artykułu zachęcałem Cię do dalszego zgłębiania wiedzy. Postanowiłem jednak rozszerzyć serię o dodatkowy post, w którym opiszę co kryje się za tajemniczym terminem git flow.

Zanim jednak przejdziemy do sedna, omówmy klasyczną sytuację. Rozpoczynasz jednoosobowy projekt. Dzięki poprzednim artykułom wiesz, że warto stosować kontrolę wersji. Tworzysz więc repo, mastera, developa i zaczynasz rozwijać oprogramowanie. Pracując jako one-man army nie potrzeba wprowadzać dodatkowych usprawnień, bo Ty panujesz nad całym bałaganem – sam go też tworzysz. Wyobraź sobie jednak, że Twój projekt odniósł ogromny sukces komercyjny i zatrudniłeś 20 osobowy zespół do rozwijania swojej aplikacji. Stosowane wcześniej podejście do zarządzania kodem nie będzie zbyt rozsądne. Co więcej sprawi, że w projekcie będzie panował chaos – wyobraź sobie 20 developerów commitujących równolegle na developa. Jak temu zapobiec? A stosując git flow właśnie.

Co to ten git flow?

No dobrze, to czym on w ogóle jest ? – zapytasz. To sposób zarządzania branchami i kodem tak, aby zoptymalizować ich używanie, żeby programistom, testerom, dev-opsom i wszystkim innym żyło się lepiej. Brzmi ciekawie? No to zajrzyjmy w głąb tego podejścia.

Założenia

fizyka

Git flow jest proste i genialne zarazem. Wprowadza on sposób na organizację pracy na wszystkich etapach rozwoju oprogramowania. Robi to przez dedykowane do tego branche:

  • Feature
  • Release
  • Hotfix

Oczywiście develop i master także istnieją i są wykorzystywane zgodnie z ich przeznaczeniem. Master przechowuje kod produkcyjny, natomiast develop kod aspirujący do stania się produkcyjnym, to znaczy zawierającym zmiany scalone, z innych branchy z gotowymi funkcjonalnościami do testowania.

Zastanówmy się więc do czego wykorzystuje się pozostałe branche.

Feature branch

Tworzy się go z developa. To na nim programiści wprowadzają wszystkie zmiany związane z funkcjonalnością nad jaką dane jest im aktualnie pracować. Zależnie od potrzeb zadania lub projektu, mogą pracować na nim pojedyncze osoby lub całe zespoły. Każdy feature branch powinien zawierać wszystkie modyfikacje, które lądują na developa, wskazane są więc częste merge. Scalenie kodu do developa powinno nastąpić w momencie, w którym funkcjonalność jest ukończona- działa, kod się kompiluje i nie ma błędów, przynajmniej według programisty.

Release branch

Wiesz czym jest feature branch i jak z niego korzystać we współpracy z developem. W każdym projekcie rozwija się kolejne funkcjonalności, te mergowane są do developa. Przychodzi jednak czas, aby wydać nowe wersję, która musi zostać ostatecznie przetestowana. W trakcie takiej weryfikacji może się zdarzyć, że pojawią się błędy, które trzeba poprawić. Nie ma problemu, tylko gdzie? Na developie nie powinno się commitować takich rzeczy, feature branch uruchomił by cały proces mergowania. W przypadku, gdyby błąd został znaleziony np. miesiąc po oddaniu zmian, rozwiązywanie konfliktów mogłoby być czasochłonne i frustrujące. To co? Może master? Nie muszę chyba tłumaczyć, że to kiepski pomysł 🙂 Pozostaje ostania opcja – stworzyć nowy branch – Release branch. To na nim poprawiane będą wszystkie bugi znalezione przed oddaniem nowej wersji. Tutaj nie powinieneś rozwijać nowych funkcjonalności ani refaktoryzować aplikacji – ten branch służy do naprawiania i tylko do tego.

No dobrze wszystko zrobione, błędy poprawione, release się udał, co dalej? W takim wypadku aktualizujemy mastera oraz developa. Do obu z nich robimy merge z release brancha. Do mastera dodatkowo dołączany jest tag z aktualnym numerem wersji oprogramowania, będącego na produkcji.

Hotfix branch

bug

W tym miejscu moglibyśmy zabrać się za podsumowanie… gdyby kod pisały maszyny. Jeśli czytasz to w czasach, gdy robią to już roboty, to artykuł powstał w czasach, kiedy tak nie było 🙂 Co z tego wynika? W aplikacji, nawet przetestowanej mogą pojawić się błędy, które znajdą końcowi odbiorcy na już wdrożonej wersji. W takim momencie czas działa na niekorzyść zespołu, więc problem trzeba naprawić tak szybko jak to tylko możliwe. Do takich celów powstała koncepcja branchy hotfix. Na nich naprawiane są błędy występujące na produkcji. Naturalne jest więc to, że tworzy się go z mastera. Po udanej poprawce zmiany, merguje się też do developa i pozostałych branchy.

Jak widzisz git flow rozwiązuje problemy organizacji kodu w kluczowych etapach projektu:

  • Rozwijaniu
  • Testowaniu
  • Wdrażaniu
  • Wsparciu (support)

Jako przykład poprawnego wykorzystania pełni możliwości git flow zamieszczam grafikę ze strony pomysłodawcy całego podejścia, prezentującą cały proces jaki zachodzi w systemie kontroli wersji pomiędzy kolejnymi wydaniami aplikacji:

git flow
źródło: https://nvie.com

Wady git flow

Git flow jak wszystko ma też swoje wady. Na różnych blogach autorzy wymieniają takie wady:

  1. Nieporządek w historii commitów

Nie miałem takich doświadczeń w pracy z git flow. Inni programiście twierdzą jednak, że w przypadku pracy w dużych zespołach historia commitów bywa mocno skomplikowana i trudna do analizy. Natrafiłem nawet na określenie, porównujące ją do Guitar Hero. Według mnie autor ma rację, jednak uważam też, że to jest naturalna kolej rzeczy. Duża ilość branchy powoduje potrzebę wykonywania częstych merge’y, co skutkuje rozrośniętą historią commitów. Zastanawiając się nad decyzją o zastosowaniu git flow w swoim projekcie pomyśl o tym, co jest dla Ciebie ważniejsze? Segregacja kodu zgodnie z jego przeznaczeniem i organizacja procesów wytwarzania softu, czy porządek w drzewie commitów. Obie są ważne, więc decyzja zawsze na końcu zależy od potrzeb w konkretnym projekcie.

  1. Podział na master i develop jest niepotrzebny

Z tym zarzutem nie zgadzam się jeszcze bardziej. Według autora develop w pewnym momencie osiągnie stan, w którym będzie możliwe wykonanie deployu, dlatego wtedy można dodać tam tag, wrzucić kod na produkcję. W rezultacie takiego podejścia master jest niepotrzebny. Osobiście jednak uważam, że jeśli zależy nam na segregacji kodu za pomocą branchy, to podział na mastera i developa ma sens. Drugi z nich charakteryzuje się częstą zmiennością i tym, że może czasem nie działać. Jego zadaniem jest zbieranie kodu z feature branchy. Po co komplikować sprawę obciążając go odpowiedzialnością za deploy? W momencie, gdy kod na tym branchu ustabilizuje się, można wykonać deploy, a kod odpowiadający temu na produkcji trzymać na masterze. Dzięki temu dysponować będziemy zawsze działającą wersją, której nie popsuje żaden nieprzemyślany commit.

Narzędzia do pracy z git flow

Git flow to metodologia, czy określając huczniej filozofia zarządzania repozytorium. Nie spotkałem się więc z wieloma narzędziami współpracującymi z nią. Dla osób korzystających z gita z użyciem konsoli, warte rozważenia będzie zainstalowanie rozszerzeń ułatwiających pracę z git flow. Będą one jednak pomocne głównie w organizacji folderów i branchy zgodnie z metodologią, redukując ilość komend jakie trzeba wywołać do uzyskania tego samego efektu. Resztę trzeba zrobić samemu.

Podsumowanie

I to by było na tyle w temacie git flow. Z dzisiejszego wpisu dowiedziałeś się czym w ogóle jest, jakie są jego podstawowe założenia i wady. Przeczytałeś też o narzędziach, z których możesz skorzystać jeśli używasz konsoli. Warto jednak pamiętać o tym, że to co tu przedstawiłem to jedynie model, schemat, od którego warto zacząć. We wcześniejszych artykułach wspominałem, że każdy zespół z czasem wypracowuje swoje zasady- poeksperymentuj i Ty. Git flow daje duże możliwości, jednak o tym przekonasz się gdy najpierw opanujesz podstawy – gita, do czego bardzo Cię zachęcam. Wspominałem już, że te artykuły moją być dla Ciebie iskrą, która pozwoli Ci zacząć i zachęci do dalszego zgłębiania tematu. Daj znać w komentarzy, czy spełniły swoje zadanie, czy wyniosłeś z nich coś nowego i przydatnego? Jeśli tak, to nie zapomnij podzielić się tym w social media, żeby inni także mogli z tego skorzystać. Z góry dziękuję.

Please follow and like us:

Dodaj komentarz

This site uses Akismet to reduce spam. Learn how your comment data is processed.