Mi az, amit minden fejlesztőnek tudnia kellene, de szinte nincs egyetem, ahol oktatnák? Ezek a verziókövető rendszerek, amit minden jól működő fejlesztőcég alkalmaz.

1. Verziókövető
rendszerek alkalmazása
fejlesztési projektekben
Gyöngyösi Péter, BalaBit

2. Mi az a verziókezelés?
Egy adathalmaz konzisztens állapotait és
változását rögzíteni képes és azt
visszakövethetővé tevő rendszer.

3. Miért verziókezelünk?
Mert egy nagyon jó eszköz.
(és a jó eszközöket szeretjük)

4. Hogy tudjuk, mi történt
•
mikor mi és hogyan
került a kódba
•
látni a kontextust
•
ticketekkel, bugokkal
összekötni a kódot
•
ad egy timeline-t

5. Backup
•
nem kell félni a változtatásoktól
•
szimpla backup egy idő után töröl, ha te törölsz
•
könnyen vissza lehet nyerni bármi korábbi
állapotot
•
olcsón ki lehet próbálgatni dolgokat
•
build-management alapvetése: mindent
lehessen újrabuildelni!

6. Regression-keresés
•
„Ez hogy működhetett valaha, és mikor törtük
el?”

7. Együttműködés
•
több ember dolgozik a projekten – valahogy
össze kell fésülni a munkájuk
•
„Na és ezért kinek törjem el a kezét?”

8. Mindez a gyakorlatban
•
miért a git?
•
kollaboráció
•
fejlesztés-tracking
•
backup
•
regression-keresés

9. Miért a git?
•
gyors, effektív
•
sok hasznos tool létezik hozzá
•
az elosztottság rengeteg speciális helyzetben
egy nagyon kényelmes, hasznos dolog
•
az open source világhoz ezer szállal kötődünk,
ott meg egyre dominánsabb...

10. Kollaboráció – a BalaBit
•
sok programnyelv, heterogén
fejlesztőkörnyezet
•
security termékek → erős kontroll a mainline-on
•
kis csapatok...
•
...de sok közös komponens csapatok közt
•
újrabuildelhetőség nagyon fontos
•
sok külső, open source függőség

11. Kollaboráció – a cherry-
pick mainline
patch 6 ✓ dev-gyp
• terméken, csapaton belül patch 5 ✓
jatekpatch 3
használjuk főleg
✓ gyp patch 2
• alapkoncepció: patch 4 ✓
• fejlesztőnek/tesztelőnek
patch 3 ✓ jatekpatch 2
saját ág, ami az ő játszótere
• az integrálandó patcheknek patch 2 ✓ ✓ gyp patch 1
kell jóknak lenni, azontúl
olyan szemétdomb lehet,
patch 1 ✓ jatekpatch 1
amit nem szégyell

12. Kollaboráció – a cherry-
pick mainline
gyp feature 2 ✓
dev-gyp
✓ gyp patch 3
• integrálás: gyp feature 1 ✓
jatekpatch 3
• közös review (személyesen,
semmi fancy tool) ✓ gyp patch 2
patch 4 ✓
• patcheket szedünk
• javíthatunk, összevonhatunk, patch 3 ✓ jatekpatch 2
darabolhatunk
• conflict-feloldás itt, ha túl sok, patch 2 ✓ ✓ gyp patch 1
visszadobjuk
• tiszta, önmagában értelmezhető patch 1 ✓ jatekpatch 1
patchek kellenek

13. Kollaboráció – a cherry- jatekpatch 3
pick mainline dev-gyp
jatekpatch 2
jatekpatch 1
gyp feature 2 ✓
✓ gyp patch 3
jatekpatch 3
gyp feature 1 ✓
• fejlesztő időnként rebase-el
• kidobja a saját patcheit
✓ gyp patch 2
• behúzza magához a mainline-t patch 4 ✓
• visszarakja egyesével a patcheket,
conflictot old fel patch 3 ✓ jatekpatch 2
• amik már felkerültek, itt kidobja
patch 2 ✓ ✓ gyp patch 1
• lehet itt is szerkeszteni, átrendezni,
kidobálni
patch 1 ✓ jatekpatch 1

14. Kollaboráció – a cherry-
pick
•
git alapon mindez:
•
mainline, fejlesztői ág: git repository-k
•
git remote-tal egymásnak megadva
•
git cherry, git cherry-pick
•
git rebase –interactive
•
kicsit buta, scripttel kell neki segíteni

15. Kollaboráció – a merge
zorp-mainline
scb-mainline
• főleg csapatok közt, közös
komponensekhez
• a git jobban „szereti”, ✓ scb patch 4
effektívebb eszközök zorp patch 4 ✓
• de kifogástalan minőségű
zorp patch 3 ✓ ✓ scb patch 3
ágakra van szükség!
• egy Linux kernel-szintű zorp patch 2 ✓ ✓ scb patch 2
dolognál ez belefér...
✓ scb patch 1
• ...de egy átlagos fejlesztői zorp patch 1 ✓
projektnél ez túl drága

16. Kollaboráció – a merge
zorp-mainline
scb-mainline
zorp patch 5 ✓ ✓ scb patch 5/B
•
tipikusan mainline-ok merge ✓ ✓ scb patch 5/A
között
✓ scb patch 4
előre meghatározott zorp patch 4 ✓
pontokon (pl. új zorp patch 3 ✓ ✓ scb patch 3
release kezdetekor)
merge-ölünk zorp patch 2 ✓ ✓ scb patch 2
✓ scb patch 1
zorp patch 1 ✓

17. Fejlesztés követése
- rendes verziókezelést követelünk meg, amit a git támogat
nem fájlonként, hanem patchenként commit
olcsó, egyszerű brancheket csinálni, emiatt könnyebb tisztán
tartani a dolgokat
alap git toolok elegendőek:
git log
gitk
gitweb

18. Backup
pofátlanul könnyen indítható verziókezelés
git init; git add .; git commit
olcsó, könnyű branchelés
git stash
git checkout
git tag

19. Regression-keresés
git checkout → visszaállás tetszőleges állapotra
git log fájlra, git blame
best thing since slice bread: git bisect
git bisect start
git bisect good release-1.0.0
git bisect bad
[make check]
git bisect good/bad...
(scriptelhető is!!!)

20. Összegzés
a verziókezelés nem szükséges macera, hanem
eszköz!
...de ehhez az kell, hogy ne legyen útban:
akkor kelljen dolgozni vele, amikor akarunk
legyen gyors
legyen megbízható
legyen flexibilis
...és a git erre nagyon jó.

21. Köszönöm.
Gyöngyösi Péter
gyp@balabit.hu