Első Laravel webalkalmazásunk verziókövetése a Github segítségével

Attila | 2022. 02. 03. 17:37 | Olvasási idő: 4 perc

Címkék: #git #Laravel

A verziókövetés témakörének ismerete manapság már alapelvárás egy programozótól. Annyiféle előnyt nyújt a számunkra ez a terület, hogy nem is lehetne az összeset felsorolni, csak néhányat kiemelek: segíti a fájlok változásainak nyomon követését, látszik, hogy mit hibáztunk, hogyan javítottuk ki, az is látszik, hogy ki hibázott... csapatok külön fejlesztési ágakon tudnak dolgozni ugyanannál az alkalmazásnál és még sorolhatnám hosszan. Én most ezek közül mégis azt hangsúlyoznám ki, hogy azért használjuk ezt a verziókövetést, hogy az általam végigvezetett projekteken folyamatosan láthassátok, hogy mikor, milyen változtatásokat hajtottam végre. Ez is egyfajta naplóként szolgál majd nekünk és segíti az előrehaladást.
Github+VSCode+Laravel

A fejlesztéshez szükséges előfeltételeket teljesítettük már ebben a bejegyzésben, elvileg tehát mindenkinél telepítve van a Git a saját gépén. Az első Laravel alkalmazásunk is meg van már (ha végigcsináltuk ezt a bejegyzést), úgyhogy ezt fogjuk a mostani leírás szerint fellőni a Github-ra (ehhez még mindenképpen kelleni fog egy regisztráció a Github weboldalára). Előtte azonban nézzünk végig egy kis összefoglalót a verziókezelésről, hogy mi is ez és hogyan tudjuk a legegyszerűbb parancsokkal aránylag könnyen kézben tartani az alkalmazásunk verziókövetését.

A Git-es verziókövetésről általában készített egy ügyes hallgatóm, Kiss Bálint egy hasznos kis összefoglalót, amit itt meg szeretnék osztani veletek röviden.

Miért jó a verziókezelés?
Egy verziókezelő rendszer követi a változásokat egy fájlon vagy fájlok csoportjain, hogy hiba esetén vissza lehessen állítani egy korábbi állapotot:

  • Fájl visszaállítása hiba esetén.
  • Egész projekt visszaállítása hiba esetén.
  • Ki módosított utoljára (ki hibázott)?
  • Változások végigkövetése kommentek segítségével.
  • Változtatásokat a projekt adminisztrátora engedélyezheti (legalábbis GitHub esetén).
  • Fejlesztési ágak, branchok létrehozása stb.

A verziókövetés alapfogalmai

  • Repository: tárhely, melyen a projekt van
  • Commit: változtatások érvényre juttatása
  • Push: saját gépünkön lévő munkánk feltöltése távoli repository-ra
  • Pull: szinkronizáció, távoli repository fájlainak letöltése saját gépre
  • Clone: teljes repository lemásolása saját gépre
  • Branch: fejlesztés ágazata (új projekt esetén a kezdeti ág master volt régen, most már main a neve)

Github-os regisztráció után létre tudjuk hozni ott a saját "repo"-nkat (egy közkedvelt rövidítés a repository szóra). A repo-mnak ugyanazt a nevet fogom adni, mint amit a webalkalmazás telepítésekor adtam a projektnek: myfirstsite . Majd kattinthatunk a Create repository gombra alul.

Megjegyzés: természetesen adhatunk a projektünkhöz leírást, README fájlt, vagy akár priváttá is tehetjük, ha nem akarjuk, hogy a külvilágból elérjék, én azonban most publikusan hagyom és majd linkelem is a blogbejegyzés végére. Így ha valaki a későbbiek során elakadna, mindig látni fogja, hogy mit is csináltunk az adott alkalommal a projektünkben.

Tipp: ha kezdő vagy középhaladó programozók vagyunk, de majd szeretnénk elhelyezkedni programozóként vagy új munkahelyet keresünk, akkor sok cégnél szokták kérni, hogy osszuk meg velük a korábbi projektjeinket, mutassuk meg, hogy miket csináltunk eddig. Ebben az esetben nagyon hasznos tud lenni, ha átadunk egy olyan Github elérhetőséget, amiben megfelelően sok projekt repo-ja érhető el, mintegy tanúbizonyságot adunk ezzel tudásunkról. Érdemes élni ezzel a lehetőséggel!

Létrehozás után ezt kell látnunk és vegyük észre, hogy egyből segít is nekünk a Github azzal, hogy milyen parancsokat kell kiadnunk majd ahhoz, hogy összekössük a helyi (local) gépen működő webalkalmazásunkat és a Github-on fent lévő repo-nkat.

Mivel a Git-et telepítettük a saját gépünkre, ezért ezzel együtt települt a Git Bash nevű kliens alkalmazás is, ami egy grafikus felületet biztosít a számunkra. A későbbiekben én majd a VSCode-ban lévő Terminal-t fogom használni, de aki szeretné, az megismerkedhet a Git Bash alkalmazással is, amiben főleg Unix-os parancsokkal tudja kezelni a fájlrendszert (a Git-es parancsok azonosak lesznek, azokat mindjárt meg is nézzük). Itt egy kis rövid felsorolás a számunkra talán legfontosabb Unix-os parancsokról, ha úgy döntünk, hogy mégis a Git Bash-t használjuk majd a VSCode-os Terminal helyett:

  • ls – aktuális könyvtár tartalmának listázása
  • cd – könyvtárba lépés
  • touch – üres fájl létrehozása
  • rm – fájl törlése
  • cp - fájl, mappa másolása
  • mkdir – mappa létrehozása
  • rmdir – mappa törlése

Vágjunk akkor bele a helyi és a távoli (Github-on lévő) repo-k összekötésébe. Elsőként inicializáljuk a VSCode Terminal-jában a projektünket, kvázi jelezzük a rendszernek, hogy ez egy Git-es verziókezelővel nyomon követett alkalmazás lesz: git init

Ennek a parancsnak a kiadásával egy üres Git projektünk jött létre. Továbbá ez egy rejtett .git nevű mappát hoz létre a projekt könyvtárában, mely verziókezeléshez szükséges fájlokat tartalmazza (Windows alatt Vezérlőpultban kell beállítani a rejtett állományok megjelenítését, hogy látszódjon a rejtett mappa).

Tipikus hibák lehetnek: 1) Nem települt fel rendesen a git, emiatt azt írja rá a rendszer, hogy ismeretlen parancs... ekkor ellenőrizzük le újra azokat a dolgokat, amelyeket az előfeltételek teljesülése során megtettünk a git kapcsán (korábbi blogbejegyzésben). 2) Nem a megfelelő mappában adtuk ki a parancsot. Nálam ez a mappa, ahogy korábban már említettem is: C:\xampp\htdocs\myfirstsite . "Ha nem ott lennénk", akkor navigáljunk el oda a cd parancsok kiadásával, vagy pedig nyissunk meg egy új VSCode ablakot, az Open Folder menüpontot válasszuk ki a File menüben, tallózzuk be a myfirstsite webappunk fő mappáját és kattintsunk a megnyitásra. Ekkor a VSCode-ban bal oldalt látszódik is már a projektünk mappa és fájlszerkezete (ha nem akkor válasszuk ki a függőleges menüből a felső Explorer nevű ikont).

A fenti képen látható, hogy nálam megtörtént az inicializáció és a mappák, fájlok színe meg is változott. A legtöbb mappa - bár én színtévesztő vagyok - de sárga színű lett, ami arra utal, hogy ezeket még nem adtuk hozzá a helyi könyvtárunkhoz, ezt azonban mindjárt pótoljuk. De mielőtt megtennénk, felhívnám a figyelmet a könyvtár- és fájllistában két elemre: a vendor mappára és az .env fájlra. Ezeket nem fogjuk feltölteni (szinkronizálni) a Githubra, majd a későbbiekben rátérek, hogy miért is nem. Azt pedig, hogy mit nem akarunk feltölteni a Github-ra, a .gitignore fájlban tudjuk megtenni soronként felsorolva (ha rákattintunk a fájlra és megnézzük, akkor láthatjuk, hogy a vendor mappa és az .env fájl benne is van a listában).

A git status parancs kiadásával láthatjuk is, hogy még egy commit-ot sem hajtottunk végre és még semmilyen fájlt nem "követünk". Adjuk hozzá a fájlokat és mappákat a helyi könyvtárunkhoz, vagyis "kövessük őket": ezt megtehetnénk egyesével is és a jövőben legtöbbször inkább arra lesz szükség, hogy egyesével vagy kisebb csomagban adjunk hozzá fájlokat/mappákat a könyvtárunkhoz, azonban most ez a kezdeti, inicializációs lépés, úgyhogy adjunk hozzá minden fájlt és mappát (amik nem szerepelnek a .gitignore fájlban): git add . (itt a pont fontos karakter, ez fog mindent hozzáadni). A fájljaink és mappáink így a "staging area"-ba kerülnek. Ha újra lekérnénk a git status -t, akkor láthatjuk az eredményt az előző futtatáshoz képest.

Következhet a git commit parancs kiadása, azonban ezt lássuk el egy -m kapcsolóval is, amelynek segítéségével nevet ("üzenetet", megjegyzést) adhatunk a commit-nak: git commit -m "Initial commit"

Ezután a Github ajánlásának megfelelően a branch-et (fejlesztési ágat) nevezzük át a jelenlegi master-ről main-re: git branch -M main

Összeköthetjük ezekután a "staging area"-nkat a távoli Github repository-val (nyilván itt az URL-t ki kell cserélni a saját repo címére): git remote add origin https://github.com/gludovatza/myfirstsite.git

Ha még sosem használtuk a git-et, akkor biztosan szükségünk lesz bejelentkezésre a Github-ra a Terminalunkból:

git config --global user.name "felhasznalonev"

git config --global user.email "emailcim"

Git felhasználónévhez tartozó e-mail cím. A „--global” kapcsoló jelzi, hogy az egész számítógépre (operációs rendszer bejelentkezett felhasználójára) vonatkozóan érvényesülnek a beállítások. Ha kiadtuk a fenti utasításokat, akkor elméletileg felugrik egy kis ablak, ahol meg kell adni a bejelentkezési paramétereinket (jelszó).

A folyamat végén következhet a git push --set-upstream origin main utasítás kiadása, amivel feltöltjük a Github-ra a webalkalmazásunkat. A későbbiekben elég kiadni a git push utasítást, csak legelőször kell ilyen hosszan megfogalmazni.

Sikeresen feltöltöttük a Github-ra a Laravel projektünket! Az eredmény ezen a címen látható: https://github.com/gludovatza/myfirstsite

További kiegészítő gondolatok

A VSCode is segítségünkre van annak kapcsán, hogy git-tel kövessük az alkalmazásunk verzióit. Mutatok egy példát:

Itt látható egy részlet, amelyen látszik, hogy megnyitottam a readme.md fájlt szerkesztésre és hozzáírtam a 10. sorba egy új szöveget plusz ütöttem utána egy Entert, ami a 11. sorba került (mentsük is el rögtön). Ezt a VSCode mutatja nekünk a sorok száma mellett színesen kiemelve, hogy ezek új sorok. A bal oldali függőleges menüben pedig kiválasztottam Source Control menüpontot, ami jelzi, hogy jelenleg 1 fájl változott a legutóbb Github-ra push-olt változathoz képest. Mivel a "Changes" lenyíló lista alatt van most a fájlunk, ezért ez még a "working directory"-ban van. Futtathatnám újra a git add . vagy jelen esetben a git add readme.md parancsot és átkerülne a módosítás a "staging area"-ba, de megtehetjük ezt úgy is, hogy a fájl mellett a + jelre kattintunk, kevesebbet kell gépelni... (amúgy, ha rákattintunk a Changes alatt a fájl nevére, akkor megnyitja a fájlt a VSCode egy osztott ablakban és kiszínezi nekünk, hogy mi változott a fájlban:

Kattintsunk a + jelre a fájl neve mellett. Kis gondolkodás után most már nem a "Changes" alatt lesz a fájlunk neve, hanem a "Staged Changes" részben. Ismét írhatnánk a Terminal-ba a git commit -m "message" parancsot, de megtehetjük mindezt úgy is, hogy a "Staged Changes" feletti Message szövegdobozba írjuk be a váloztatáshoz tartozó üzenetet, majd a felette lévő ✔ (pipát). Ekkor megjelenik egy gomb ugyanott a következő szöveggel: "Sync Changes 1". Ezt megnyomva, gyakorlatilag a háttérben egy git push utasítás hajtódik végre (esetleg rákérdez, hogy biztos akarjuk-e push-olni a változtatást és rányomhatunk, hogy OK és hogy többet ne jelenjen meg ez az ablak).

Újra megnézhetjük a https://github.com/gludovatza/myfirstsite oldalt és láthatjuk, hogy most már 2 commit-ünk van. A fájllistában a readme.md fájl mellett látható, hogy melyik commit-tel módosult utoljára és akár részletesen tudjuk böngészgetni az adott commit-ok érintett módosításait, fájljait is, valamint egy fájl történetét is meg tudjuk nézni, hogy milyen commitek milyen változásokat hajtottak végre rajtuk... egyelőre nekünk most elég ennyire ismernünk a Github-ot és a verziókövetést. A későbbiekben adott helyen, ahol releváns, úgyis visszatérünk még a finomságaira.

Még egy megjegyzés a végére, hogy ha a VSCode-tól mondjuk több segítséget várnánk el a Git-es verziókövetés segítésére, akkor a Gitlens kiterjesztést érdemes lehet telepíteni. (VSCode-ban nagyon hasonlóan működnek a kiterjesztések mint mondjuk a Firefox-ban vagy a Chrome-ban, kipróbálhatjuk őket, aztán ha mégsem tetszenek, akkor lehet őket uninstall-álni).