Sunteți pe pagina 1din 18

SUPORT DE CURS

GIT Essential

1|P a ge
Cuprins

Cuprins .................................................................................................................. 1
Termeni tehnici .................................................................................................... 3
1. Versionarea ...................................................................................................... 4
2.Tool-uri de care avem nevoie ........................................................................... 6
3. Crearea primului repository si clonarea lui.................................................... 7
4. Flow-urile principale in GIT ............................................................................. 8
5. Rezolvarea Conflictelor ................................................................................... 9
6. Branch-uri .......................................................................................................11
7. Merge ..............................................................................................................12
8. GIT Stash ........................................................................................................13
9. GIT Ignore .......................................................................................................14
10. GIT Discard ...................................................................................................16
11. Checkout la un Commit vechi .....................................................................17
Contact................................................................................................................18

2|P a ge
Termeni tehnici
Repository - Container unde se stocheaza fisierele unui proiect
Branch - O ramura diferita de dezvoltare
Commit - Salvarea modificarilor in Repository-ul Local
Push - Salvarea modificarilor in Repository-ul Remote
Pull - Aducerea modificarilor din Repository-ul Remote in cel Local
Merge - Incorporarea modificarilor din 2 Branch-uri intr-unul singur

3|P a ge
1. Versionarea
GIT este un sistem de versionare al codului. Dar ce inseamna asta mai exact? E
simplu, folosind acest sistem un programator sau o intreaga echipa pot sa tina un
registru exact al fiecarei schimbari din codul proiectului lor. Poti de asemenea sa te
intorci la oricare versiune de cod din trecut daca e nevoie.

GIT-ul e bazat pe o arhitectura distribuita lucru care e extraordinar de folositor.


Practic in loc sa ai tot codul proiectului tau intr-un singur loc, asa cum se intampla
in cazul SVN, fiecare programator are pe calculatorul sau o copie in intregime a
tuturor versiunilor si modificarilor.

4|P a ge
In acest moment GIT este o tehnologie folosita in aproape toate companiile de IT
fiind independenta de codul pe care il scriu echipele de programare. Fie ca dezvolta
aplicatii mobile sau web, scrise in Java, Python sau pur si simplu in HTML si CSS,
GIT-ul este ceva ce nu trebuie sa lipseasca din CV-ul nici unui IT-ist.

5|P a ge
2.Tool-uri de care avem nevoie
In primul rand e nevoie sa instalam GIT-ul (sistemul de versionare) pe calculatorul
nostru. E bine ca dupa instalare sa dam si un restart calculatorului nostru pentru a
ne asigura ca totate setarile s-au facut corect.
Link: https://git-scm.com/

In continuare avem nevoie de un cont pe BitBucket.org (un tool asemanator cu


GitHub). Acest cont ne va fi de folos atunci cand instalam SourceTree (toolul
principal cu care vom lucra).
Link: https://bitbucket.org

Dupa ce avem contul de BitBucket putem sa descarcam aplicatia SourceTree care


este un client pentru GIT si sa o instalam.
Link: https://www.sourcetreeapp.com/

Ultimul pas este acela de a crea un cont pe GitHub unde vom avea Repository-ul
Remote, adica acel container in care vom avea un back-ul al codului nostru.
Link: https://github.com/

6|P a ge
3. Crearea primului repository si
clonarea lui
Un repository este un container in care vom tine un proiect. Acel repository poate
sa fie LOCAL daca se afla pe calculatorul nostru sau REMOTE daca se afla pe
GitHub, BitBucket sau alte servere asemanatoare.

Primul pas este ca creem un repository nou pe GitHub. Il vom face PRIVAT, adica
disponibil doar pentru noi. Dupa ce am creat acest repository va trebui sa il clonam
pe calculatorul nostru. Inainte de a-l clona trebuie sa ne asiguram ca avem o
legatura securizata intre PC si GitHub. Pentru aceasta legatura folosim niste chei
SSH.

Secure Shell (SSH) este un protocol securizat care asigura transferul de fisiere
intre dispozitive. Aceste chei sunt practic niste “parole” care doar impreuna pot sa
ofere acces. Avem o cheie publica, pe care o putem da oricui (in cazul nostru o dam
GitHub-ului) si o cheie privata pe care o pastram doar noi (secret).

7|P a ge
4. Flow-urile principale in GIT
Atunci cand folosim GIT-ul, cel mai des vom aplica 2 flow-uri principale.

Salvarea codului nostru in Repository-ul Remote (GitHub)

1. Fisierele noi si cele modificate vor aparea in zona de Unstaged Files. Va


trebui sa le mutam pe toate in zona de Staged Files (fisiere pe care vrem sa
le trimite in Repository-ul Local si in cel Remote).
2. In zona de mesaje adaugam un mesaj cat mai descriptiv despre ce am
facut si apoi apasam butonul Commit. In acest moment modificarile
noastre au ajuns in Repository-ul Local.
3. Apasam butonul Pull pentru a trimite modificarile si in Repository-ul
Remote (GitHub).

Aducerea pe calculatorul nostru a codului din Repository-ul Remote (GitHub)

1. Apasam butonul de Pull pentru a aduce modificarile noi (daca exista si


sunt facute de altcineva) din Repository-ul Remote (GitHub) pe calculatorul
nostru.

8|P a ge
5. Rezolvarea Conflictelor
Se intampla uneori ca 2 persoane sa lucreze in acelasi timp in acelasi fisier si
poate chiar la aceeasi linie de cod. In cazul acesta a doua persoana care va da un
Push la codul sau catre GitHub va primi o eroare care este de fapt un conflict in
cod. De obicei aceste conflicte apar rar si sunt cauzate de lipsa de comunicare
dintre membrii echipei.

Ca sa rezolvam aceste conflicte este nevoie sa merge folosind un editor de cod in


fisierul mentionat in SourceTree si sa facem niste editari manuale. In codul de mai
jos avem un conflict din cauza ca un membru al echipei a adugat un link dar a uitat
sa ii puna si o valoare in atributul de href. Al doilea membru al echipei a adaugat si
el acelasi link dar nu a scris corect ancora. In acest caz prin merge va trebui sa
combinam cele 2 versiuni in 1 care sa contina partile corecte de cod de la ambii
membrii ai echipei:

1. <<<<<<< HEAD
2. <a href=”http://www.google.com”>Gole</a>
3. =======
4. <a href=””>Google</a>
5. >>>>>>> branch-a

9|P a ge
Rezultatul final al acestui merge va fi o singura linie de cod. Obervati ca am sters
complet liniile 1, 3 si 5 lucru pe care trebuie sa il facem la fiecare conflict. Acestea
au rolul de a demarca codul celor 2 persoane care au generat conflictul.
1. <a href=”http://www.google.com”>Google</a>

10 | P a g e
6. Branch-uri
In momentul in care incepem lucrul la un proiect este bine sa organizam putin ce
se intampla in GIT. Pentru asta va fi nevoie de cateva branch-uri de lucru. Un
branch este o ramura secundara de deszvoltare a proiectului.

Sa spunem ca intr-o zi te decizi sa implementezi o functionalitate nou de login.


Creezi un branch nou si faci commit/push doar pe acest branch pana in momentul
in care login-ul este terminat si testat.

Este recomandat ca fiecare functionaliate noua sau bug mai important sa fie facut
pe un branch nou. Acolo sa fie facuta implementarea completa si testarea, iar apoi
acel Branch secundar se poate aduce in Branch-ul principal (in cazul nostru
master).

11 | P a g e
7. Merge
In momentul in care decidem ca am terminat munca la o functionalitate noua si
aceasta este stabila si testata putem sa o aducem in Branch-ul principal (in cazul
nostru master).

Prin merge aducem practic tot codul la care am lucrat intr-un Branch secundar in
Branch-ul principal (in cazul nostru master).

Un Merge nu pastreaza istoricul Commit-urilor. Asta inseamna ca daca pe Branch-


ul nostru secundar numit login am facut 3 Commit-uri, in momentul in care vom
face Merge in Branch-ul principal master toate cele 3 Commit-uri se vor contopi
intr-unul singur.

12 | P a g e
8. GIT Stash
Prin Stashing putem sa stocam temporar modificarile pe care le-am facut in codul
nostru fara sa le adaugam intr-un Branch sau sa le trimitem in Repository-ul
Remote.

Dupa ce creem un Stash putem face doua lucruri cu el:

1. Sa aplicam Stash-ul pe un Branch. Putem sa creem un nou Branch si in


acesta aducem codul din Stath daca dorim sa il folosim sau sa il
modificam in continuare.
2. Sa stergem acel Stash daca nu mai avem nevoie de el.

13 | P a g e
9. GIT Ignore
Prin Ignore putem specifica ce fisiere sa nu fie vizibile pentru sistemul GIT. In acest
fel putem avea in folderul proiectului nostru fisiere pe care sa le modificam, iar
acest modificari sa nu fie vizibile in momentul unui Commit.

Putem sa folosim Ignore in cazul unor fisiere de configurare specifice


calculatorului nostru, fisiere cu parole sau fisiere readme de care avem nevoie doar
noi.

In momentul in care folosim Ignore pentru prima data, in folderul proiectului nostru
va fi creat un fisier nou cu numele .gitignore in care vom avea specificate fisierele
pe care le ignoram. In acest fisier putem sa specificam si anumite patter-uri prin
care sa ignoram mai multe fisiere care au parti din nume sau extensii in comun.

Exemple de pattern-uri:

Pattern Descriere

config.txt Ignore doar fisierul config.txt

*.log Ignora toate fisierele care au extensia .log

14 | P a g e
*.log Ignora toate fisierele care au extensia .log cu exceptia
!important.log fisierelor cu numele important.log

debug?.log Ignora toate fisierele care incep cu debug si au un


caracter random urmat de extensia .log. De exemplu:
debug0.log
debugg.log

Retineti ca acest fisier .gitignore trebuie trecut print-un Commit si Push.

15 | P a g e
10. GIT Discard
Discard este comanda prin care renuntam la modificarile facute intr-un
fisier sau grup de fisiere de la ultimul Commit si pana in prezent. E ca o
resetare a codului in acele fisiere.

16 | P a g e
11. Checkout la un Commit vechi

In orice moment ne putem intoarece la un Commit mai vechi avand tot istoricul
GIT-ului in SourceTree. Ca sa ne intoarcem la o versiune mai veche din codul nostre
pur si simplu trebuie sa dam dublu click pe mesajul Commit-ului in panoul central.

Ca sa ne intoarcem la versiunea de cod actuala e nevoie sa dam dublu click pe


numele Branch-ului nostru in meniul din stanga.

17 | P a g e
Contact
Pentru orice intrebare sau nelamurire te rog sa ma contactezi folosind
email-ul radhoovlogs@gmail.com.

De asemenea, te astept in comunitatea mea destinata pasionatilor de IT si


programare.

Youtube: YouTube.com/VlogDeIT
Blog: BlogDeIT.ro
Facebook: Facebook.com/VlogDeIT

18 | P a g e

S-ar putea să vă placă și