Git, verziókezelés Flashcards
Mire jó a git?
Egyik legnépszerűbb elosztott verziókezelő a piacon a Git.
* A repositoryban tároljuk a változásokat.
* Nem csak a szerveren, hanem minden gépen ott van a teljes repository. (local és remote)
* A Git koordinálja a munkát és javaslatokat ad, hogy hogyan használjuk.
* Vissza tudjuk követni, hogy ki mikor és mit csinált.
* Régebbi verziókhoz bármikor vissza tudunk térni.
* A Git snapshotokat készít az egész repo állapotáról.
Szempontok a git fejlesztésekor
● egyszerű legyen
● gyors legyen
● ne a lineáris fejlesztést támogassa
● nagyon nagy projektekhez is legyen alkalmas.
Git Branch modellek
Kétféle branch létezik:
* Long running (master)
* Short lived (pl feature branchek)
Main branchek között szerepel a:
* Master, amire csak releasek kerülnek
* Develop, amin featurok és hibajavítások vannak
* Supporting branchek
* Feature branchek
* Release branchek
* Hotfix branchek
Release branchen ha van bugfix, akkor a developre is bele kell mergelni, nem csak a masterbe. Mindig vissza kell őket mergelni! Hotfix branch arra szolgál ha masteren valami hiba van és ezért gyors hibajavítás kell. Developra is mergeljük ezt.
Github flow
Feature toggles (felhasználó elől elrejtjük a még nem kész featuret).
Napi routine:
● git fetch (lehúzzuk a változtatásokat a develop branchre hogy a legfrissebbről induljunk)
● új feature branch a developból (git checkout -b)
● git add . (változtatások stagelése)
● git commit
● git push
● merge/pull request
● tesztek futtatása (ha lefutottak mehet a merge)
● lokális feature branch törlése merge után.
Github workflow típusok
- Central repository workflow
- Integration manager workflow
- Dictator and lieutenants workflow
Central repository workflow
A központi branch a Main, és az összes változtatás ide kerül be, nem kell több branch.
Ha kész vagyunk a feature-el, pusholjuk a main-re lokálból.
Ha conflictunk van akkor a git vissza fogja utasítani a push-t és kezelnünk kell. Force push esetén átírja a jelenlegi remote branchet.
Integration manager workflow
Van egy blessed repository, amibe egy integration manager mergeli a developerek public repositoryjait.
A developerek privát repositoryjai a blessed repositoryból származnak le majd a változtatásokat a public repóba küldik fel.
Dictator and lieutenants workflow
Ez is egy több remote repositoryt tartalmazó workflow. Nagy projekteknél használják több száz kollaborátorral. Pl ilyenek a nyílt forráskódú programok (Linux).
Vannak integration managerek, akiket lieutenant-oknak hívunk. A lieutenantok behúzzák a változtatásokat a saját repójukba, onnan pedig a dictator mergeli a változtatásokat és felküldi a blessed repository-ba. A developerek repói publicok.
kliensoldali hook-ok
Fetch, commit, push, pull request, issue handling, wiki.
Webhooks -> merge requestnél hívódik meg egy URL, aminél parancsok vannak meghívva, mint buildelés, tesztelés.
Fast-forward merge
Amikor pl a developerről leszármazott feature branchünkkel végeztünk és visszacsatoljuk a developerbe-be, de ott nem történt változás mióta leágaztunk ezért nem lesz nyoma annak, hogy bármilyen visszamergelés történt volna, csak a lineárisan az új commitok fognak látszódni. Azért nem javasolt mert elveszik a nyoma annak hogy volt merge.
2-way merge: 2 külön ágat mergel össze.
3-way merge: A fő branch a 3. és azzal mergelődik össze a 2 leszármaztatott branch.
Rebasing
célja a változtatások összeintegrálása 2 branchről. Itt is van fast-forward.
Visszamegy közös ősig, kitörli a historyt. Nem lesz felesleges merge commit, végeredményben nincs különbség.
Rebase egyenes code historyt eredményez, revertelni könnyű.
Hátrány, hogy elrejti a contextet, újra írja a historyt, pull requestelelni nem lehet, force push kell néha.
Merge előnye, hátránya
Merge előnye a nyomonkövethetőség, hátránya a history nehezen követhetősége. Távoli repoba felrakott commitot ne rebaseljünk, mert így két változtatás 2x lehet benne a historyba.
