Kodėl Git tapo standartu programuotojų pasaulyje
Prisimenu savo pirmąsias dienas programuojant – failai pavadinimu „projektas_final.zip”, „projektas_final_TIKRAI_GALUTINIS.zip”, „projektas_final_TIKRAI_GALUTINIS_v2.zip”. Skamba pažįstamai? Tai klasikinis scenarijus, kurį išgyvena kiekvienas pradedantis programuotojas, dar nesusipažinęs su versijų kontrolės sistemomis. Git atsirado kaip išgelbėtojas nuo šio chaoso, ir šiandien jį naudoja beveik kiekviena programavimo komanda pasaulyje.
Git sukūrė pats Linus Torvalds 2005 metais, kai jam prireikė efektyvaus būdo valdyti Linux branduolio kūrimą. Nuo tada ši sistema tapo neatsiejama programavimo proceso dalimi. Tačiau daugeliui pradedančiųjų Git atrodo kaip kažkas bauginančio – pilna keistų komandų, nesuprantamų terminų ir potencialių galimybių viską sugadinti. Gera žinia – tai tik iliuzija. Realybėje jums reikia išmokti vos keliolika pagrindinių komandų, kad galėtumėte produktyviai dirbti.
Pirmieji žingsniai: Git instaliavimas ir konfigūracija
Prieš pradedant naudoti Git, jį reikia įsidiegti. Linux ir macOS sistemose Git dažnai jau būna įdiegtas, o Windows naudotojams reikės atsisiųsti instaliatorių iš oficialios svetainės. Patikrinti, ar Git jau įdiegtas, galite terminale įvedę git --version.
Po instaliavimo pirmiausia reikia susikonfigūruoti savo tapatybę. Tai svarbu, nes kiekvienas jūsų atliktas pakeitimas (commit) bus pažymėtas jūsų vardu ir el. paštu:
git config --global user.name "Jūsų Vardas"
git config --global user.email "[email protected]"
Šie nustatymai išlieka visam laikui, todėl jų nereikės kartoti kiekvieną kartą. Dar vienas naudingas nustatymas – numatytasis teksto redaktorius. Jei nenorite naudoti Vim (kuris gali būti gana sudėtingas pradedantiesiems), galite nustatyti ką nors paprastesnio:
git config --global core.editor "nano"
Arba, jei naudojate Visual Studio Code:
git config --global core.editor "code --wait"
Repozitorijos kūrimas ir klonimas
Yra du pagrindiniai būdai pradėti dirbti su Git: sukurti naują repozitoriją arba klonuoti esamą. Jei kuriate naują projektą nuo nulio, atidarykite terminale projekto aplanką ir įveskite:
git init
Štai ir viskas! Dabar jūsų aplankas yra Git repozitorija. Techniškai Git sukūrė paslėptą .git aplanką, kuriame saugoma visa versijų kontrolės istorija ir konfigūracija.
Dažniau tačiau teks klonuoti jau egzistuojančią repozitoriją, pavyzdžiui, iš GitHub. Tam naudojama git clone komanda:
git clone https://github.com/vartotojas/projektas.git
Ši komanda ne tik atsisiunčia visus projekto failus, bet ir visą jo istoriją – kiekvieną pakeitimą, kurį kada nors atliko bet kuris projekto kūrėjas. Tai viena iš Git stiprybių – turite pilną projekto istoriją savo kompiuteryje, todėl galite dirbti neprisijungę prie interneto.
Kasdienės darbo komandos: add, commit, status
Dabar pereikime prie trijų svarbiausių komandų, kurias naudosite kiekvieną dieną. Pirma – git status. Ši komanda parodo dabartinę jūsų repozitorijos būseną: kokie failai pakeisti, kokie paruošti įrašymui (commit), kokioje šakoje (branch) esate. Įpratę nuolat naudoti git status – tai kaip žiūrėti į žemėlapį prieš žengiant kitą žingsnį.
Kai pakeičiate failus savo projekte, Git juos pastebi, bet automatiškai neįtraukia į kitą commit. Pirma reikia nurodyti, kuriuos pakeitimus norite įtraukti, naudojant git add:
git add failas.txt
Arba, jei norite pridėti visus pakeistus failus:
git add .
Taškas čia reiškia „viskas dabartiniame aplanke”. Būkite atsargūs su šia komanda – kartais netyčia galite pridėti failų, kurių nenorite versijų kontrolėje (pavyzdžiui, slaptažodžių, laikinų failų ar kompiliavimo rezultatų). Tam ir reikalingas .gitignore failas, bet apie tai vėliau.
Po to, kai failai pridėti, laikas juos įrašyti į istoriją su git commit:
git commit -m "Pridėtas prisijungimo funkcionalumas"
Commit žinutė (po -m vėliavėlės) turėtų būti aiški ir aprašyti, ką pakeitėte. Venkite žinučių kaip „pataisymai” ar „update” – po kelių mėnesių nei jūs, nei jūsų kolegos nesuprasite, kas buvo padaryta. Geresnės žinutės pavyzdžiai: „Ištaisyta klaida prisijungimo formoje”, „Pridėtas el. pašto validavimas”, „Optimizuotas duomenų bazės užklausų greitis”.
Darbas su nuotolinėmis repozitorijomis
Vienas iš didžiausių Git privalumų – galimybė lengvai bendradarbiauti su kitais. Tam naudojamos nuotolinės repozitorijos (remote repositories), dažniausiai talpinamos GitHub, GitLab ar Bitbucket platformose.
Komanda git push išsiunčia jūsų lokalius commit’us į nuotolinę repozitoriją:
git push origin main
Čia origin yra numatytasis nuotolinės repozitorijos pavadinimas, o main (arba master senesnėse repozitorijose) – šakos pavadinimas. Pirmą kartą darydami push, gali tekti nurodyti, kad jūsų lokali šaka turėtų sekti nuotolinę:
git push -u origin main
Vėliavėlė -u nustato upstream ryšį, todėl ateityje galėsite tiesiog rašyti git push be papildomų argumentų.
Atvirkštinė operacija – git pull – atnaujina jūsų lokalią repozitoriją pakeitimais iš nuotolinės:
git pull origin main
Įpratę daryti git pull prieš pradedant dirbti kiekvieną dieną. Tai užtikrina, kad turite naujausią kodo versiją ir sumažina konfliktų tikimybę. Jei dirba keletas žmonių tame pačiame projekte ir visi keičia tuos pačius failus, Git kartais negali automatiškai sulieti pakeitimų – tada atsiranda merge konfliktai, kuriuos reikia išspręsti rankiniu būdu.
Šakos: kaip dirbti su skirtingomis funkcijomis vienu metu
Šakos (branches) yra viena galingiausių Git funkcijų. Pagalvokite apie jas kaip apie lygiagrečias realybes jūsų projekte. Galite sukurti naują šaką eksperimentams, naujų funkcijų kūrimui ar klaidų taisymui, nerizikuodami sugadinti veikiančio kodo.
Sukurti naują šaką ir į ją persijungti:
git checkout -b nauja-funkcija
Arba naujesniuose Git versijose (nuo 2.23):
git switch -c nauja-funkcija
Dabar visi jūsų commit’ai bus šioje naujoje šakoje, o pagrindinė main šaka liks nepaliesta. Tai ypač naudinga komandiniame darbe – kiekvienas gali dirbti savo šakoje, o vėliau sulieti (merge) pakeitimus į pagrindinę šaką.
Peržiūrėti visas šakas:
git branch
Persijungti į kitą šaką:
git checkout main
Arba:
git switch main
Kai baigiate darbą šakoje ir norite ją sulieti su pagrindine, pirmiausia persijunkite į pagrindinę šaką, o tada naudokite git merge:
git switch main
git merge nauja-funkcija
Jei šaka jums nebereikalinga, galite ją ištrinti:
git branch -d nauja-funkcija
Profesionaliose komandose dažnai naudojama tokia praktika: main šaka visada turi veikiantį kodą, develop šaka naudojama aktyviam kūrimui, o kiekviena nauja funkcija ar klaidos taisymas kuriamas atskiroje šakoje su aprašomuoju pavadinimu, pavyzdžiui, feature/user-authentication ar bugfix/login-error.
Laiko mašina: kaip grįžti atgal ir peržiūrėti istoriją
Vienas didžiausių versijų kontrolės privalumų – galimybė keliauti laiku. Padarėte klaidą? Norite pamatyti, kaip kodas atrodė prieš savaitę? Git tai leidžia padaryti.
Komanda git log parodo visą commit’ų istoriją:
git log
Tai gali būti gana daug informacijos, todėl dažnai naudojamas sutrumpintas variantas:
git log --oneline
Kiekvienas commit turi unikalų identifikatorių (hash) – ilgą simbolių seką. Norėdami pamatyti, kas buvo pakeista konkrečiame commit’e:
git show abc1234
Jei norite grįžti prie ankstesnės būsenos, yra keletas būdų. Saugiausias – sukurti naują šaką nuo seno commit’o:
git checkout abc1234 -b senoji-versija
Arba, jei norite visiškai atšaukti paskutinius pakeitimus (ATSARGIAI – tai ištrins jūsų neišsaugotus pakeitimus):
git reset --hard abc1234
Saugesnė alternatyva – git revert, kuri sukuria naują commit’ą, atšaukiantį ankstesnio commit’o pakeitimus:
git revert abc1234
Dar viena naudinga komanda – git diff, rodanti skirtumus tarp versijų:
git diff – parodo nesaugotus pakeitimus
git diff --staged – parodo pakeitimus, paruoštus commit’ui
git diff abc1234 def5678 – parodo skirtumus tarp dviejų commit’ų
Praktiniai patarimai ir dažniausios klaidos
Dirbant su Git, yra keletas dalykų, kuriuos verta žinoti iš anksto, kad išvengtumėte galvos skausmo.
Naudokite .gitignore failą. Tai specialus failas, kuriame išvardijate, ko Git neturėtų sekti. Tipiškai ten įtraukiami kompiliavimo rezultatai, priklausomybių aplankai (kaip node_modules), konfigūracijos failai su slaptažodžiais, IDE nustaymų failai. GitHub turi puikią .gitignore šablonų kolekciją įvairioms programavimo kalboms.
Commit’inkite dažnai, bet logiškai. Geriau padaryti kelis mažus commit’us nei vieną milžinišką su žinute „daug pakeitimų”. Kiekvienas commit turėtų reprezentuoti vieną loginį pakeitimą. Jei commit žinutėje naudojate žodį „ir”, tikriausiai reikėtų padaryti du atskirus commit’us.
Visada darykite pull prieš push. Tai išvengs daugelio konfliktų ir problemų. Įpratę pradėti darbo dieną su git pull.
Nebijokite šakų. Jos pigios ir lengvai kuriamos. Eksperimentuojate? Sukurkite šaką. Neįsitikinę, ar pakeitimas veiks? Sukurkite šaką. Blogiausiu atveju tiesiog ją ištrinkite.
Niekada nedarykite force push į pagrindinę šaką. Komanda git push --force gali perrašyti kitų žmonių darbą ir sukelti didelių problemų. Jei manote, kad jums reikia force push, pirmiausia pasikalbėkite su komanda.
Mokykitės iš klaidų. Kažką sugadinote? Tai normalu. Git turi daug saugiklių, ir beveik visada galima viską atstatyti. Komanda git reflog parodo visų jūsų veiksmų istoriją ir gali išgelbėti net iš, atrodytų, beviltiškų situacijų.
Kelionės su Git pradžia, o ne pabaiga
Šios komandos sudaro maždaug 80% to, ką naudosite kasdieniniame darbe su Git. Taip, yra dar šimtai kitų komandų, vėliavėlių ir galimybių – rebase, cherry-pick, stash, submodules ir daugybė kitų. Bet nebūtina jų visų išmokti iš karto.
Pradėkite nuo šių pagrindų. Sukurkite testinę repozitoriją ir eksperimentuokite. Padarykite commit’us, sukurkite šakas, sulieti jas, padarykite klaidų ir ištaisykite jas. Git yra įrankis, kurį išmokstate praktikuodami, o ne skaitydami dokumentaciją.
Kai šios komandos taps antra prigimtimi, natūraliai pradėsite susidurti su sudėtingesniais scenarijais ir poreikiais. Tada bus tinkamas laikas mokytis pažangesnių funkcijų. O kol kas – tiesiog pradėkite naudoti Git savo projektuose. Po kelių savaičių negalėsite įsivaizduoti, kaip be jo gyvenote.
Ir atminkite: kiekvienas patyręs programuotojas kažkada buvo ten, kur esate dabar – žiūrėjo į terminalo langą su git komanda ir nežinojo, ką daryti toliau. Skirtumas tik tas, kad jie nepasidarė ir toliau mokėsi. Dabar jūsų eilė.
