GIT: Release branch w podejściu Trunk Based Development

Nagrałem screencast, gdzie tłumaczę jak podchodzić do release’owania kolejnych paczek gdy korzystamy z Gita (a w szczególności z Trunk Based Development).

Strona, z której korzystałem to https://learngitbranching.js.org/. Można na niej pouczyć się branchowania bo ma interaktywne tutoriale. Ja korzystam z tej opcji bez tutoriali czyli https://learngitbranching.js.org/?NODEMO

(wiem, że są szumy, ale „Done is better than nothing”, kupię mikrofon)

trunk based development i release branches
Tak wygląda historia na końcu

Komendy, które były wpisywane w „konsoli”:

git checkout -b develop
git commit
git tag ver-2.1
git branch rel-2.1 // drogi się rozchodzą, QA testuje, team dev’ów tworzy kod
git commit // kolejny feature
// bug
git commit
git tag fix-1
// bug 2
git commit
git tag fix-2
git checkout rel-2.1
git cherry-pick C4
git cherry-pick C5
git checkout develop
git commit // kolejny feature
// Minął miesiąc(2), a może sprint. Decydujemy się na kolejny release
git commit
git tag ver-2.2
git branch rel-2.2
git commit // kolejny feature
// QA znalazł buga
git commit
git tag fix-3
git checkout rel-2.2
git cherry-pick C9
// gdy 2.2 poszło na produkcję to
git branch -D rel-2.1
commity bez opisu oznaczają ze tu się dużo mogło dziać.

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj /  Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

w

Connecting to %s