Git - 1. Elmélet

Kezdő fejlesztőként - főleg manapság - elég gyorsan találkozni fogsz a GitHub-bal és a verziókövetés/verziókezelés kifejezésekkel. Amíg egyedül fejlesztesz sokáig feleslegesnek gondolhatod a verziókövetést, főleg, ha úgy gondolod, hogy az elnevezés tényleg csak ennyit takar.

Tegyük fel, hogy van egy projekted, amit valamikor elkezdtél. Ebbe néha napján kódolsz egy picit. Ha ezt verziókezelő nélkül csinálod, ezekkel a problémákkal találkozhatsz egy idő után:

• Pár hónap múlva észreveszed, hogy tönkrement egy korábban jól működő funkció. Látod melyik sorban van a hiba, de nem tudod hogyan állj neki megjavítani, mert nem emlékszel mikkel függött össze az akkori módosítás.
• Egy barátod csatlakozni akar a projekt fejlesztésébe. Hogy dolgoztok egyszerre ugyan azokon a fájlokon?
• Elkészült az első kiadható változatod, az 1.0. Hogyan kezeled innentől azt, hogy az 1.0 hibáit javítod, mégis készülhet emellett az 1.1?

Persze ezekre a példákra mindig van megoldás “nyers erővel”, de fejlesztőként nyilván mindig arra törekszik az ember, hogy jobban és hatékonyabban dolgozzon. Ha még hobbifejlesztő vagy és az a célod, hogy a szakmában helyezkedj el, nem úszod meg verziókövető ismerete nélkül előbb-utóbb.

Fogalmak tisztázása

A GitHub egyszerűbbé és érthetőbbé tette a Git használatát mindenki számára, viszont úgy vettem észre, hogy a térhódításának köszönhetően sokaknak összemosódnak emiatt a fogalmak. A Git nem egyenlő a GitHubbal és vica versa.

A Git egy verziókezelő. Van sok más, pl. a Subversion vagy a CVS. Ez tehát maga a szoftver.

A GitHub pedig egy szolgáltatás, ami Gitet használ, viszont Cloud alapú, felhasználói felületet nyújt, stb. Ha Gitet akarsz használni, nem muszáj GitHub-ot használnod. Gitet a saját gépeden lévő repositoryval is használhatsz vagy ha nem akarod elhagyni a GitHub hasznos funkcióit, használhatsz GitLab-ot, amit akár magad is hosztolhatsz, saját szerveren.

Mi a Git vagy egyáltalán egy verziókezelő?

A verziókezelő egy olyan szoftver, ami egyrészt tárolja a verziókezelni kívánt fájlokat, másrészt nyomonköveti az egyes módosításokat.

Képzeld el azt, hogy van egy fájlod, amit létrehozol valamilyen tartalommal. Legközelebb, mikor megnyitod és szerkesztesz benne, a mentés után röviden összefoglalod mit változtattál benne, ez pedig nyilván lesz tartva, a módosításaid pedig meg lesznek jelölve: melyik sorok kerültek be, melyek lettek törölve, melyek módosultak és hogyan.

A verziókezelő pontosan ezt csinálja, de ettől sokkal okosabban.

A Git egy verziókezelő. Több is van a piacon, de ez lett manapság a legelterjedtebb. Nyílt forráskódú, tehát ingyenes, eredetileg a Linux forráskódjának kezelésére fejlesztette Linus Torvalds.

Kik használnak verziókezelőt?

Szoftverfejlesztők, írók, bloggerek, grafikusok, játékfejlesztők. Gyakorlatilag bárkinek szüksége lehet arra, hogy a munkájában a változtatások követhetőek legyenek. Én értelemszerűen csak a szoftverfejlesztői vonzatával foglalkozok a dolognak, abból is egy általános részével.

A verziókezelés elemei

Mielőtt elkezdenénk használni, fontos tisztázni, hogyan is néz ki a Git kívülről.

Repository

A repository maga a projekted. Például ennek a weboldalnak a kódja is egy repoban lehet, ahogy egy mobil alkalmazás Android vagy iOS projektje, a C#-ban írt egyetemi beadandód, de nem szükséges az, hogy programkód legyen: lehet az bármilyen szöveges vagy akár bináris adat. Egy repo tehát sok fájlt tartalmaz, ami logikailag valahogy összetartozik.

Commit

A repositorykba commitokat tudsz küldeni. Egy commit egy változtatás tulajdonképpen, ami a módosításokat vezeti be a repositoryba, pontosabban a branchbe. Lehet hozzá megadni ún. commit message-et, amivel röviden utalhatsz arra, hogy mit tartalmaznak a benne lévő változtatások.

Például ha erre a weboldalra szeretnék egy “Kapcsolat” menüpontot, ahol egy e-mailt küldő form van, akkor miután elkészült a menüpont, a módosított fájlokat egy új commitban küldöm be, a commit message-be pedig beleírom, hogy “Kapcsolat menüpont”.

Később a commitok listájában látod a leírást és azt is, hogy milyen fájlok módosultak, azokban melyik sorok és azt is, hogy hogyan.

A commit nem csak a módosításaid egy része, hanem a művelet neve is, amivel ezeket a módosításokat rögzíted.

Pull

A pull segítségével le tudod tölteni (“lehúzni”) a távoli Git repositoryból a sajátodba a változtatásokat.

Push

A push egy olyan művelet, amivel a helyi gépeden lévő repositoryba került commitokat felküldöd (“pusholod”) a távoli szerveren lévő Git repositoryba. Fontos tehát, ha commitolsz, az első körben csak a saját, helyi repoba kerül!

Conflict

A conflict az a szomorú dolog, amikor egy push során felküldeni kívánt commitod ütközik egy másik, már feltöltött committal, ami még nálad nem volt letöltve.

Ez így bonyolult egyben, ezért egy példa:

• Reggel 08:00-kor kezdesz a munkahelyeden, egyből meghívod a repositoryn a pull parancsot, hogy a tegnapi nap folyamán történt változtatások bekerüljenek a helyi gépeden lévő repositoryba.
• Elkezdesz dolgozni a kiadott feladaton, legyen az bármi, az index.html-be írod. Több óra eltelik.
• Kollégád eközben az index.html-be beleteszi a “Kapcsolat” menüpontot, commitolt, pusholt.
• Végeztél, commitolsz, majd pusholsz, hogy felkerüljön a szerverre is a munkád.
• A push elakad, ugyanis conflict van.

Mi történt? Az, hogy amíg dolgoztál az index.html-en, kollégád már feltöltött egy másik commitot ugyan ebbe a branchbe, amiben szintén azt a fájlt változtatta meg. Te utoljára reggel pulloltál a szerverről, ezért neked a változtatások csak addig vannak meg a helyi repoban. A verziókezelő nem tudja eldönteni, hogy azt hagyja meg, hogy te törölted a 10. sort vagy azt, hogy a kollégád átírta a 10. sort.

A conflictok megoldhatóak vagy úgy, hogy bizonyos részeket visszavonsz (rollback) vagy úgy, hogy megmondod melyik változtatást kell megtartani (tiédet vagy a kollégádét).

Branch

A branch egy “ága” a repositorydnak, amibe commitokat tudsz küldeni. Minden repository legalább egy branch-et tartalmaz, Git esetén ez a “master”, illetve GitHubon már a “main”, SVN-ben pedig “trunk”.

Bármennyi új branchet tudsz létrehozni az elsődleges mellé és külön tudsz beléjük commitolni. Egyrészt a brancheket használhatod arra, hogy külön kezelj verziókat vagy kiadásokat, másrészt hasznos akkor, ha sokan dolgoznak egy projekten, de erről majd még később.

Merge

A merge segítségével tudod egy branch commitjait egy másikba átvezetni.

Példa: a projekted stabil, működő változata a main branchben van. Egy új funkciót szeretnél fejleszteni, ezért nyitsz egy új branchet, legyen a neve feature. Minden módosításodat a feature branchbe commitolod. Mikor végzel, a feature branchet mergeled a main branchbe, így az abba írt újdonságok bekerülnek oda is.

A merge a csoportmunka egyik legfontosabb eszköze: ha mindenki külön branchben dolgozik, egymás után lehet egyszerűen átvezetni az éles verzióba a módosításokat, vagy akár egy másik, köztes branchbe, amit tesztelésre használtok.

Verziókezelés a “gyakorlatban”

Már említettem, hogy használhatsz Gitet úgy is, hogy csak és kizárólag a saját gépeden tárolod a repodat, viszont miért tennéd? Csak előnye van annak, ha pl. feltöltöd GitHubra, akár egy privát repositoryba a munkádat, hiszen így legalább lesz róla másolatod, amit bárhol elérsz.

Tehát normális esetben a repositoryd egy központi helyen érhető el, legyen ez most a GitHub. Onnan klónozod a saját gépedre, ekkor ott is létrejön. A gépedre töltött repo is tartalmazza a módosításokat, másolata a központi helyen lévőnek.

A saját gépeden lévő viszont magától sosem fog frissülni. A te feladatot az, hogy ez mindig naprakész legyen. A push és pull parancsok azok, amikkel szinkronban lehet tartani a központi és a gépeden lévő repo állapotát. Ha nem akarsz conflictokat, akkor gyakran kell pull parancsot hívni napközben, ha ugyan abban a branchben dolgoztok többen is.

Csoportmunka branchek nélkül

Kevés ember mellett teljesen jól használható, mert rendkívül egyszerű.

Mindegyikötők letölti magához a repot, folyamatosan pullol, és pushol ugyan abba a branchbe. Lehetnek conflictok, de mivel kevés commit kerül be egyszerre, nem nehéz őket megoldani.

Csoportmunka branchekkel

Nagyobb projektek és több emberrel való munka esetén jó.

Valamilyen logikai egység szerint brancheket hoztok létre, ebbe commitoljátok a munkát, majd a végén ti vagy egy vezető mergeli bele a fő branchbe.

A brancheket létrehozhatjátok a megvalósítandó funkció szerint (pl. a sokszor említett kapcsolat formhoz készül egy branch), vagy pl. egy scrum sprint szerint.

Nagy projekteknél, ha nem ti mergelitek ezeket be, már csak azért is jó, mert ekkor a vezető - vagy aki a mergelést végzi - akarva, akaratlanul is code review-t tarthat, illetve rá hárul a conflictok javítása is.

Ezt a megoldást remekül lehet kombinálni ticket manager szoftverekkel, a Scrum fejlesztési mintával és a pull requestekkel, így nagyon hatékonnyá tud válni.

Végszó

Ez az elmélet elég ahhoz, hogy a következőekben azzal folytassuk, hogy létrehozunk egy repositoryt és dolgozunk vele a gyakorlatban.