Bazele GIT și GitHub

De ce-ai avea vreodată nevoie de GIT? Pentru că vrei ca munca ta să poată la un moment dat să fie văzută, folosită și chiar extinsă de alții. Și pentru că vrei un sistem prin care să-ți salvezi munca în caz că pățește ceva calculatorul tău. Cea mai simplă variantă de folosire a GIT-ului e GitHub, așa că azi vom diseca aceste două concepte.

Imaginează-ți că GIT-ul e un sistem de salvări dintr-un joc – dacă lucrezi la un proiect și vrei să te poți întoarce în timp în anumite momente cheie în care codul tău și proiectul tău merge bine, sau când faci modificări majore (te bați fără succes cu un task „boss-level”). Chiar mai mult, dacă vrei să progresezi mai repede în joc, poți primi ajutor de la alți oameni doritori într-un sistem „multiplayer” ingenios care vin cu adăugiri la „salvările” tale. Mă rog, asta e o analogie destul de simplistă, hai să detaliem puțin folosind un exercițiu de imaginație.

În Evul Mediu al IT-ului, acum (doar) vreo 20 ani, programatorii în general și front end developerii în special foloseau unelte antice din alamă și bronz să scrie pe tăblii de piatră și uneori chiar pe suluri de papirus rodul muncii lor, iar acele tablete și suluri erau transportate de hamali sau caruri trase de animale până la librăriile unde erau folosite și stocate. Glumesc, nu era chiar așa, dar diferența dintre felul cum își salvau munca developerii acum 20 de ani față de cum o fac astăzi diferă la fel de mult cum diferă scrierea cuneiformă sau hieroglifele egiptene de un email.

Înainte, când construiai un site, trebuia să-l uploadezi pe server conectându-te direct la server prin protocolul FTP sau SFTP (adică File Transfer Protocol sau Secure File Transfer Protocol) și copiind efectiv fișierele. Poți face asta și azi, dar nu e la fel de eficient ca metodele mai moderne.

Înainte, munca ta, aplicația sau site-ul la care lucrai, exista în mod idependent și la tine și la colegii tăi pe calculatoare. De obicei era un ritual ca o dată pe săptămână (sau cu o frecvență aleasă de comun acord), dacă doi sau mai mulți oameni lucrau la aceleași fișiere și le modificau, să stea împreună (sau să-l lase pe cel mai senior dintre ei) să pună cap la cap toate modificările. Aceste modificări era necesar să funcționeze simultan în noua variantă de site, care mai apoi ajungea pe serverul „de producție” (adică cel public, accesibil de clienți și vizitatori). Cum? Păi copiat sau transferat prin FTP, imediat după această muncă de sincronizare a modificărilor tuturor membrilor echipei.

Nu cred că trebuie să îți spun cât de anevoios și stresant era procesul uneori, mai ales dacă erau zeci de membri în echipă. Și nu cred că trebuie să menționez că am evoluat substanțial de atunci.

Au existat mai multe tehnologii intermediare, cum ar fi Subversion sau BitKeeper, dar important este că în 2004, inventatorul și principalul contribuitor la Linux, Linus Torvalds, s-a săturat de problemele pe care le avea cu SCM-ul (Source Control Manager-ul) și a inventat unul nou, pe nume GIT.

GIT avea să devină cel mai bun și cel mai folosit sistem de control al surselor din lume, și e folosit la scară largă de 99.99% din companiile care fac software astăzi. E atât de bun, încât s-au fondat inclusiv întregi business-uri care s-au străduit să ofere GIT lumii întregi: unii gratuit (cum este GitHub), unii pe bani (cum sunt GitLab, Atlassian BitBucket sau alții).

Dar ca să înțelegi exact de ce e așa bun GIT-ul și la ce folosește, hai să intrăm în detalii.

Mai exact, ce e GIT și ce e GitHub?

Să presupunem că vrei să-ți faci un dressing în care să-ți pui toate hainele. Dacă dulapurile din dressing sunt GIT-ul, magazinele de mobilă sunt GitHub, GitLab sau BitBucket. GitHub, spre exemplu, seamănă cu IKEA pentru că e ieftin (în cazul GitHub-ului, gratis) și ți-l poți asambla singur, dar dacă-ți prinzi urechile și ai nevoie de ajutor poți plăti o echipă să-ți facă instalarea. Evident, poți plăti și un tâmplar artizan care să-ți construiască mobila la un standard destul de incert de calitate (adică să hostezi GIT-ul pe un server de-al tău sau de la hosting-ul tău), dar nu e neapărat cea mai bună soluție. O să vă las pe voi să găsiți analogia pentru GitLab și BitBucket. 🙂

Așadar, GIT-ul este software-ul. GitHub-ul este serviciul care oferă software-ul, cu sau fără bani.

De ce-ți trebuie ție GIT?

În stadiul în care ești acum (ca începător), tu n-ai nevoie neapărat de GIT, pentru că nu lucrezi într-o echipă. Așa s-ar deduce din ce-am scris mai sus, nu?

Ei bine, nu e chiar așa, pentru că GIT nu ajută doar la munca în echipă (unde nu doar că ajută, ci e indispensabil și esențial în ziua de azi). Ajută și din alte puncte de vedere.

1. GIT este un sistem distribuit. Ce-nseamnă asta? Înseamnă că în momentul în care te apuci de un proiect nou, poți ține toate fișierele din acel proiect într-un container de GIT, numit în engleză Repository (sau repo). Toate fișierele site-ului tău pot sta într-un astfel de repo, și unul din avantaje este că dacă repo-ul este creat de un serviciu extern cum este GitHub, este disponibil de oriunde din lume, de pe orice calculator. Asta înseamnă că dacă schimbi calculatorul pe care muncești și ți-ai făcut repo-ul public (sau te loghezi cu userul și parola de GitHub pe alt calculator), ai acces de oriunde la proiectul tău. Practic, asta permite și lucrul în echipă – poți da acces mai multor oameni la repo și cu toții vor putea să-l acceseze – sau dacă e public, îl poate accesa oricine îi știe adresa web. Și în plus, există și posibilitatea ca toți oamenii implicați în proiect să lucreze în ritmul lor la proiect, nu în același timp neapărat.
2. GIT este un sistem de control al surselor cu versionare. Asta-nseamnă că poți stoca pe perioadă nedeterminată și în același loc toate versiunile prin care a trecut site-ul tău și fiecare fișier în parte, ca să te poți întoarce oricând la o variantă anterioară. Implicit, dacă folosești GitHub, asta înseamnă că ai backup aproape infinit al proiectului în cloud și dacă ți se strică la un moment dat calculatorul (sau proiectul), îl poți recupera sau poți accesa și deploya o variantă mai veche a lui care funcționa bine.
3. GIT este un sistem colaborativ. Cum ziceam și la început, indiferent dacă în echipă sunteți 2 oameni sau 200, cu toții pot conviețui și contribui la același proiect fără prea mari bătăi de cap, datorită felului cum e gândit sistemul colaborativ. Vom vorbi mai în detaliu despre asta în viitor, însă ce trebuie să reții acum e că poți să-ți imaginezi GIT ca un copac special în care fiecare ramură este o clonă perfectă a ramurii din care se trage inițial. Apoi, fiecare ramură evoluează și se îmbunătățește. La un moment dat, ramura aia se întoarce în trunchi și asta face ca trunchiul să primească toate îmbunătățirile și noutățile cu care a venit acea ramură. Din punctul ăla încolo, îmbunătățirile astea se reflectă în toate noile ramuri care răsar ulterior. E un arbore care evoluează sub ochii tăi, pe măsură ce echipa lucrează la el să-l perfecționeze. Și din metafora asta a copacului vine și terminologia de „branch”, adică ramură. Din ramura sau branch-ul „main” (adică cel principal, trunchiul cum ar veni) poți crea oricând o ramură care clonează acest „main”, o poți împodobi cu modificări minunate, și mai apoi o poți contopi (sau merge-ui) înapoi în „main” ca să beneficieze toată lumea din echipă (și vizitatorii site-ului) de minunățiile făcute de tine.

Suficientă teorie! Hai să trecem la practică! Voi încerca să-ți explic cum funcționează GIT în mare, fără să intru prea mult în coding-ul pe care nu l-am început încă, folosind doar o metaforă vizuală. Apoi îți voi explica cum să folosești GIT ca să-ți faci experiența parcurgerii acestui curs de front end mai ușoară și mai interesantă.

Exemplu de funcționare a GIT-ului cu o metaforă

Să presupunem că ai două obiecte: o carte de colorat și un caiet de matematică. Combinația celor două obiecte reprezintă un proiect pe care vrei să-l versionezi cu ajutorul GIT. Asta-nseamnă că din momentul ăsta, cele două obiecte fac parte dintr-un repository de GIT.

Să mai presupunem că ai doi prieteni care vor să te ajute să colorezi întreaga carte de colorat și să rezolvi toate problemele de matematică din culegerea de admitere la facultate, și totul să se întâmple simultan. Spre deosebire de viața reală, unde cele două obiecte nu pot fi simultan în 3 locuri, așa încât toți cei 3 oameni implicați în proiect să lucreze în același timp și la colorat și la matematică, în lumea digitală se poate orice. Mai ales dacă folosești GIT.

Cu GIT, repo-ul tău poate fi clonat pe toate cele 3 calculatoare (adică al tău și ale prietenilor tăi) exact așa cum e acum. Din punctul ăsta, toți 3 puteți să vă apucați de treabă și să lucrați simultan la proiect.

Să presupunem că tu alegi să colorezi pagina 1 și 2 din cartea de colorat, dar și să rezolvi probleme de matematică de la 1 la 10. Înainte să te apuci de treabă, ca să nu viciezi branch-ul main al proiectului din GIT, adică varianta „principală” a acestuia, îți creezi un branch pe care-l denumești muncă-mixtă. Procesul de creare a branch-ului se numește „checkout” (vine din engleză, și e omonim cu expresia folosită când împrumuți o carte de la bibliotecă: to check out).

OK, deci ai făcut un checkout din branch-ul main în branch-ul tău personal, numit muncă-mixtă.

Cei doi prieteni ai tăi, Ion și Maria fac și ei același lucru, numai că-și numesc branch-urile început-ion și respectiv început-maria.

Din punctul ăsta încolo, fiecare poate să lucreze la altceva. Tu colorezi primele 2 pagini din carte și rezolvi primele 10 probleme, cum am zis. Ion colorează primele 4 pagini din carte și nu rezolvă nicio problemă de matematică. Maria, mai conștiincioasă, rezolvă probleme de matematică de la numărul 5 la numărul 20, și colorează prima pagină din cartea de colorat, neștiind că și tu ai făcut același lucru.

În momentul ăsta, Maria vrea să merge-uiască, adică să îmbine modificările ei în branch-ul principal, în main. Ca să poată face asta în mod civilizat, face o cerere, care se numește „pull request”. Practic, ea cere să se aplice modificările ei în branch-ul principal. Ca să fie sigură că n-a greșit, vă menționează pe tine și pe Ion ca revieweri ai pull request-ului, lucru care presupune ca voi să verificați munca ei și s-o aprobați. Procesul ăsta se numește „code review” și când amândoi vă dați acordul, branch-ul ei, numit început-maria se merge-uiește, se contopește cu branch-ul principal, adică main, și din punctul ăla încolo, main-ul conține pagina 1 colorată și problemele de la 5 până la 20 rezolvate.

În momentul ăsta, vrei și tu să-ți aduci aportul la proiect și faci un Pull Request pentru ca branch-ul tău, pe nume muncă-mixtă să se merge-uiască cu main-ul. Doar că intervine o problemă. Pentru ca tu să poți face merge corect, noul branch main trebuie adus în branch-ul tău pentru a reflecta noua sa stare. În momentul în care-l tragi la tine, constați că și tu și Maria ați colorat pagina 1 din cartea de colorat și ați rezolvat problemele 5-10. Va deveni responsabilitatea ta să decizi care e varianta corectă a colorării paginii 1 și a rezolvării problemelor 5-10.

De multe ori, fiindcă a trecut deja printr-un proces de code review, varianta „corectă” se consideră cea pe care ai adus-o din main la tine în branch, dar dacă ești convins că varianta ta e mai completă, ai puterea să suprascrii sau să completezi atât culorile din pagina 1 a cărții de colorat cât și rezolvările problemelor 5-10 de matematică. Odată ce ai terminat acest proces, care se numește „conflict resolution” (adică ad literam „rezolvarea conflictelor”), poți continua cu pull request-ul, numindu-i pe Ion și Maria revieweri în procesul de code review. Dacă Mariei nu-i place cum ai făcut conflict resolution pe pagina colorată de ea și-ți cere să faci modificări, tu trebuie să ajungi la o concluzie împreună cu ea și să decideți împreună care e varianta corectă de a colora prima pagină. Dacă e nevoie, trebuie să faci modificările necesare în pagină înainte să ți se aprobe pull request-ul. Odată aprobat, toate schimbările din branch-ul tău, inclusiv ultimele modificări, sunt merge-uite în main și main conține acum atât modificările tale cât și ale Mariei.

În fine, în acest moment vrea și Ion să facă un pull request. La rândul lui, el trebuie să-și aducă noul main la el în branch și să constate cu stupoare că primele 2 pagini din cele 4 colorate de el au conflicte. Pentru că ține minte că ați discutat pe larg despre pagina 1 și ați ajuns la o concluzie apropo de cum se colorează, el acceptă varianta din main a paginii 1, dar la pagina 2, pe care ai modificat-o doar tu, el combină culorile tale cu ale lui și apoi face pull request.

Odată ce code review-ul e finalizat, branch-ul main conține acum o combinație de muncă a tuturor celor 3 oameni implicați, cu modificări la care au contribuit toți 3 în măsuri diferite pe fiecare pagină de colorat sau problemă de matematică. Și uite așa, împreună ați colorat primele 4 pagini din cartea de colorat și ați rezolvat primele 20 probleme de matematică, fără să lucrați în același timp.

Acum că am explorat metafora din spatele unui GIT flow, hai să vedem concret cum poți tu să folosești GIT-ul chiar acum.

Concret, cum folosești GitHub să te ajute să devii front end developer?

1. Instalare și pregătire

Înainte de toate, dacă n-ai făcut asta deja, citește articolul precedent din Cursul de Front End pentru a vedea ce ai nevoie să-ți instalezi local ca să poți lucra pe front end de acum încolo. Lista include și un IDE, adică un editor de cod, preferabil Visual Studio Code, pe care vom începe să-l folosim intens din momentul ăsta pe tot parcursul cursului.

Apoi, mai avem ceva de instalat special pentru a folosi GIT.

Dacă folosești Windows, mergi la https://gitforwindows.org/, descarcă și instalează aplicația GIT de aici. Dacă nu, dă search pe Google după GIT for Mac sau GIT for Linux, depinzând de ce sistem de operare folosești.

Apoi, creează-ți un cont de GitHub, completând formularul de aici: https://github.com/join 

Nu în ultimul rând, instalează aplicația de source control de la GitHub, care se numește GitHub Desktop, de aici: https://desktop.github.com/

Apoi, în GitHub Desktop, loghează-te cu contul de GitHub pe care l-ai făcut (username și parolă).

Aceste trei bucăți din puzzle te vor ajuta să folosești GIT și GitHub într-un mod cât se poate de simplu ca să-ți stochezi temele pe care ți le voi da în acest curs, ca să-ți poată fi evaluate în code review de către participanții mai experimentați din comunitatea noastră de pe Discord.

Și chiar dacă nu vrei să folosești oportunitatea asta să-ți validezi tema pentru acasă, faptul că te obișnuiești să folosești GIT te va ajuta mult în viitorul tău job.

2. Primul tău proiect

Înainte de toate, trebuie să știi că poți să-ți faci repo-uri de GIT fie din proiecte deja existente fie de la zero, fără niciun fișier de început. Astăzi vom explora a doua variantă, și vom face un test cu un proiect complet nou.

Intră în GitHub și navighează în zona de Repositories spre butonul de New, sau intră direct în pagina https://github.com/new

Numele repo-ului este în același timp și slug-ul din URL, adică bucata din adresa web care definește proiectul, deci e nevoie să fie compus doar din litere mici, cifre sau liniuță, fără spații, litere mari sau caractere speciale.

Descrierea e opțională, dar utilă – însă o poți adăuga și ulterior. Și util este să lași repo-ul public dacă vrei să fie evaluat de colegii de breaslă. Restul opțiunilor sunt la alegerea ta. 🙂 Apasă pe Create repository și mergi mai departe.

În pagina asta vei vedea un buton verde pe care scrie Code, dacă dai click pe el îți va apărea un popup în care poți să copiezi link-ul din tab-ul HTTPS. Acest link, de forma: https://github.com/ViorelMocanu/ssg-test-1-astro.git (https două puncte slash slash github punct com slash userul tău de GitHub slash numele repo-ului cu extensia punct GIT la final) este adresa repo-ului.

Pentru a clona repo-ul la tine pe calculator, trebuie să deschizi Visual Studio Code. Ar trebui să-l ai deja instalat din lecția precedentă. În acest moment, e nevoie să decidem, însă, unde vor locui fișierele noului tău proiect la tine pe calculator.

Ca să fie foarte simplu, hai să alegem Desktop-ul. Voi presupune că folosești Windows. Apasă Click dreapta pe Desktop și alege opțiunea New > Folder. Denumește fișierul nou „proiecte” și apoi intră în el.

În acest folder vom pune primul nostru proiect folosind GitHub. Dacă ai instalat Visual Studio Code corect, când apeși click dreapta într-un spațiu gol din folder-ul curent, îți va apărea opțiunea Open with Code (pe Windows 11 e nevoie să apeși întâi Show more options). Dacă dai click pe ea, îți va deschide Visual Studio Code fix în folder-ul curent.

Alternativa ar fi să deschizi direct VSCode și să selectezi opțiunea Open Folder, să navighezi către folder-ul tău și să îi dai Open.

3. Primele comenzi pregătitoare de GIT

Acum că suntem în IDE, e momentul să îi spunem GIT-ului că folder-ul curent este „baza” repo-ului public pe care tocmai l-ai făcut. Cu alte cuvinte, să legăm fișierul local de pe desktop cu fișierele remote de pe GitHub.

Lucrul cu GIT și GitHub se poate face în mai multe feluri. Noi astăzi vom explora varianta universală, prin terminal sau consolă, însă dacă vrei, găsești aici ghidul despre cum să folosești interfața din GitHub Desktop ca să faci aceleași lucruri pe care le vom face noi în terminal. E ceva mai simplu, dar nu te ajută la proiecte mai mari, unde ai mai mulți pași necesari ca să poți face operațiunile pe care le vom face împreună.

Așadar, din Visual Studio Code, mergi în Terminal > New Terminal sau apasă Ctrl + Shift + ` (tasta din stânga lui 1 din stânga sus). Ar trebui să-ți apară un terminal nou și cursorul ar trebui să fie la capătul unui rând în care apare adresa completă a folder-ului în care te afli, spre exemplu, la mine apare: C:/Users/Viorel/Desktop/proiecte

În consolă poți scrie diverse comenzi pe care le poți executa apăsând tasta Enter. Ca să testăm că ai GIT-ul instalat corect și funcționează, prima comandă pe care ar trebui s-o rulăm este:

git --version (git spațiu minus minus version) – asta ar trebui să îți dea un răspuns tot în consolă cu versiunea curentă a GIT-ului tău instalat local. Ar trebui să observi că primul cuvânt este softul pe care vrem să-l rulăm, al doilea cuvânt de obicei este comanda, dar de data asta e doar un parametru de comandă – parametrii se scriu cu două liniuțe înainte.

În caz că n-ai apucat să instalezi GitHub Desktop și ca o măsură de precauție chiar dacă ai făcut-o, hai să definim userul și mail-ul contului tău de GitHub în configurarea git-ului local și prin consolă. Ca să facem asta, e nevoie să rulezi două comenzi:

git config --global user.name "USERUL_TAU" (ai grijă să fie două liniuțe înainte de global și userul tău să fie între ghilimele)

git config --global user.email "EMAILUL_TAU" (din nou, ai grijă ca parametrul global să aibă două liniuțe înainte de el și email-ul tău să fie între ghilimele duble)

Când vei face apoi primele operațiuni pe repo-ul de GitHub, sistemul îți va cere și parola de GitHub, pe care va trebui s-o introduci tot în consolă. Nu te speria dacă nu apar caracterele parolei în timp ce le introduci, e normal, ca să țină parola securizată.

Comenzile astea trebuie rulate exclusiv prima dată când rulezi comenzi de GIT.

De acum încolo explorăm comenzile pe care va trebui să le rulezi de fiecare dată când începi un proiect nou în GIT.

4. Primul tău repository de GIT

Acum, ca să legăm efectiv folder-ul local de repo-ul remote, adică de la distanță, mai exact din GitHub, trebuie să deschidem browser-ul și să mergem în repo-ul proaspăt creat. Mai ții minte unde ziceam că e butonul verde pe care scrie Code? Dă click pe el și apasă pe Copy ca să copiezi adresa proiectului, care ar trebui să fie de forma https://github.com/ViorelMocanu/ssg-test-1-astro.git

Acum, rulează comanda

git spațiu clone spațiu și apasă Ctrl + V

Asta-ți va rezulta într-o comandă de tipul:

git clone ADRESA_REPO_ULUI – spre exemplu:

git clone https://github.com/ViorelMocanu/ssg-test-1-astro.git

apoi apasă Enter, și ultimul rând din mesajul pe care-l primești trebuie să arate de forma Receiving objects: 100% (4/4), done.

Vei observa că în folder-ul Proiecte s-a generat un nou subfolder cu numele repo-ului. Ca să putem executa comenzi în proiect, trebuie să navigăm în consolă în interiorul folder-ului. Poți face asta cu comanda:

cd PRIMA_LITERĂ_A_REPO_ULUI și apoi tasta Tab

CD vine de la Change Directory, adică „schimbă directorul”.

Prima literă a repo-ului este, în cazul exemplului meu, tasta S.

Tasta Tab auto-completează numele folderului în care vrei să intri, dacă există un singur folder care începe cu S în cazul meu. Dacă ai mai multe foldere care încep cu S, trebuie să tastezi numele complet al folder-ului, cel puțin până când începutul e unic, și abia apoi va funcționa tasta Tab să autocompleteze ce-a rămas.

Apoi apasă Enter.

Gata! Acum, modificările pe care le faci local pot fi sincronizate către GitHub să le poată vedea oricine. Hai să testăm teoria asta.

5. Adaugă primul fișier în repo

Pentru a adăuga orice fișier în repo, în meniul din stânga din VSCode trebuie să deschidem folder-ul nou creat (care are numele repo-ului) și în funcție de opțiunile alese când ai creat repo-ul poți vedea sau nu deja niște fișiere în el: readme.md, license, .gitignore și așa mai departe.

Acum, creează un fișier nou apăsând Click dreapta și New file în meniul din stânga. Creează pentru început un fișier numit index.html

Acțiunea asta ți-a deschis automat fișierul în dreapta. Ca să testăm că merge, tastează în fișier următoarele două linii de cod:

<h1>Salutare, lume!</h1>

<p>Paragraf de test.</p>

Apoi apasă Ctrl + S ca să salvezi fișierul. Vezi aici un exemplu care-ți arată cum ar trebui să ai conținutul în fișier.

Ar trebui să te obișnuiești cu operațiunile astea, pentru că le vom face destul de des de acum încolo.

Avem, deci, un fișier nou pe care vrem să-l trimitem și în GitHub. Cum facem asta?

6. Sincronizează-ți fișierele locale cu cele din GitHub

În consolă, ca primă comandă înainte de orice altă comandă de modificare a surselor, îți recomand să începi cu:

git status

Această comandă îți va zice exact ce se întâmplă cu repo-ul tău local în comparație cu cel de pe GitHub.

Rulează acum comanda, și ar trebui să primești un mesaj care conține un rând de genul: Untracked files și apoi un fișier cu roșu, care e chiar cel nou creat: index.html – asta e bine, înseamnă că GIT deja și-a dat seama că sunt schimbări locale la tine pe calculator pe care le poți trimite în GitHub.

Ca să faci asta, în mod uzual, e nevoie să rulezi 3 comenzi succesive:

git add . – comanda git add adaugă în lista de fișiere urmărite de GIT orice fișier ai în folder-ul clonat din repo-ul din GitHub. În cazul ăsta, punctul e ca și cum ai selecta TOATE fișierele din folder-ul de lucru, din orice subfolder posibil. E cea mai frecvent folosită variantă a comenzii, și recomand s-o folosești de fiecare dată la început (excepțiile se vor discuta separat într-un modul dedicat Git-ului avansat).

Dacă rulezi din nou git status vei vedea că index.html-ul nostru din roșu a devenit verde și în stânga lui a apărut starea sau statusul fișierului: new file, semn că a intrat sub umbrela urmăriri GIT-ului. Asta e bine.

A doua comandă uzuală este cea în care unul sau mai multe fișiere sunt pregătite de upload în GitHub, împachetate în ceva ce se numește „commit”. Acest commit în mod ideal vine la pachet cu un mesaj care descrie în câteva cuvinte ce și de ce s-a comis. Există și niște standarde de scriere a acestor mesaje de commit, către care vei găsi link în descriere dacă vrei să le înveți (și eu îți recomand). Te invit, deci, să rulezi comanda:

git commit -m "feat: fisier nou de index"

-m e parametrul care semnalizează că imediat după următorul spațiu, în paranteze duble, urmează mesajul de commit, care ar trebui să fie scurt și cuprinzător. Mesajul din exemplul meu începe cu feat: pentru că ce-am făcut acum este un „feature” în engleză, adică un lucru nou și util, și genul ăsta de notație face parte din standardele despre care am zis adineauri.

Apoi, ca să te asiguri că acest commit ajunge în GitHub, e nevoie să-l „împingi” acolo, adică să-i faci:

git push

7. Câteva cuvinte despre branch-uri

În mod normal, între comenzile astea ar fi existat și cel puțin 2 comenzi adiționale sau diferite: una prin care am fi definit un „branch” nou, adică o ramură nouă care clonează la rândul ei „trunchiul” repo-ului, care e branch-ul numit main. În acest nou branch putem face oricâte modificări care nu se vor vedea în branch-ul main decât în momentul în care îl vom uni cu acesta, proces care se numește „merging”, cum am explicat mai devreme.

Branch-urile ajută mult la conlucrarea în echipă. În mod ideal, fiecare task sau problemă de rezolvat din proiect ar trebui să aibă câte un branch propriu. Asta permite fiecărui programator să lucreze la una sau mai multe branch-uri în timpul unui ciclu de producție sau sprint, ca să separe în mod cât mai curat munca necesară pentru fiecare problemă în parte și să contribuie la productivitatea echipei.

Nu vom intra azi în subiectul ăsta pentru că în timpul acestui curs vei lucra singur sau singură și ne-am complica destul de mult dacă am introduce și branch-urile în ecuație momentan.

8. Verifică sincronizarea

Acum că modificările sunt în GitHub, hai să le și verificăm, nu?

Intră în pagina repo-ului, dă un refresh (F5 sau Ctrl + R) și ar trebui să vezi nu doar fișierul nou adăugat (index.html) cât și conținutul acestuia, dând click pe el. Îl poți vedea și pe al meu aici: https://github.com/ViorelMocanu/ssg-test-1-astro/blob/main/index.htm – și asta e partea frumoasă, că odată codul tău ajuns în GitHub, e accesibil oricui vrea să se uite la el… spre exemplu mie și oamenilor din comunitate care îți pot verifica următoarele teme pentru acasă din acest curs. 🙂 Util, nu?

9. Pe foarte scurt, ce alte lucruri permite GIT-ul?

Trebuie să înțelegi că noi astăzi doar am zgâriat puțin suprafața acestui subiect. N-o să intrăm încă în ele, dar GIT-ul și GitHub-ul permit multe alte operațiuni și acțiuni care sunt menite să te ajute pe tine ca developer sau ca inginer de DevOps să îți faci treaba.

Am pomenit deja de branch-uri, care sunt lucruri de bază în care nu intrăm azi fiindcă e destul de mult de explicat și prefer să începem lucrul practic din curs și apoi să învățăm mai multe despre branch-uri când vine momentul.

Pe lângă branch-uri, cele mai importante facilități pentru tine în acest moment sunt issue-urile sau problemele în Română. În GitHub, când cineva vede probleme cu codul scris de altcineva, poate să-i lase un issue. Există o întreagă tehnică de scriere a issue-urilor corect, îți voi lăsa în descriere un link cu documentație pentru asta, dar pe scurt, orice idee de îmbunătățire sau orice problemă identificată în codul tău poate fi semnalată de altcineva, așa încât tu s-o repari. Poți apoi să legi și commit-uri sau branch-uri de rezolvarea respectivului issue, ca să fie notificați cei care au deschis issue-ul și cei care urmăresc issue-ul, să poată folosi apoi codul scris de tine știind că problema e rezolvată sau ideea e implementată.

Mai enumăr și alte lucruri pe care le poți face cu GIT și GitHub când ai nevoie, dacă vrei poți căuta despre ele să afli mai multe detalii:

Comenzile:

• git --help
  (asta e o comandă utilă dacă ai nevoie de o listă completă de comenzi posibile din GIT, pe care mai apoi le poți căuta pe Google să vezi ce fac)
• git init
• git log
• git diff
• git revert
• git reset
• git clean
• git rebase
• git branch
• git merge
• git remote
• git fetch
• git pull

Feature-urile:

• pull request
• GitHub Actions
• GitHub Labels
• GitHub Projects
• GitHub Milestones
• și nenumărate altele…

Recapitulare și temă

Felicitări, ai mai parcurs un articol din cursul de Front End Development gratuit în Română! Azi am învățat despre ce este GIT-ul și la ce folosește și ai aflat cum folosești GitHub ca să îți ții fișierele undeva cu acces public pentru a le expune și altor oameni sau ție din mai multe dispozitive și locații.

Ăsta e momentul perfect să îți dau o temă pentru acasă.

• Tema pentru tine este să treci prin pașii relevanți pe care i-am descris în articolul ăsta și să-ți creezi un repo nou. Atenție, nu e nevoie să-ți creezi un cont nou, doar un repo nou.
• Adaugă cele două fișiere pe care le poți downloada de aici (salvează cu Ctrl + S) și aici (salvează cu „download” sau click dreapta > save image as), și urcă-le apoi în repo-ul de pe GitHub folosind pașii descriși în articolul curent.
• Apoi pune link-ul către repo în comentarii, ca și cum l-ai clona, dar ATENȚIE MARE – fără https://github.com/ – doar ce urmează după (și asta pentru că WordPress e posibil să nu-ți permită să postezi link-uri în comentarii). Spre exemplu, dacă ar fi să pun în comentarii bucata corectă din repo-ul folosit ca exemplu în articol, ar trebui să pun doar: ViorelMocanu/ssg-test-1-astro.git
• Dacă ai dificultăți cu vreun pas de instalare, înregistrare sau execuție a comenzilor de GIT, scrie-mi mai jos în comentarii și voi încerca să te ajut.

Resurse adiționale

Mai găsești resurse utile pentru tine în următoarele link-uri (în engleză):

• Git cheat sheet – listă scurtă de comenzi utile
• Cum se scriu GitHub Issues
• Cum se scriu mesajele de commit + Conventional Commits
• Tutorial oficial de GitHub
• Tutorial de Git și GitHub de la FreeCodeCamp

Toate cursurile de Front End Development pentru începători pe care le-am scris până acum

1. Modulul 1: Noțiuni introductive
   • Introducere în Front End
   • Ce este și cum funcționează un calculator?
   • Ce este Internetul?
   • Cum funcționează Internetul?
   • Introducere în tehnologiile Web: HTML, CSS și JavaScript
   • Arhitectura informațională, baza UX-ului și a HTML-ului
   • Pregătește-te să codezi: software pentru Front End
   • Bazele GIT și GitHub (articolul curent)
2. Modulul 2: HTML pentru începători
   • Introducere și istoria HTML-ului
   • Block vs inline, link-uri și semantica textului
   • Mai multe în curând…
3. Modulul 3: CSS pentru începători
   • În curând…
4. Modulul 4: HTML pentru avansați
   • În curând…
5. Modulul 5: CSS pentru avansați
   • În curând…
6. Modulul 6: JavaScript pentru începători
   • În curând…
7. Modulul 7: Alte noțiuni utile
   • În curând…

Scrie-mi mai jos în comentarii cum ți se pare cursul până acum și ce alte module ai vrea să mai adaug pe viitor!