Model pracy z gałęziami w GIT

Model pracy z GITem od Vincenta Driessena

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

MODEL PRACY Z GAŁĘZIAMI W GITPoprawki nanosimy w gałęzi master poprzez ich implementację w warstwie hotfix branches. Stosujemy tutaj konwencję nazewnictwa hotfix-*.

* – 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

GITNowe 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

Model pracy z repozytorium GITa.Releasy to nic innego jak przygotowanie zestawu funkcjonalności do grupowego wydania na produkcję. W warstwie release branches stosujemy nazewnictwo  release-*.

* – 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

Linki

http://nvie.com/files/Git-branching-model.pdf
http://nvie.com/posts/a-successful-git-branching-model/