GitLab¶
Verziókövetés¶
A verziókövetés lényegében valamilyen információ - például a forráskód - több változatának menedzselése.
Verziókövető rendszerek jellemzői:
-
Nyomonkövetés, hogy mikor és hogyan változott a könyvtárunk és ki végezte el a változtatást
-
Visszaállítható bármelyik korábbi állapota a könyvtárnak, illetve lekérhető a legfrisebb verzió
-
Szinkronizálni tud egy másik gépen levő hasonló könyvtárral (átvezetve a változásokat)
-
Jelez, ha ezt nem tudja automatikusan elvégezni
-
Minden verziót egy szám vagy hash azonosít
-
A verziók összefüggései egy gráffal vizualizálható a legegyszerűbben
Azaz innentől kezdve nincs szükség arra, hogy a fájlok elnevezésével jelöljük meg a különböző verziókat, hiszen szoftveres módon fogjuk tudni kezelni innentől kezdve a problémát.
Verziókövetéssel egyébként sok helyen találkozhatunk - például a Microsoft Word is rendelkezik beépített verziókövető rendszerrel - esetünkben viszont két verziókövető rendszert érdemes tárgyalni, az a Git és az SVN.
| Git | SVN |
|---|---|
| Elosztott rendszer | Centralizált rendszer |
| Offline is elérhető | Hálózatot igényel a használata |
| Komplexebb rendszer | Egyszerűbben átlátható/tanulható |
| A fejlesztési ágak kezelése komplikáltabb | A fejlesztési ágak könnyen kezelhetőek |
| A konfliktusok száma lecsökken | A konfliktusok száma nagyobb |
| Gyorsabb rendszer | Lassabb működésű |
Verziókövetés fogalmak¶
A félév során Git verziókövető rendszert fogunk használni, így az alábbi fogalmak is erre a verziókezelő szoftverre vonatkoznak (néhány fogalom más verziókezelő esetén - például SVN - nem értelmezhető/mást jelent). A Git verziókezelő rendszer a szöveges állományok, így tipikusan a forráskód fájlok, dokumentációk változáskezelésében hatékony. Ez azt is jelenti, hogy bizonyos fájlokat nem érdemes verziókövetés alá vonni Git-tel (bizonyos nézőpontból pedig elvi hiba, hiszen a Git nem tárhelyszolgáltatásként működik). Így tehát a következő állományokat NE tároljunk: rejtett fájlokat, futtatható állományokat, tömörített mappákat pl.: bin/, tmp/, node_modules/, .class, .log, .jar, .zip, .rar
-
Master: a fő fejlesztési irányvonal
-
Branch: különböző elágazások a fejlesztésben, amelyek később visszatér(het)nek a master-be
-
Conflict: ugyanaz a dokumentum két helyen megváltozik (pl. más branch-eken), és a változtatások automatikusan nem egyesíthetőek
-
Repository (remote, local): a forráskódok, history (korábbi események) tárhelye (szerver)
-
Working copy (working directory): aktuális munkakönyvtár egy adott repository-hoz nézve
-
Commit: a fájlok eltárolása a local repository-ban
-
Staging area: átmeneti terület a local repository és a working directory között, a következő commit-ra jelölt fájlokat tartalmazza
-
Push, Pull: a local és a remote repository közötti commit-ok feltöltése/letöltése
-
HEAD: a legutolsó commit-ra való hivatkozás az aktuális branch-ben
-
Checkout: branch-ek közötti váltásra szolgál
-
Clone: remote repository lemásolása a saját gépre (első alkalommal)
-
Merge: branch-ek egyesítése
Önmagában a Git is egy hasznos eszköz, viszont tipikusan ún. Git menedzselő szolgáltatásokkal együtt használjuk. Ilyen webszolgáltatás a GitLab, GitHub illetve a BitBucket is. Ezen szolgáltatások lényege ugyanaz, egyszerre biztosítják a Git általi verziókövetést, illetve számos egyéb, a csapatmunkát elősegítő eszközt is, többek között feladat és hibakövető rendszert, wiki oldalakat, vagy a projekt build-elését, deploy-olását elősegítő eszközöket is.
Feladat és hibakövető rendszer¶
-
Célja a fejlesztés nyomonkövetés
-
A szoftver készítése során problémák merülhetek fel a működéssel kapcsolatban
-
Hibákat javítani kell, amihez a szoftverfejlesztőknek értesülniük kell a hibákról
-
A csapat munkáját teljes kontextusban láthatjuk
-
A félév során a GitLab Issue Board-ját fogjuk használni, dDe több szoftveres megoldás is létezik: https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems
A GitLab elérése¶
A félév során az egyetem GitLab szervere a következő címen érhető el: https://git-okt.sed.inf.szte.hu/users/sign_in
Belépés során használjuk a h-s azonosítót (hXXXXXX) és az LDAP fület.
Group létrehozása¶
A projektmenedzser hozzon létre egy új csoportot. A csoport nevének formai követelménye: 2022_kurzuskod-gyakorlat_projektnev,
Figyeljünk arra, hogy a NEPTUN-ban is megtalálható kurzuskódban nagy i betű van és nem kis L, illetve a projektnév nem egyedi, hanem a választható projektek közül kell a megfelelőt beírni, tehát pl.: 2022_IB153I-17_film
A path és a name ugyanaz legyen, illetve a csoport láthatósága Private legyen.
Projekttagok hozzárendelése¶
A bal oldalon válasszuk ki a Members menüt. A keresőben csak azokat hallgatókat listázza a rendszer, akik már beléptek a GitLab felületére. A tagok jogosultsága legyen Master. A gyakorlatvezetőt nem kell hozzáadni a projekthez.
Projekt létrehozása¶
Figyeljünk arra, hogy a korábban létrehozott csoport „alá” hozzuk létre a projektet.
Figyeljünk továbbá a projekt nevére is, ha mindent jól csináltunk, akkor a következő URL-en keresztül elérhető az új (egyelőre üres) projekt: https://git-okt.sed.inf.szte.hu/2022_kurzuskod-gyakorlat_projektnev/projektnev.git
Mérföldövek és Issue-k¶
Hozzuk létre a projekttervben is szereplő mérföldköveket.
Lehetőség szerint M1, M2, M3, M4 nevekkel hozzuk létre és állítsuk be a megfelelő indulási és bejezési dátumot is (a projekttervnek megfelelően).
Minden (projekttervben szereplő) feladat és (a fejlesztés során fellépő) hiba egy Issue-nak felel meg. Minden Issue-hoz hozzárendelünk egy címet, felelőst és mérföldkövet is.
Gyakorlásképp hozzunk létre még pár Issue-t és rendeljük az első mérföldkőhöz.
Issue Board¶
Kattintsunk a Board-ra és kattintsunk az Add default list gombra.
Lényegében egy tábla nézetben tudjuk az Issue-kat áttekinteni és azok állapotait vezetni (To Do, Doing, Closed).
Az Issue-hoz tartozó műveletek kilistázódnak, illetve hozzá is tudunk szólni (pl. hiba, kérdés esetén), vagy akár projekttagot tag-elni (pl. @h123456), Issue-ra hivatkozni (pl. #1), commit-ot megjelölni a hash azonosítója segítségével (pl. b3c8bd74).
A félév során mindenkinek kötelezően vezetnie kell a projekttervben vállalt feladatait Issue-k formájában. Vezetés alatt az adott feladat/hiba teljes életciklusát értjük, amely során a feladatokat mérföldkövekhez rendeljük, a korábban részletezetett állapotokat folyamatosan megjelöljük, a feladat megoldásához tartozó commit-okat tag-eljük, a fellépő hibákat rögzítjük.
Mérföldkövek lezárása¶
Optimális esetben egy adott mérföldkő határidejére már minden Issue állapote Closed, azaz a mérföldőkben vállalt összes feladat elvégzésre került. Ennek állapotát szintén nyomon lehet követni.
A mérföldkő lejártakor a mérföldkövet is le kell zárni, azonban az el nem végzett feladat lezárása TILOS!
Markdown¶
A Git menedzselő szolgáltatások (pl. GitLab) és a Markdown jelölőnyelv között szoros kapcsolat van. Könnyen olvasható és könnyen írható sima szöveges formátum, amelyet a menedzselő szolgáltatások könnyen meg tudnak jeleníteni.
Talán a legtipikusabb megjelenési formátuma az ún. README.md fájlok (a Markdown fájlok .md kiterjesztésűek), illetve találkozhattunk vele ennek a tárgynak a keretein belül is, hiszen a projektterv is Markdown-ban íródott.
A README fájlokról bővebben: https://www.makeareadme.com/
A Markdown szintaxisát összefoglaló dokumentáció: https://www.markdownguide.org/basic-syntax/
A Markdown táblázat online készítése: https://www.tablesgenerator.com/markdown_tables