Modul de lucru al echipelor de dezvoltare software pare că a devenit tot mai complex o dată cu trecerea timpului, din cauza integrării a tot felul de unelte care la prima vedere nu au legătură cu programarea.
Dacă ești la început de drum e posibil să te întrebi la un moment dat de ce ai nevoie de atât de multe unelte când dezvolți o aplicație, când tu de fapt tot ce vrei e să scrii cod.
Problema
Una din principalele probleme pe care inginerii software a fost nevoie să o rezolve era versionarea codului.
Gândește-te la următoarea situație: într-o echipă sunt 5 oameni, fiecare lucrează individual pe propriul laptop, dar contribuie la același proiect.
Cum se face sincronizarea codului între toți acești 5 oameni?
Cine centralizează codul, care este cea mai recentă versiune și cine o are?
În cazul în care 2 membri ai echipei fac modificări pentru scopuri independente pe aceleași linii de cod, cine suprascrie pe cine sau cine face agregarea ambelor modificări astfel încât codul să fie funcțional și să cuprindă ambele schimbări de logică?
Ce este git și cum ne ajută
Git este un sistem de versionare distribuit. Adică fiecare programator poate lucra individual fără ca schimbările făcute de el în cod să afecteze pe alții.
Pentru că fiecare programator are propria copie locală a tot codului sursă a unei aplicații care poartă numele de repository sau loc de depozitare, dacă vrei, în cazul ăsta local.
Un repository este modul prin care git ține seama de toate schimbările tale aduse codului, prin ceea ce poartă numele de commits (comiteri), creând astfel un istoric al tuturor schimbărilor.
Ce este GitHub
Aici intră în joc componenta denumită remote repository, care în cazul de față este GitHub.
Acest remote repository, sau depozit la distanță, e doar un loc centralizat în care se stochează codul cu toate schimbările provenite de la toți membri echipei.
Astfel mai mulți membri ai echipei își transmit schimbările făcute de fiecare în parte “împingând” versiunea lor locală de cod în acel remote repository, ca mai apoi să “tragă” versiunea integrată înapoi în repository-ul local.
În cazul în care 2 dintre ei au modificat conținutul aceluiași fișier, va fi generat ceea ce poartă numele de “conflict” și unul din developeri va trebui să aleagă versiunea finală a fișierului, să aleagă care dintre schimbări să rămână: a lui, a celuilalt sau ambele dacă e posibil.
Cum publici codul pe GitHub
Dacă ai git deja instalat la tine pe PC, tot ce trebuie să faci pentru a împinge cod deja existent în GitHub este să:
- Creezi un cont pe GitHub
- Creezi un repository pe GitHub
- Creezi un repozitory local
- Să adaugi fișierele pe care git vrei să le urmărească
- Să faci un commit și apoi să împingi codul
Sună complicat, dar chiar nu e, dacă ai făcut deja primii 2 pași, tot ce trebuie să faci e să mergi în directorul unde ai fișierele ale căror istoric vrei să-l urmărești și să execuți într-un terminal comenzile:
git init
git add [numele fișierului, ex. index.js]
sau
git add . (punct) pentru a “urmări” toate fișierele din director
git commit -m “primul meu commit”
git remote add origin <https://github.com/contul-tău/nume-repository.git>
unde origin este efectiv numele repository-ului. Îl poți denumi cum vrei, dar origin e standard.
git push -u origin main
observă comanda push (împinge)
Acum codul tau va fi deja împins spre GitHub și îl vei putea vedea acolo.
Dacă cineva a făcut o actualizare pe care a împins-o deja în GitHub, tot ce trebuie să faci pentru a o aduce și la tine local este:
git pull
Concluzie
Acum să sumarizăm, diferența între git și GitHub e aceea că GitHub e doar un loc unde se centralizează și se urmăresc schimbările într-un proiect, iar git e tehnologia ce ne permite să urmărim aceste schimbări. GitHub la rândul lui folosește tot git, doar că joacă un rol de genul “server pentru cod”.
Pe lângă GitHub, există multe alte platforme de genul pe piață:
- Bitbucket
- Gitlab
- Azure DevOps
și altele, dar astea 3 sunt de departe cele mai cunoscute. Toate sunt locuri unde să centralizăm schimbările aduse pe proiect, pe baza tehnologiei denumite git.
