Ce este Git și cum funcționează controlul versiunilor

Git, explicat într-o frază

Pe site-ul oficial, proiectul se descrie drept un sistem distribuit de control al versiunilor, gândit să gestioneze rapid și eficient atât proiecte mici, cât și proiecte foarte mari. "Distribuit" înseamnă că fiecare persoană care lucrează la proiect are pe calculatorul ei o copie completă a acestuia, cu tot istoricul, nu doar ultima versiune a fișierelor.

Git este folosit în principal pentru codul sursă al aplicațiilor și site-urilor. Poate urmări orice tip de fișier, dar este cel mai util pentru fișierele text, la care arată exact ce rânduri s-au schimbat: documentație, fișiere de configurare, traduceri.

Ce problemă rezolvă un sistem de control al versiunilor

Aproape oricine a lucrat la un document important cunoaște scenariul: "oferta.docx", "oferta_v2.docx", "oferta_final.docx", "oferta_final_corectat.docx". După câteva zile nu mai știi care e versiunea bună, ce s-a schimbat între ele și cine a făcut modificarea.

La un site sau la o aplicație, aceeași problemă e mult mai gravă. Un proiect are sute sau mii de fișiere, la care lucrează simultan mai mulți programatori. Fără un sistem de control al versiunilor apar rapid situații precum:

• Modificări suprascrise. Doi oameni editează același fișier, iar munca unuia dispare când celălalt își salvează varianta.
• Erori greu de urmărit. Site-ul nu mai funcționează după o actualizare, dar nimeni nu știe exact ce s-a schimbat.
• Imposibilitatea revenirii. O funcție nouă strică ceva important și nu există o cale sigură de a reveni la starea de ieri.
• Dependența de o singură persoană. Codul există doar pe laptopul unui programator, iar dacă acesta pleacă din proiect, pleacă și istoricul.

Git rezolvă toate aceste situații printr-un principiu simplu: fiecare set de modificări este salvat ca un "instantaneu" al proiectului, cu autor, dată și o descriere. Aceste instantanee formează un istoric complet, în care poți naviga înainte și înapoi.

Cum a apărut Git

Git nu a fost creat de o companie, ci a apărut dintr-o problemă practică a comunității care dezvoltă nucleul sistemului de operare Linux.

• 2002Proiectul Linux începe să folosească BitKeeper, un sistem comercial de control al versiunilor, oferit gratuit comunității.
• 2005Relația dintre comunitatea Linux și compania care dezvolta BitKeeper se rupe, iar licența gratuită este retrasă. Linus Torvalds, creatorul Linux, începe să scrie propriul instrument. Primul commit din istoria Git este datat 7 aprilie 2005.
• 2005După câteva luni, Torvalds predă coordonarea proiectului lui Junio Hamano, care coordonează proiectul și astăzi.
• 2008Se lansează GitHub, platforma care face Git accesibil unui public mult mai larg prin găzduire online și colaborare.
• 2026Pe 28 septembrie 2026 este lansată versiunea 2.56, cea mai recentă la data scrierii acestui articol, iar comunitatea pregătește trecerea la Git 3.0.

Obiectivele stabilite de la început explică în bună parte de ce Git a devenit standard: viteză, un design simplu, suport foarte bun pentru dezvoltarea în paralel (mii de ramuri simultan), funcționare complet distribuită și capacitatea de a gestiona proiecte uriașe, cum este nucleul Linux.

Conceptele de bază: cum funcționează Git

Pentru a înțelege o discuție cu o echipă de dezvoltare, sunt suficienți câțiva termeni. Fiecare are o traducere aproximativă în română, dar în practică se folosesc aproape mereu formele din engleză.

Repository (depozit)

Un repository, prescurtat "repo", este folderul proiectului urmărit de Git, împreună cu tot istoricul modificărilor. Un site are de obicei un repository propriu, care conține codul temei, al funcțiilor personalizate și fișierele de configurare.

Commit (salvare în istoric)

Un commit este un instantaneu al proiectului la un anumit moment, însoțit de un mesaj care explică ce s-a schimbat, de exemplu "Adaugă formularul de contact pe pagina de servicii". Fiecare commit are un identificator unic și poate fi consultat sau restaurat oricând.

Staging area (zona de pregătire)

Înainte de commit, programatorul alege exact ce modificări intră în el. Zona de pregătire funcționează ca un coș în care pui fișierele sau chiar doar anumite rânduri modificate, apoi le salvezi împreună. Astfel, fiecare commit poate cuprinde o singură modificare logică, nu un amestec de schimbări fără legătură între ele.

Branch (ramură)

O ramură este o linie de dezvoltare separată. Ramura principală, numită de obicei main (sau master în proiectele mai vechi), conține, de regulă, versiunea stabilă. Când cineva lucrează la o funcție nouă, creează o ramură separată, în care poate experimenta fără să afecteze site-ul care funcționează.

Merge (unire)

Când funcția nouă este gata și testată, ramura ei se unește cu ramura principală. Dacă două persoane au modificat aceleași rânduri, Git semnalează un conflict, pe care un programator trebuie să îl rezolve, alegând sau combinând variantele corecte.

Remote (copia de pe server)

Pe lângă copiile locale ale fiecărui programator, proiectul are de obicei o copie centrală pe un server sau pe o platformă precum GitHub, GitLab sau Bitbucket. Comenzile push și pull trimit, respectiv aduc modificări între copia locală și cea de pe server.

Cum arată o zi de lucru cu Git

Dacă te întrebi "ce face concret un programator când spune că a urcat modificările?", fluxul obișnuit arată cam așa:

1. Aduce ultima versiune. Sincronizează copia locală cu cea de pe server, ca să pornească de la modificările colegilor.
2. Creează o ramură nouă. Lucrează separat, de exemplu pe o ramură numită formular-contact.
3. Modifică fișierele și salvează commit-uri. Fiecare pas logic devine un commit cu un mesaj clar.
4. Trimite ramura pe server. Colegii pot vedea modificările și le pot verifica.
5. Cere o revizuire. Pe platforme precum GitHub sau GitLab se deschide o cerere de unire (pull request sau merge request), în care alt programator citește codul și lasă comentarii.
6. Unește ramura cu cea principală. După aprobare și testare, modificarea intră în versiunea stabilă și poate fi publicată pe site.

În linia de comandă, aceiași pași se traduc în câteva comenzi scurte:

# aduce ultimele modificări de pe server
git pull

# creează o ramură nouă și trece pe ea
git switch -c formular-contact

# pregătește fișierele modificate și salvează un commit
git add contact.php
git commit -m "Adaugă formularul de contact"

# trimite ramura pe server
git push -u origin formular-contact

Mulți programatori folosesc și interfețe grafice (integrate în editoare precum Visual Studio Code sau aplicații dedicate), care afișează aceleași operații sub formă de butoane și liste. Principiile rămân identice.

Git vs GitHub: care e diferența

Confuzia dintre Git și GitHub este probabil cea mai frecventă. Pe scurt, Git este instrumentul, iar GitHub este un serviciu online care găzduiește proiecte Git și adaugă funcții de colaborare.

Poți folosi Git fără GitHub, de exemplu doar local sau cu un server propriu. Invers nu se poate: GitHub, GitLab și Bitbucket se bazează toate pe Git.

Cât de răspândit este Git

În dezvoltarea software, Git a devenit practic standardul. Datele disponibile arată cât de larg este adoptat:

Surse: DevClass, despre Stack Overflow Developer Survey 2022; GitHub Octoverse 2025.

În același sondaj Stack Overflow din 2022, al doilea sistem ca popularitate, SVN, era folosit de sub 6% dintre profesioniști. Raportul GitHub din 2025 arată, la rândul lui, că peste 36 de milioane de dezvoltatori noi s-au alăturat platformei într-un singur an.

La ce folosește Git într-un proiect web

Pentru un site de prezentare, un magazin online sau o aplicație internă, Git aduce beneficii concrete, vizibile și pentru cel care deține proiectul:

• Istoric complet al modificărilor: se poate afla oricând ce s-a schimbat pe site și de ce.
• Revenire rapidă: dacă o actualizare produce o eroare, codul poate fi readus la versiunea anterioară.
• Lucru în paralel: o funcție nouă poate fi dezvoltată fără să afecteze site-ul care funcționează.
• Revizuire de cod: modificările pot fi verificate de un al doilea programator înainte de publicare.
• Publicare automatizată: împreună cu instrumente de automatizare, codul aprobat poate fi testat și urcat pe server fără pași manuali, deci cu mai puține greșeli.
• Continuitate: dacă echipa se schimbă, noii programatori primesc proiectul cu tot istoricul și contextul lui.

Lucrul pe versiuni succesive se potrivește bine și cu abordarea etapizată a produselor noi, în care lansezi o primă versiune simplă și o îmbunătățești pe baza feedbackului. Am explicat această abordare în articolul despre ce înseamnă MVP.

Un detaliu important pentru site-urile WordPress: în Git se păstrează de obicei codul personalizat (tema și pluginurile dezvoltate special), nu și baza de date cu articole, comenzi sau conturi de utilizatori ori imaginile încărcate în site. Pentru acestea este nevoie, în continuare, de backup-uri separate.

Greșeli frecvente în lucrul cu Git

Prima greșeală este, de fapt, o problemă de securitate: orice parolă ajunsă într-un repository trebuie considerată compromisă și schimbată. Alte măsuri de protecție pentru un site sunt descrise în ghidul nostru de securitate pentru site-uri web.

Ce trebuie să știi despre Git dacă deții un site

Nu trebuie să înveți comenzi ca să beneficiezi de Git. Merită însă să pui echipei sau agenției care îți dezvoltă site-ul câteva întrebări simple:

1. Codul site-ului este versionat în Git? Un răspuns negativ înseamnă că modificările se fac direct pe server, fără istoric și fără o cale sigură de revenire.
2. Unde se află repository-ul și cine are acces la el? Ideal, proiectul este găzduit într-un cont al firmei tale sau ți se poate preda oricând.
3. Cum se publică modificările pe site? Un proces clar, cu testare înainte de publicare, reduce riscul de erori vizibile pentru clienți.
4. Ce se întâmplă dacă o actualizare strică ceva? Răspunsul ar trebui să includă revenirea la versiunea anterioară din Git, nu doar repararea manuală.

Aceste întrebări contează mai ales la schimbarea furnizorului: un proiect cu istoric complet în Git poate fi preluat de o altă echipă mult mai ușor decât unul format doar din fișierele copiate de pe server.

Întrebări frecvente