5 / 42 ELTE, 2016 | Vajna Miklós Minek az elosztott verziókezelés? ● A teljes repó (kivétel: shallow clone) elérhető helyben ● Gyors diff, blame, log, merge ● Nem kell mindig online lenni ● Nincs egyedi hibapont (SPoF) ● Committer fogalma eltűnhet ● Mentések kevésbé fontosak ● Egyszerűbb branch / merge
6 / 42 ELTE, 2016 | Vajna Miklós Miért pont a git? ● Legfontosabb OK: elosztott ● De ezen felül is vannak egyedülálló funkciói: ● git mergerecursive (cherrypick kezeli az átnevezéseket) ● git rerere ● git blame: észreveszi, ha egy darab kódot áthelyeztünk máshova ● git grep ● combined diff
9 / 42 ELTE, 2016 | Vajna Miklós A 4 objektumtípus ● Alacsony szinten: tartalom szerint címezhető filerendszer ● 4 objektumtípus: blob, tree, commit, tag ● Blob: egy fájl egy verziója ● Tree: 1..* tree vagy 1..* blob ● Commit: 0..* commit és pontosan 1 tree ● Tag: csak annotált tagek esetén használatos, bármire mutathat
11 / 42 ELTE, 2016 | Vajna Miklós Ami nem objektum: ref, symref ● A nem annotált tagek refek ● És nem tag objektumok ● Tipikus refek: ● HEAD ● refs/heads/master master → ● refs/remotes/origin/master → origin/master
12 / 42 ELTE, 2016 | Vajna Miklós Ami nem objektum: hooks ● Távoli: pl. levél küldése push után ● Helyi: ● nem szándékos merge esetén figyelmeztetés ● coding style nem betartása ● Lehet kikényszerített (push elutasít) ● Vagy önkéntes (git commit n)
13 / 42 ELTE, 2016 | Vajna Miklós Ami nem objektum: reflog ● git commit m A ● git commit m B ● Utolsó commit eldob ● Akarom is Bt, meg nem is ● reflog: helyi napló Bről ● Alapértelmezés: 2 hétig
15 / 42 ELTE, 2016 | Vajna Miklós Ami nem objektum: index ● Probléma: egy fileban két módosítás, csak az egyiket akarjuk commitolni ● Vagy conflict feloldás közben: conflictok feloldása egyesével Objektumtároló Munkakönyvtár Index diff diff HEAD diff diff --cached
16 / 42 ELTE, 2016 | Vajna Miklós Ami nem objektum: packfile ● Kezdetben: egy objektum egy file → ● Így se rossz: treeben csak a változott file kerül ténylegesen tárolásra ● De: ● Sok I/O seek ● Kis változás nagy fileban ● Megoldás: packfile ● git gc auto
17 / 42 ELTE, 2016 | Vajna Miklós Ami nem objektum: submodule ● Probléma: közös kód, több projekt használná ● Megoldás: tegyük külön repóba, de pontosan kövessük, melyik verzióját használjuk ● API változtatást jól leköveti ● Bisectet segíti
18 / 42 ELTE, 2016 | Vajna Miklós Merge rebase ↔ ● Kezdeti állapot: ● Rebase: ● Merge: A B C F G D E topic master A B C F G D E topic master H A' B' C' F G D E topic master
19 / 42 ELTE, 2016 | Vajna Miklós Parancsok ● Túl sok: a git (2.10.1) 164 paranccsal rendelkezik ● Melyeket kell ismerni? ● Kategóriák: ● Fő porcelain parancsok ● Egyéb porcelain parancsok ● Plumbing parancsok
24 / 42 ELTE, 2016 | Vajna Miklós Refek szimbolikus nevei ● Állatorvosi ló: ● Mit érdemes ebből megjegyezni: ^ és ~ G H I J A = = A^0 \ / \ / B = A^ = A^1 = A~1 D E F C = A^2 = A^2 \ | / \ D = A^^ = A^1^1 = A~2 \ | / | E = B^2 = A^^2 \|/ | F = B^3 = A^^3 B C G = A^^^ = A^1^1^1 = A~3 \ / \ / A H = D^2 = B^^2 = A^^^2 = A~2^2 I = F^ = B^3^ = A^^3^ J = F^2 = B^3^2 = A^^3^2
33 / 42 ELTE, 2016 | Vajna Miklós Konfiguráció ● Konfiguráció: ● Rendszer, globális, helyi ● Repó része is, meg nem is ● Köztes megoldás: – Submodule példa
37 / 42 ELTE, 2016 | Vajna Miklós Branch kezelés: referenced clone ● Csak akkor érdekes, ha több branchünk van ● git clone reference …/master ● Ha submoduleokat is használunk: ● Külön script kell hozzá, pl configure opció ● A megspórolt hely jelentős, egy példa master / branch méretére: 1.2GB / 13MB
38 / 42 ELTE, 2016 | Vajna Miklós Branch kezelés: rebase i ● Még nem publikált commitok remixelése ● Példa: unit teszt ● Javítás commitálása ● Unit teszt commitálása ● Javítás revertelése: jelez hibát a teszt? ● rebase i: – Revert eldobása – Unit teszt squasholása a javításba
39 / 42 ELTE, 2016 | Vajna Miklós Branch kezelés: bisect ● Bisect: bináris keresés ● Regressziók automatikus visszakeresése ● bibisect: ha nagy a projekt, és egy nap lenne ● Reverse bisect: mit kéne backportolni? ● A jó és a rossz válaszok felcserélése ● git bisect start és a git bisect good/bad esetén is
40 / 42 ELTE, 2016 | Vajna Miklós Branch kezelés: push tree ● Készítsünk egy referenced clonet, pl. master push ● Push helyett cherrypick masterpushba, majd onnan push ● Elkerülhető vele egy hosszú rebuild a munkaórák alatt ● Minél kevesebbszer csinálunk tényleges pullozást, annál kevésbé hatékony (több conflict) ● Továbbra is pullozzunk pl. naponta
vmiklos
gr2m
destraynor
reverentgeek
sachag
moore
morganepeng
matthewcrist
jmmastey
akmur
bkeepers
eileencodes
panda_program