Verziókezelő rendszerek: Git

A szoftverfejlesztés gyors tempójú világában, ahol a kód hihetetlen ütemben változik, elengedhetetlen a változások nyomon követése, a csapattársakkal való együttműködés és a projekt történetének/előzményeinek megőrzése. Ekkor jönnek képbe a verziókezelő rendszerek.

A verziókezelő rendszerek, vagy röviden VCS-ek (Version Control System) a modern szoftverfejlesztés alapkövei. Rendet teremtenek a projekt során, és lehetővé teszik a fejlesztők számára a együttműködést.

De nem csak a szoftverfejlesztésben használhatóak fel.

Kifejezetten előnyösek szöveges dokumentumoknál is, hiszen a dokumentum összes szerkesztése/módosítása megtekinthető egy helyen és biztosak lehetünk abban, hogy nem tűnnek el a szöveg egyes részei.

Ez a blog is verziókezelő rendszer segítségével készül.

A következőkben mélyen elmerülünk a verziókezelők világában, különös tekintettel az egyik legnépszerűbben, a Gitben.

Képzeld el a következő forgatókönyvet:

Egy fejlesztőcsapat tagja vagy, amely egy projekten dolgozik. Te és a kollégáid egy időben végeztek változtatásokat a kódon. Verziókezelés nélkül ez olyan, mintha egy közös lapon rajzolgatnátok egyidejűleg és mindenki másik színnel – ez a zűrzavar, a konfliktusok és az elveszett munka alapja. Gyakran előfordulhat, hogy a kód felülíródik, és így a hatékony munka elképzelhetetlen.

A verziókezelő rendszerek hatékony megoldást kínálnak ezekre a kihívásokra. Nyilvántartást vezetnek a kódon végrehajtott minden változtatásról, lehetővé téve, hogy nyomon követhesd, ki, mikor, mit és miért tett. Ha egy új funkció hibát okoz, akkor pontosan meg tudod határozni a felelős változtatást, és visszaállíthatod a kódot bármelyik előző állapotába.

Verziókezelő rendszerekkel a közös munka egyszerűsödik, mivel a fejlesztők egyidejűleg dolgozhatnak a projekt különböző részein, és biztosak lehetnek abban, hogy a módosításaik nem ütköznek egymással.

Nevezhetjük a projekt időgépének is.

A következőkben bemutatom a Git működését, a repository létrehozásának és a commitolásnak az alapjaitól az olyan fejlett fogalmakig, mint a branch és a merge. De ne aggódj, ha még új vagy a Gitben, az alapoktól kezdjük.

Mit takar a verziókezelő rendszer megnevezés?

Tulajdonképpen, a verziókezelés a kódbázisban vagy bármely fájlgyűjteményben idővel végrehajtott változtatások nyomon követésére és kezelésére szolgál. Tárolja a projektben bekövetkezett módosításokat, kiegészítéseket és törléseket, így létrehozva a kód változásának előzményeit.

Mivel minden változtatáshoz tartozik egy üzenet (commit message), amely leírja a végrehajtott módosításokat, így a verziókezelő rendszerek a projektben valaha is végrehajtott változtatásról részletes nyilvántartást vezetnek. Ez a részletes nyilvántartás lehetővé teszi a fejlesztők számára, hogy megértsék, hogyan fejlődött a kód, így könnyebb azonosítani a hibák forrását, nyomon követni, hogy mikor vezettek be egy adott funkciót, vagy szükség esetén visszaállítani egy stabil állapotot.

Git verziókezelő rendszer

A Git-et Linus Torvalds hozta létre 2005-ben. Linus a Git-et kényszerűségből fejlesztette ki, miközben a Linux operációs rendszer fejlesztését irányította. Szüksége volt egy olyan verziókezelő rendszerre, amely képes volt kezelni egy nagy, elosztott csapat igényeit.

A Git legfontosabb jellemzői:

• A központosított verziókezelő rendszerekkel ellentétben a Git nem támaszkodik egyetlen központi szerverre. Ehelyett minden fejlesztőnek a saját számítógépén van a teljes előzmény.
• A sebességéről és a hatékonyságáról ismert. Arra optimalizálták, hogy kis és nagy projekteket egyaránt könnyedén kezeljen.
• Kiválóan teljesít az elágazási és összevonási munkafolyamatokban. A fejlesztők ágakat (branch) hozhatnak létre új funkciók, hibajavítások számára, és később ezeket az ágakat visszaolvaszthatják (merge) a fő ágba.
• A segítségével a fejlesztők offline, internet nélkül is dolgozhatnak. A változtatásokat helyben rögzíthetik, és később szinkronizálhatnak a távoli tárolókkal.

Alapvető koncepciók

A működése egyszerű, minden egyes commit a teljes projekt egy adott időpontban készült pillanatképét jelenti. Ezek a commitok időrendi sorrendben kapcsolódnak egymáshoz, és így egy láncot alkotnak.

A használatának megkezdése előtt fontos megérteni néhány alapvető fogalmat.

Repository

A repository (tár) egy olyan mappa (folder), amely a verziókezeléshez szükséges összes fájlt és adatot tartalmazza. Tartalmaz egy rejtett .git nevű mappát, amely a tárolóhelyre vonatkozó adatokat tárolja.

Commit

A commit egy pillanatkép a repository egy adott állapotáról.

Minden commit egyedi azonosítóval, úgynevezett hash-sel rendelkezik, és tartalmazza a végrehajtott változtatások adatait, a szerzőt és a változtatás időpontját.

A commit szövege kardinális rész, hiszen az előzmények között sokkal könnyebben tudunk majd keresgélni. A commitnak kötelezően tartalmaznia kell egy üzenetet, amelyben a következőket érdemes megadni:

• a feladat célja
• mire volt ráhatása
• ha azonosítóval rendelkező feladaton dolgozunk, akkor ezt is érdemes megadni

Jó példa:

Hibajavítás #123: Felhasználó hitelesítési logika frissítése

- Megoldottam egy biztonsági sebezhetőséget a jelszó kódolásával kapcsolatban.
- Frissítettem a felhasználói dokumentációt az elvégzett változtatásokkal kapcsolatban.

Szerző: Jane Doe [email protected]

• az összefoglaló sor világos és tömör, kimondja, hogy a commit a #123-as azonosítójú problémával foglalkozik, és rövid áttekintést ad az elvégzett változtatásokról
• az üzenet teste részletes információkat tartalmaz arról, hogy mi történt, beleértve a biztonsági javításokat és a dokumentáció frissítéseit

Rossz példa:

Változtatás

• az összefoglaló sor nem tartalmaz semmilyen információt a változásokról
• az üzenet nem tartalmaz semmilyen információt arról, hogy valójában mi változott a kódban

Célszerű úgy dolgozni a feladatokon, hogy minden funkció vagy feladat egy commitba tartozzon.

Branch

A branch (ág) egy különálló fejlesztési vonal egy tárban. Lehetővé teszi a fejlesztők számára, hogy függetlenül dolgozzanak a funkciókon vagy javításokon anélkül, hogy befolyásolnák a fő kódbázist.

A branchek elnevezései fontosak, hiszen ha a későbbiekben vissza szeretnénk térni rájuk, akkor a neve alapján meg tudjuk állapítani, hogy miről is van szó.

• a branch neve legyen világos és leíró
• használj kötőjeleket a szavak elválasztásához
• ha azonosítóval rendelkező feladaton dolgozunk, akkor azt használjuk
• használj kisbetűket

Jó példák:

javitas/felhasznalo-hitelesites
javitas/hiba-456

Rossz példák:

javitas
Javitas/Hiba456

Merge

A merge két branch összefűzését jelenti. Képzeld el, hogy van egy fájl és ennek két különböző változata.

A Git a legtöbb esetben automatikusan összefűzni a változtatásokat, de mégis előfordulhatnak konfliktusok, ha két branch különbözőképpen módosítja ugyanazt a sort. A konfliktusok megoldása ilyenkor manuálisan történik, hiszen csak a fejlesztők tudhatják pontosan, hogy mi a helyes és mi nem.

A konfliktusok kezelése egy fontos része a folyamatnak, hiszen itt kerülhet por a gépezetbe. Előfordulhat, hogy emberi hibából kifolyólag, valami olyan törlődik aminek nem lenne szabad. Ha nem vagyunk biztosak magunkban, akkor mindenképpen érdemes megkérdezni azt a fejlesztőt aki az adott sort változtatta.

Push

A push azt jelenti, hogy a helyi (csak a saját szamítógépünkön létező) commitokat elküldjük egy távoli tárolóba, így elérhetővé téve azokat mások számára.

Pull

A git pull parancsot arra használjuk, hogy egy távoli tárolóból lekérjük és
letöltsük a változtatásokat, majd integráljuk azokat az aktuális ágba.

Kollaboratív fejlesztés

A kollaboratív szoftverfejlesztés egy olyan megközelítés, amelyben több személy vagy csapat dolgozik együtt. A közös célok elérése érdekében a fejlesztők közötti együttműködésre és kommunikációra helyezi a hangsúlyt.

A közös fejlesztés gyakran magában foglalja a kódellenőrzéseket, amikor a csapattagok megvizsgálják egymás kódját, és visszajelzést adnak róla. A kódvizsgálatok segítenek a kód minőségének biztosításában, a hibák észrevételében és a csapattagok közötti tudásmegosztásban.

GitHub

A GitHub egy webalapú platform és szolgáltatás, amelyet elsősorban verziókezelésre és kollaboratív szoftverfejlesztésre használnak.

Tárhelyeként szolgál. A fejlesztők nyilvános vagy privát repository-kat hozhatnak létre kódjaik tárolására.

Rengeteg nyílt forráskódú projekt a GitHubot használja elsődleges platformként a kódok tárolására és kezelésére. A GitHub olyan funkciókat biztosít, amelyek megkönnyítik a világ minden tájáról való közreműködést.

A problémakövető rendszere lehetővé teszi a fejlesztők számára, hogy hibákkal, funkcióigénylésekkel kapcsolatos feladatokat jelentsenek.

Olyan eszközöket kínál, mint a mérföldkövek és címkék, amelyek segítik a projektmenedzsmentet. A csapatok ezekkel a funkciókkal tervezhetnek, nyomon követhetik az előrehaladást.

GitLab

Sok tekintetben hasonlít a GitHubhoz, de további extra funkciókat biztosít.

Mélyen integrálódik a Kubernetes-szel. Ez az integráció leegyszerűsíti a konténeres alkalmazások telepítését és kezelését.

A GitLab egy felhőben futtatott és egy saját szerverre telepíthető verziót is kínál, amelyet a saját szervereinkre is telepíthetünk.

Haladó Git koncepciók

A Git ajánl még sok-sok egyéb hasznos funkciót, amelyet nem minden nap használnak a legtöbb esetben.

Tagging

A tagging (címkézés) egy olyan mechanizmus, amely értelmes, ember által olvasható címkéket társít egy adott commithoz vagy a repository előzményeinek egyes pontjaihoz. A címkék számos fontos célt szolgálnak a szoftverfejlesztésben és a verziókezelésben:

• a címkéket gyakran használják a projekt jelentős mérföldköveinek, például a szoftverek verzióinak jelölésére
• a címkék hivatkoznak commitokra, még akkor is, ha a repository ágstruktúrája idővel megváltozik. Ez különösen akkor lehet hasznos, ha elemezni kell a múltbeli kódot

A címkék elnevezései a legtöbb esetben a szemantikus verziókezelés (SemVer) sémáját követik. A SemVer széles körben elfogadott a szoftveriparban, és segít fenntartani a kompatibilitást és a stabilitást.

A SemVer verziószámok három részből álló formátumot követnek:

MAJOR.MINOR.PATCH

Például:

1.0.0
2.3.2

E részek mindegyike konkrét információkat közöl a változások jellegéről:

• MAJOR verzió:
  • a fő verziószámot jelöli.
  • a főverziószám emelése olyan visszafelé nem kompatibilis változásokat jelez

Példák olyan változtatásokra, amelyek indokolják a főverzió növelését:

• jelentősebb átírások/változások
• jelentős változások a projekt céljaiban
• MINOR verzió:
  • a kisebb verziószám növelése visszafelé kompatibilis új funkciókat vagy fejlesztéseket jelez
  • a kisebb verziószámú frissítések új funkciókat adnak hozzá

Példák olyan változásokra, amelyek indokolják a kisebb verziószám növelését:

• új funkciók hozzáadása
• optimalizálás
• PATCH verzió:
  • a javítás verziószámának növelése visszafelé kompatibilis hibajavításokat vagy javításokat jelez

Példák a javítási verziószám növelését indokoló változtatásokra:

• hibajavítások
• biztonsági frissítések

Rebasing

A rebasing egy olyan művelet, amely lehetővé teszi a commitok egy sorozatának áthelyezését, kombinálását vagy módosítását.

Miért használd:

• segít egy lineáris commit-előzményt létrehozni, amelyben nincsenek merge commitok
• a branckeket naprakészen tartja a fő branch legújabb változtatásaival
• rendbe teheted a commit-előzményeket, mielőtt megosztanád a kódot másokkal

Mikor ne használd:

Kerüld az olyan branchek rebase-elését, amelyeken több csapattag aktívan osztozik és dolgozik együtt, mivel az megzavarhatja a megosztott előzményeket.

Submodules

A submodulok (almodulok) a Git egy olyan funkciója, amely lehetővé teszi, hogy egy repository-ba almappaként egy külön repository-t tegyünk. Az almodulok akkor hasznosak, ha külső modulokat akarsz bevonni a projektedbe, miközben azokat különállóan és verziókezelve tartod a saját tárolóikban.

Gyakori kérdések

• Használhatok egyszerre több verziókezelő rendszert egy projektben?Igen, technikailag lehetséges, de ez nem ajánlott, hiszen a kezelése bonyolult lehet.

További tippek

• győződj meg arról, hogy választott verziókezelő rendszer rendelkezik integrációkkal az általad használt kódszerkesztőkkel
• győződj meg arról, hogy hozzáférsz a választott verziókezelő rendszer dokumentációjához
• vizsgáld meg, hogy a verziókezelő rendszer eleget tesz-e a projekt egyedi igényeinek
• definiálj verziókezelési irányelveket és ezeket mindenkinek be kell tartania

Következtetés

A Git vagy más verziókezelők használata a mai programozási világban alapvető készség. Ezek nélkül szinte alkalmatlanok vagyunk teljesíteni a mai programozási elvárásokat.

További források

Git dokumentáció

Gitlab

Github

Kubernetes