Git — este un sistem distribuit de control al versiunilor cu sursă deschisă, creat de Linus Torvalds în 2005 pentru dezvoltarea nucleului Linux. Spre deosebire de sistemele centralizate precum SVN, Git stochează o copie completă a depozitului pe fiecare dispozitiv al dezvoltatorului, permițând lucrul fără conexiune permanentă la server. Conform datelor Git SCM, 2024, Git este utilizat în peste 90% din toate proiectele comerciale de dezvoltare software.
Puncte principale
Git — este un sistem distribuit de control al versiunilor (VCS) care urmărește modificările în fișiere și permite mai multor dezvoltatori să lucreze simultan la același proiect. Spre deosebire de sistemele centralizate, în Git fiecare dezvoltator are o copie completă a depozitului, inclusiv întregul istoric al modificărilor, ceea ce face sistemul rezistent la pierderea datelor și nu necesită conexiune permanentă la serverul central.
Istoria Git a început în 2005, când Linus Torvalds a creat un nou VCS după ce compania BitKeeper a retras licența gratuită pentru sistemul său pentru dezvoltatorii nucleului Linux. Obiectivele au fost: viteza, simplitatea arhitecturii, suportul pentru dezvoltarea neliniară prin ramificare și distribuția completă. În 3 luni Torvalds a scris nucleul Git, iar după un an proiectul a trecut la auto-gestionare sub conducerea lui Junio Hamano.
Conform sondajului Stack Overflow (2024), 93,9% dintre dezvoltatorii profesioniști folosesc Git, ceea ce îl face sistemul de control al versiunilor dominant în industrie. Cel mai apropiat concurent — Subversion (SVN) — este utilizat doar în 5,2% dintre proiecte, preponderent în medii corporative mari cu procese centralizate.
Depozitul Git — este un director în care Git urmărește modificările tuturor fișierelor. În interiorul directorului se află un folder ascuns .git, unde sunt stocate toate obiectele sistemului: commituri, arbori, bloburi și referințe. Când un dezvoltator creează un commit, Git nu copiază fișierele în întregime — el creează o imagine instantanee (snapshot) a stării și salvează o referință la aceasta.
Fiecare commit conține: un hash SHA-1 unic (40 de caractere), o referință la commitul anterior (parent), autorul, data, mesajul commitului și o referință la arborele (tree) care descrie starea fișierelor la momentul commitului. Lanțul de commituri formează un graf aciclic direcționat, în care fiecare commit indică unul sau mai mulți părinți.
# Inițializarea depozitului
git init my-project
cd my-project
# Crearea commitului
echo "Hello, Git" > README.md
git add README.md
git commit -m "Initial commit"
# Vizualizarea istoricului
git log --oneline --graph --all
Git utilizează trei zone principale: working directory (fișierele pe disc), staging area (indexul unde ajung fișierele pregătite) și repository (istoricul commiturilor). Comanda git add mută modificările din directorul de lucru în staging, iar git commit fixează conținutul staging-ului în depozit. Această separare permite dezvoltatorului să adune un commit coerent dintr-un set de modificări, fără a fixa fiecare corecție separat.
Comenzile de bază Git acoperă 90% din operațiile zilnice ale dezvoltatorului. Comanda git clone creează o copie locală a depozitului la distanță, git pull preia modificările de pe server și le îmbină cu ramura curentă, iar git push trimite commiturile locale pe server. Aceste trei comenzi formează ciclul principal de lucru cu Git.
Pentru vizualizarea stării se folosește git status — arată care fișiere au fost modificate, care au fost adăugate în staging și care nu sunt urmărite. git diff afișează modificările concrete în fișiere înainte de adăugarea în staging. Mai jos este tabelul cu cele mai frecvent utilizate comenzi:
| Comandă | Acțiune | Exemplu |
|---|---|---|
| git clone | Copiază depozitul la distanță | git clone https://example.com/repo |
| git add | Adaugă fișiere în staging | git add src/main.kt |
| git commit | Fixează modificările în istoric | git commit -m "Fix login bug" |
| git push | Trimite commituri pe server | git push origin main |
| git pull | Preia modificări de pe server | git pull origin feature |
Pentru anularea modificărilor Git oferă mai multe opțiuni. git reset mută indicatorul ramurii la commitul specificat și poate reseta staging sau directorul de lucru. git revert creează un nou commit care anulează modificările commitului specificat — aceasta este o metodă sigură de anulare pentru ramurile comune, deoarece istoricul nu este rescris.
Ramurile în Git — sunt indicatori ușori și mobili către un anumit commit. Crearea unei noi ramuri nu copiază fișiere, ci doar creează un nou indicator, ceea ce face ramificarea practic instantanee. Ramura main (anterior master) — ramura principală a proiectului, care conține codul stabil, gata de lansare.
Practica standard este utilizarea Git Flow sau GitHub Flow. În Git Flow se folosesc ramurile: main (cod de lansare), develop (ramură de integrare), feature/* (funcții noi), release/* (pregătirea lansărilor) și hotfix/* (corecții urgente). GitHub Flow este mai simplu: doar main și ramuri feature, iar toate modificările sunt livrate prin Pull Request.
# Crearea și comutarea ramurii
git branch feature-auth
git checkout feature-auth
# sau cu o singură comandă:
git checkout -b feature-auth
# Lista ramurilor
git branch --list
git branch -a # toate ramurile, inclusiv cele șterse
# Ștergerea ramurii
git branch -d feature-auth
O proprietate importantă a ramificării Git — posibilitatea de cherry-pick: transferul unui commit individual dintr-o ramură în alta cu comanda git cherry-pick <hash>. Acest lucru este util când trebuie să transferați o corecție de eroare dintr-o ramură feature în release fără a îmbina întreaga ramură. Git suportă, de asemenea, rebazarea (rebase) și rebazarea interactivă (git rebase -i) pentru lipirea, reordonarea și editarea commiturilor.
Merge (îmbinare) creează un commit de îmbinare special care are doi părinți. Acest commit înregistrează faptul combinării a două ramuri și păstrează istoricul complet — se vede unde și când a avut loc îmbinarea. Merge păstrează istoricul în forma în care a fost creat, ceea ce simplifică auditul, dar face graful commiturilor mai complex.
Rebase (rebazare) în loc să creeze un commit de îmbinare, mută commiturile ramurii curente pe vârful ramurii țintă. Istoricul devine liniar — se creează impresia că dezvoltarea a avut loc secvențial. Însă rebase rescrie istoricul, modificând hashurile SHA-1 ale commiturilor, ceea ce îl face periculos pentru ramurile comune la care au acces alți dezvoltatori.
Recomandare privind alegerea: utilizați merge pentru ramurile publice unde istoricul este văzut de alți dezvoltatori (feature → develop), și rebase pentru lucrul local, când trebuie să aplicați modificări proaspete din main în ramura voastră feature înainte de a crea un Pull Request. Regula este simplă: dacă un commit a fost deja trimis pe server — nu-l rebazați.
Conflictul de îmbinare apare când Git nu poate combina automat modificările într-un singur fișier. Git marchează zonele conflictuale din fișier cu markeri speciali: <<<<<<< (modificările noastre), ======= (separator), >>>>>>> (modificările lor). Dezvoltatorul editează manual fișierul, selectând varianta dorită sau combinând ambele, și finalizează îmbinarea cu un commit.
Depozitul la distanță (remote) — este o copie a depozitului Git aflată pe server. GitHub, GitLab și Bitbucket sunt cele mai populare platforme de găzduire a depozitelor la distanță. Ele oferă interfață web pentru vizualizarea codului, gestionarea accesului, revizuirea codului și integrarea cu sisteme CI/CD.
În Git se pot configura mai multe depozite la distanță pentru un proiect. Implicit, remote-ul principal se numește origin. Comanda git remote add adaugă un nou remote, git fetch preia modificări fără îmbinare, iar git pull este o prescurtare pentru git fetch + git merge. Pentru lucrul cu codul prin Pull Request, dezvoltatorul creează un fork al depozitului, îl clonează, lucrează într-o ramură feature și trimite o cerere de îmbinare în depozitul original.
# Adăugarea depozitului la distanță
git remote add origin https://github.com/user/repo.git
# Vizualizarea depozitelor la distanță
git remote -v
# Trimiterea ramurii pe server
git push -u origin feature-auth
# Preluarea modificărilor de pe ramura la distanță
git pull origin main
Depozitele la distanță suportă etichetarea pentru marcarea versiunilor de lansare. Etichetele pot fi ușoare (doar un indicator către un commit) și adnotate (conțin metadate: autor, dată, mesaj). Etichetele adnotate sunt recomandate pentru versiunile de lansare, deoarece transmit informații complete despre versiune și pot fi semnate cu cheie GPG pentru verificarea autoratului.
Git Worktree permite lucrul simultan cu mai multe ramuri în directoare diferite fără a comuta între ele. Comanda git worktree add ../feature-auth feature-auth creează un nou director de lucru feature-auth, unde se poate scrie cod fără a schimba ramura în directorul principal. Worktree este util pentru corecții rapide în ramura release când directorul principal este ocupat cu dezvoltare pe termen lung.
Git Submodules — un mecanism de includere a unui depozit Git în altul. Submodulul stochează o referință la un commit fixat al depozitului extern, ceea ce garantează reproductibilitatea compilării. Comanda git submodule add https://github.com/example/lib.git adaugă o bibliotecă externă ca submodul. La clonarea unui proiect cu submodule, pentru încărcarea tuturor dependențelor este necesar să se execute git submodule update --init --recursive.
Întrebări frecvente
Git — VCS distribuit cu istoric local și posibilitatea de lucru offline. SVN — un sistem centralizat care necesită conexiune permanentă la server pentru orice operație în afara vizualizării fișierelor.
Utilizați git revert HEAD pentru anulare sigură (se creează un nou commit). Dacă commitul nu a fost încă trimis pe server, puteți utiliza git reset --soft HEAD~1.
.gitignore — fișierul în care sunt listate modelele de fișiere și directoare pe care Git trebuie să le ignore. Este utilizat pentru excluderea fișierelor temporare, a compilărilor și a configurațiilor IDE din depozit.
git fetch încarcă modificările de pe server, dar nu le îmbină cu ramura curentă. git pull face fetch și execută imediat merge. Pentru control, utilizați fetch + vizualizare diff, apoi merge manual.
Utilizați git commit --amend — această comandă deschide editorul pentru modificarea mesajului commitului. Dacă commitul este deja pe server, va fi necesar git push --force, ceea ce este periculos pentru ramurile comune.
Concluzii
Vom dezvolta o aplicație mobilă la cheie
IT Sectr creează aplicații iOS și Android pentru startup-uri și afaceri din 2017. Vă vom consilia și vă vom propune cea mai bună soluție.
Citiți și