3. Miért volt szükségünk rá?
●
Subversion műveletek távoli szerverre
lassúak
●
Revertet leszámítva minden más művelettel a
szerverhez fordul
●
Subversion branchelés nehézkes
●
Igény az elosztott verziókezelők
funkcionalitására
●
Igény code review eszközre
●
Kiadott release csak ellenőrzött kódot
tartalmazzon
6. Fejlesztés menete
●
Lokális feature branch (1 feature / branch)
●
Nincs merge, csak rebase a masterre →
tisztább history
●
git push
●
Egy commit/beküldött change (1 Change ID)
●
Beküldés előtt szükség szerint:
– git rebase i > squash
●
Érdemes elkerülni az egymásra épülő change-
eket
●
Újranyitott review esetén git commit
7. Gépi review (CI)
●
Hudson / Jenkins végzi
●
git push után automatikusan indul
●
Gerrit Trigger
●
Értékei:
●
+1 Verified
●
0 No score
●
-1 Fails
9. Kézi review
●
Beküldő reviewert rendel
a beküldött change-hez
●
Csak akkor van értelme
átnézni a change-et, ha
átment a gépi review-n
●
Code Review
●
webes felület vagy
Eclipse
●
Reviever megjegyzéseket
fűz a kódhoz
11. Kézi review kimenete
●
Change pontozása
●
(Reviewer visszadobja
a change-et)
●
Újabb beküldés
tetszőleges számú
alkalommal
●
Reviewer elfogadhatja
change-et
●
Sikeres review után
merge a master ágba
●
Többi fejlesztő számára