Model pracy z GITem od Vincenta Driessena
Ostatnimi czasy natknąłem się w internetach na model pracy z repozytorium GIT wykreowany przez Vincenta Driessena. Jego podejście sugeruje by trzymać się dwóch głównych gałęzi o nazwach master i jej podgałęzi rozwojowej develop.
Gałąź master odzwierciedla docelowy kod programu jaki znajduje się na produkcji z niej wyciągane są podgałęzie w przypadku wymagania poprawek jest to warstwa gałęzi hotfix branches.
Z gałęzi develop rozwijane są dwie warstwy gałęzi:
- feature branches - zawiera podgałęzie nowych funkcjonalności,
- release branches - zawiera podgałęzie konkretnych wydań.
Z warstwy feature branches poprzez develop trafiają implementację funkcjonalności do warstwy release branches.
Praca z hotfixami
Poprawki nanosimy w gałęzi master poprzez ich implementację w warstwie hotfix branches. Stosujemy tutaj konwencję nazewnictwa hotfix-N.
N - oznacza wersję do jakiej odnoszą się poprawki, przykładowo jeżeli poprawki nanoszone są na wersji 2.0 to wówczas hotfix można oznaczyć jako wersję 2.0.1.
Po naniesieniu poprawek hotfix należy zmerdżować do gałęzi develop oraz master. Tak by obie zawierały naniesione poprawki.
Jeżeli w trakcie powstania hotfixa istnieje gałąź w warstwie release branches, to wówczas nie merdżujemy do develop tylko do bieżącej gałęzi releasowej. Ostatecznie po zamknięciu gałęzi release i tak trafi do gałęzi develop.
Przykład: Do zaimplementowania jest bug znajdujący się w wersji 2.0.
tworzymy odgałęzienie hotfix-2.0.1
git checkout -b hotfix-2.0.1 master
poprawiamy błąd/błędy, zmieniamy wersję aplikacji na 2.0.1
git commit -am “Zmiana wersji na 2.0.1”
nanosimy poprawki:
- poprawki
- commit… ostatnie poprawki
- ostatni commit
łączymy poprawki z gałęzią master
git checkout master
git merge -no-ff hotfix-2.0.1
tagowanie wersji
git tag -a 1.2.1
Łączymy poprawki z gałęzią develop, jeżeli istnieje gałąź nowego wydania to wówczas łączymy do niego.
git checkout develop git merge -no-ff hotfix-2.0.1
usuwanie gałęzi poprawki
git branch -d hotfix-2.0.1
Praca z Featureami
Nowe funkcjonalności wdrażane w aplikacji powinny znajdować się w swoich indywidualnych pod gałęziach. Daje to niejako piaskownice do pracy nad nimi, i gwarancję, że nie popsujemy funkcjonowania systemu w trakcie prac.
Nazewnictwo gałęzi dotyczących funkcjonalności nie jest tak rygorystycznie określone. Należałoby przyjąć własną konwencję.
Gałęzie z warstwy feature branches wywodzą się od gałęzi develop.
Przykład: Praca nad nową funkcją w systemie:
tworzymy odgałęzienie features/new_ultra_super_feature
git checkout -b features/new_ultra_super_feature develop
pracujemy nad funkcjami:
nowa funkcja 1 nowa funkcja 2 nowa funkcja 3
łączymy funkcjonalności z gałęzią develop
git checkout develop
git merge -no-ff features/new_ultra_super_feature
usuwanie gałęzi funkcjonalności
git branch -d features/new_ultra_super_feature
Praca z releasami
Releasy to nic innego jak przygotowanie zestawu funkcjonalności do grupowego wydania na produkcję. W warstwie release branches stosujemy nazewnictwo release-N.
N - oznacza wersję, będzie to kolejny numerek w konwencji jaka została przyjęta, np. 0.1, 0.2, 1.0, itp.
Gałęzie z warstwy release branches wywodzą się od gałęzi develop i poprzez właśnie tą gałąź implementowane są nowe funkcje.
Jeżeli przygotowania nowego wydania dobiegły końca, należy domerdżować nowy release do gałęzi master oraz develop.
W nowym wydaniu będą znajdować się także hotfixy dlatego, należy połączyć także z gałęzią develop (hotfixy znajdą się w gałęzi develop).
Przykład: Przygotowujemy nowe wydanie oznaczone wersją 3.0:
tworzymy odgałęzienie release-3.0
git checkout -b release-3.0 develop
zmieniamy wersję aplikacji na 3.0
git commit -am “Zmiana wersji na 3.0”
pracujemy nad funkcjami:
nowa funkcja 1 -> develop -> release-3.0
nowa funkcja 2 -> develop -> release-3.0
nowa funkcja 3 -> develop -> release-3.0
łączymy ewentualne hotfixy (np. dla wersji 2.9)
git merge -no-ff hotfix-2.9.1
łączymy wydanie gałęzią master
git checkout master
git merge -no-ff release-3.0
tagowanie wersji
git tag -a 3.0
łączymy poprawki z gałęzią develop
git checkout develop
git merge -no-ff release-3.0
usuwanie gałęzi wydania
git branch -d release-3.0
