Git flow – wydajny system zarządzania gałęziami w Git

Dzięki wydajnemu zarządzaniu gałęziami w Gicie powstało wiele różnych schematów pracy opartych o rozgałęzienie kodu – najpopularniejszym z nich jest git flow.

W ramach tego materiału dowiesz się jak pracować z Gitem i praktycznie wykorzystać git flow w codziennej pracy.

Git flow – wprowadzenie

Z tego materiału dowiesz się:

  • Na czym polega mechanizm git flow?
  • Jak korzystając z wbudowanych gałęzi w git (ang. git branch) oraz systemu tagów (ang. git tag)
    można stworzyć wydajny system zarządzania zmianami w kodzie?
Systemy kontroli wersji kodu źródłowego – Git

Git tutorial

Systemy kontroli wersji odpowiedzialne są za śledzenie wszystkich zmian dokonywanych w plikach. Za ich pomocą można podejrzeć wcześniej dokonane zmiany oraz, w razie potrzeby, powrócić do starszej wersji pliku. Dzięki nim można również sprawdzić kto i kiedy dokonał tych zmian.

Obecnie Git jest najpopularniejszym rozproszonym systemem kontroli wersji. System pierwotnie został stworzony przez Linusa Torvalds jako narzędzie wspomagające rozwój jądra Linux i od tego czasu sukcesywnie zyskuje na popularności.
Git oficjalnie został wydany w 2005 roku i obecnie jest rozwijany na zasadach wolnej licencji – a co za tym idzie, swobodnie możemy go wykorzystywać w naszych projektach.

W ramach tego materiału zajmiemy się przede wszystkim wykorzystaniem git flow – natomiast kompletny tutorial Git znajdziesz poniżej.

➡ ZOBACZ 👉: Git tutorial | stash, rebase, commit, merge, checkout, push i clone

Git install – instalacja Git

Jeżeli nie masz jeszcze gita zainstalowanego lokalnie – szybko możesz to nadrobić.
W poniższym materiale znajdziesz instrukcję, jak można to zrobić.

➡ ZOBACZ 👉: Install Git – Instalacja Git, Windows, Ubuntu – Bash, GUI

Git Tag – Wykorzystanie tagów w Git

Dzięki mechanizmowi tagowania i operacji git tag – możemy w wydajny sposób oznaczyć i później pobrać praktycznie dowolny punkt w historii naszych zmian.

Jeżeli chcesz dowiedzieć się, jak działają tagi w git, w poniższym materiale znajdziesz instrukcję, jak można to zrobić.

➡ ZOBACZ 👉: Git tag – tagowanie w git, add, push, checkout

Git flow

Wprowadzenie lekkiego i szybkiego modelu zarządzania gałęziami w Gicie przyczyniło się do powstania wielu różnych schematów pracy, opartych o rozgałęzianie kodu.

Częścią wspólną tych modeli jest podział na gałęzie długotrwałe oraz krótkotrwałe.

  • Na gałęziach długotrwałych utrzymywany jest stabilny kod, który zmienia się raczej rzadko.
  • Natomiast gałęzie krótkotrwałe przeznaczone są na rozwój aplikacji oraz naprawę błędów.
    Kod powstały w gałęziach krótkotrwałych jest przenoszony podczas mergu do gałęzi długotrwałych.

Jednym z najpopularniejszych modeli jest Git-flow, którego założenia przedstawione są poniżej.

Git-Flow

Git-Flow

Git flow – branch Master

Na gałęzi master trzymany jest jedynie stabilny kod aplikacji. Tutaj nie powinno być zwykłych commitów ze zmianami kodu, a jedynie commity mergujące z gałęzi hotfix oraz release.
Każda kolejna wydana wersja aplikacji oznaczana jest nowym tagiem z wersją. Dzięki takiemu podejściu w dowolnym momencie rozwoju aplikacji, mamy do dyspozycji stabilną wersję kodu. Można ją bezpiecznie zaprezentować klientowi oraz, w razie potrzeby, nanieść niecierpiące zwłoki poprawki.

Git flow – branch HotFix

HotFix jest zawsze „wystrzeliwany” z gałęzi master. Po naprawie błędu taką gałąź należy zmergować do master. Poprawkę można również dodać do obecnie rozwijanej gałęzi develop, jeżeli chcemy, żeby już teraz została poprawiona.
W tym samym czasie może być kilka gałęzi typu HotFix.

Git flow – branch Develop

Jest to główna gałąź rozwojowa aplikacji. Kod, który zawiera, może być chwilami niestabilny. Tu spotykają się i łączą wszystkie niezależnie rozwijane funkcjonalności. Gałąź develop wystrzeliwana jest z gałęzi master po wydaniu nowej wersji.

Git flow – branch Feature

Wszystkie większe funkcjonalności powinny być rozwijane na osobnych gałęziach. Dzięki temu można je niezależnie rozwijać, nie przeszkadzając jednocześnie w rozwoju innych funkcjonalności. Daje to również możliwość wypuszczenia nowej wersji aplikacji, bez konieczności czekania aż wszystkie rozwijane rzeczy zostaną ukończone. Po zakończeniu prac kod jest mergowany do gałęzi develop, gdzie testowany jest razem z innymi funkcjonalnościami.

Git flow – branch Release

Po zakończeniu pewnego okresu rozwoju aplikacji, z gałęzi develop wystrzeliwana jest nowa gałąź, tak zwany release candidate.
Na tym branchu nie są już rozwijane żadne nowe funkcjonalności. Jego celem jest ustabilizowanie obecnie wytworzonego kodu przed ostatecznym mergem do master.

Git flow – A nie da się prościej? 🤔

A da się! 😉 Można np. skorzystać z rozszerzenia przygotowanego przez Vincenta Driessen.

Git-flow to zbiór rozszerzeń Gita dostarczających wysokopoziomowe operacje na repozytorium, wspierając strategię rozgałęziania git flow – czyli to wszystko, co przed chwilą robiliśmy ręcznie.

Git flow – Instalacja

macOS/Homebrew

brew install git-flow-avh

Linux

apt-get install git-flow

Windows (Cygwin)

wget -q -O - --no-check-certificate https://raw.github.com/petervanderdoes/
gitflow-avh/develop/contrib/gitflow-installer.sh install stable | bash

Git flow – inicjalizacja i konfiguracja

Przygodę z git-flow rozpoczynamy od jego zainicjalizowania go w już istniejącym repozytorium Git:

git flow init

Odpowiadamy tutaj na kilka podstawowych pytań konfiguracyjnych – jednak po dotychczasowej lekturze tego wpisu nie powinno to już stanowić problemu! 😉

Git flow init

Git flow – nowa funkcjonalność 🆕

Żeby rozpocząć pracę nad nową funkcjonalnością, wystarczy jedna prosta komenda:

git flow feature start <feature-name>

I cała magia git flow dzieje się dla nas automatycznie:

  • Na bazie gałęzi rozwojowej (develop) powstaje nowy branch feature/MyNewFeature,
  • a my – jesteśmy przełączani na nowo powstałą gałąź.

Git flow feature

Dla nas pozostaje już tylko wprowadzić zmiany w kodzie i zrobić commit do aktualnego brancha.

Po zakończeniu prac – kończymy naszą funkcjonalność komendą:

git flow feature finish MyNewFeature

Tym razem silnik git-flow wykona takie akcje:

  • zmerguje branch z naszą funkcjonalnością do brancha develop,
  • usunie branch rozwojowy
  • i przełączy nas na gałąź develop.

Git flow feature finish

Jeżeli współpracujemy z innymi osobami (co może być dość częstym przypadkiem…) to mamy jeszcze możliwość opublikowania naszej zmiany:

git flow feature publish <feature-name>

oraz jej późniejszego pobrania:

git flow feature pull origin <feature-name>

Git flow – nowe wydanie

Kończymy pracę nad nowymi funkcjonalnościami i chcemy wydać nową wersję aplikacji – i tym razem możemy skorzystać z git-flow:

git flow release start <release-name>

Metoda git flow release start – utworzy i przełączy nas na nowego brancha – w tym wypadku: release/Release1.

Git flow release start

Będąc na branchu dedykowanym dla nowego wydania możemy podbić wersję naszej aplikacji oraz ustabilizować wersję – czyli dodać nowe commity do tego brancha, które wprowadzają poprawki, ale już nienowe funkcjonalności.

Po zakończeniu poprawek i akceptacji wersji możemy ją zakończyć – czyli wydać.

git flow release finish Release1

Git flow release finish

I tym razem silnik git-flow wykona za nas dużo powtarzalnych zadań:

  • Zmergował branch z naszą wersją (release/Release1) do brancha głównego (master)
  • Dodał tag (Release1) do nowej wersji na gałęzi master
  • Wersja oznaczona nowym tagiem została zmergowana do gałęzi develop (robimy to, żeby przenieść ewentualne poprawki, które pojawiły się podczas stabilizacji wersji)
  • Usunął niepotrzebną już gałąź z nową wersją
  • I przełączył nas na gałąź develop – gdzie możemy rozpocząć już prace nad nową zmianą!

Całkiem sporo akcji jak na jedną komendę 😉

Git flow release logs

Jeżeli pracujemy w zespole lub chcemy przechować nasze zmiany na zdalnym repozytorium – taką wersję w międzyczasie możemy jeszcze opublikować:

git flow release publish <release-name>

lub śledzić już istniejącą zmianę:

git flow release track <release-name>

Git flow – poprawki

Zostały nam jeszcze do omówienia poprawki, które zostaną wychwycone na wersji produkcyjnej.
I tym razem możemy posłużyć się silnikiem git-flow. Ta operacja przebiega jednak analogicznie jak poprzednie akcje – dlatego zostawię Cię z tymi dwiema komendami:

git flow hotfix start Fix1

git flow hotfix finish Fix1

Git flow – podsumowanie

W ramach tego materiału przećwiczyliśmy wykorzystanie git flow oraz rozszerzenia git-flow w naszych projektach. Jest to potężne narzędzie, które potrafi ogarnąć chaos z wydawaniem wersji w niejednym zespole.

Jeżeli chcesz kontynuować swoją przygodę z gitem – to zapraszam do dodatkowych materiałów:

➡ ZOBACZ 👉: Git tutorial | stash, rebase, commit, merge, checkout, push i clone


20+ BONUSOWYCH materiałów z programowania

e-book – „8 rzeczy, które musisz wiedzieć, żeby dostać pracę jako programista”,
e-book – „Java Cheat Sheet”,
checklista – „Pytania rekrutacyjne”
i wiele, wiele wiecej!

Jak zostać programistą

2 komentarze
Share:

2 Comments

  1. michaldo says:

    Całkiem fajny wpis.

    Brakuje strzałki od 'release’ do 'develop’. „It’s important to merge back into develop because critical updates may have been added to the release branch and they need to be accessible to new features.” https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow.

    Warto też odnieść się do: „Gitflow has fallen in popularity in favor of trunk-based workflows, which are now considered best practices for modern continuous software development and DevOps practices.”

    1. Tomek says:

      Cześć michaldo.
      1. Zdecydowanie – jak mamy jakieś fixy i chcemy, żeby były w gałęzi rozwojowej, to trzeba je przenieść
      2. To wszystko zależy od naszych potrzeb. Git-flow jest dość „ciężki” i nie zawsze jest najlepszym wyjściem. Jednak całkiem nieźle się sprawdza jak mamy duży zespół i bardzo wymagający/niestabilny projekt.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *