Podstawy

Na samym początku przybliżę Ci wyjaśnienie podstawowych gałęzi w GitFlow:

• master (lub main) – Zawsze zawiera stabilną wersję kodu, która działa bez błędów i jest gotowa do wdrożenia na produkcję.
• develop – To jest gałąź, w której pracujesz nad nowymi rzeczami tworząc nowe funkcje oraz testujesz coś nowego, wszystko wtedy ląduje w develop.
• feature – Na tej gałęzi pracujesz nad wszelką nową funkcjonalnością. Zmiany z niej również lecą na develop.
• release – Kiedy wszystkie nowe funkcje są gotowe, tworzysz gałąź release, która jest ostatnim momentem przed wypuszczeniem wersji na produkcję. Możesz wykonać tu ostatnie poprawki oraz testy. Po zakończeniu prac, łączysz tę gałąź z master (czyli wysyłasz wersję na produkcję) i z powrotem z develop, celem wyrównania zmian na obu gałęziach.
• hotfix – W przypadku błędów na produkcji, tworzysz poprawkę z gałęzi master, bo stąd jest kod który działa na produkcji. Po jego naprawie łączysz hotfix, z master (żeby wersja produkcyjna była naprawiona) oraz z develop (żeby te poprawki były też w wersji roboczej).

Rozpoczęcie pracy z gitflow

Na samym początku musimy zainicjować w naszym obszarze roboczym obsługę tego naprawdę przydatnego narzędzia po przez wykonanie polecenia:

git flow init

Tylko dla tag należy dodać przedrostek: v , pozostałe nazwy gałęzi pozostawiamy domyślne. 

Proces pracy z GitFlow

1. Tworzenie Feature

Służy do utworzenia gałęzi z nową funkcjonalnością. Cechuje się tym że:

• Jest tworzona z gałęzi develop,
• Wszelkie zmiany zostaną wprowadzone do gałęzi develop,

Tworzymy nasz feature po przez:

git flow feature start name

W tym momencie możemy wykonać wszelkie prace oraz commity, należy pamiętać by po zakończeniu pracy zamknąć gałąź po przez:

git flow feature finish name

Przykłady nazewnictwa naszego "name":

• feature/login-page – nowa funkcjonalność dotycząca strony logowania,
• feature/#0001 – numer taska,

2. Tworzenie Hotfix-ów

Służy do naprawy krytycznych błędów w wersji produkcyjnej. Cechuje się tym że:

• Jest tworzony z gałęzi master,
• Wszelkie zmiany zostaną wprowadzone do gałęzi develop oraz master,

Tworzymy nasz release po przez:

git flow hotfix start name

Po naprawieniu błędu, należy połączyć gałąź hotfix z master i develop:

git flow hotfix finish name

Przykłady nazewnictwa naszego "name":

• hotfix/1.0.1 – szybka naprawa błędu w wersji 1.0.0,
• hotfix/2.1.1 – naprawa błędu w wersji 2.1.0,
• hotfix/crash-on-login – jeśli naprawiamy specyficzny problem, np. awarię przy logowaniu,

3. Wydanie Release

Służy do przygotowania nowego wydania aplikacji. Cechuje się tym że:

• Jest tworzona z gałęzi develop,
• Wszelkie zmiany zostaną wprowadzone do gałęzi develop oraz master,

Tworzymy i nasz release po przez:

git flow release start name
git flow release publish name

W tym momencie możemy przeprowadzić ostateczne testy, poprawki kodu przed wydaniem. Po zakończeniu pracy nad wydaniem, należy połączyć gałąź z master i develop za pomocą:

git flow release finish name

Przykłady nazewnictwa naszego "name":

• release/1.0.0 – pierwsze wydanie aplikacji,
• release/2.1.0 – nowa wersja z aktualizacjami funkcji,
• release/3.0.0 – większa wersja aplikacji (np. zmiany w architekturze lub nowy zestaw funkcji),

Nazywanie commitów

Z kolei tworzenie samych opisów, bardzo ciekawie opisuje artykuł na highlab.pl/conventional-commits (poniżej mała ściągawka)

docs: add short circuit to hook example (#665)
fix(cli): allow argv to be overridden in bootstrap (#621)
tests(ED-439): add tests for Modal component
styles: format code with new prettier config

Jak i samą konwencję:

feat – nowa funkcjonalność
fix – poprawka do istniejącej funkcjonalności
docs – zmiany tylko w dokumentacji
chore – zmiany które nie mają wpływu z zawartość kodu źródłowego czy testów (np. aktualizacja paczek)
refactor – zmiany, które nie są zarówno poprawkami jak i nowymi funkcjonalnościami
tests – wszystko co związane z testami (dodawanie, edycja)
perf – zmiany w kodzie usprawniające wydajność,
styles – wszelkiego rodzaju formatorania kodu, białe znaki, przecinki czy brakujące średniki
ci – zmiany na potrzeby CI (konfigi, skrypty),
build – zmiany wpływające na proces builda,
revert – revert ostanich zmian