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:
A verziókövetés alapfogalmai
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:
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).