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)
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ć.
1 Comments on “GIT: Release branch w podejściu Trunk Based Development”
Show me the code 
Zawsze robiłem odwrotnie, czyli naprawiałem np. na rel-2.1 a później cherrypick na pozostałe gałęzie. Spisane procedury zapobiegają przypadkowemu zapomnieniu o tym. A łatwiej w takim przypadku robić tego cherry-picka z wersji uboższej w kod (rel-2.1 jest uboższa do development, bo na tej ostatniej cały czas dodawane są nowe funkcje) do wersji bogatszej niż odwrotnie. Takie są moje doświadczenia, będę pamiętał o Twoich.