Repository în Git: ce este, ce tipuri există și cum funcționează

Ce este un depozit în Git

Depozitul Git — este o structură de date în care sistemul de control al versiunilor stochează metadate și obiecte ce descriu istoricul modificărilor fișierelor proiectului. Când un dezvoltator inițializează un depozit cu comanda git init, Git creează un dosar ascuns .git în rădăcina proiectului.

În interiorul acestui dosar se află toate obiectele, referințele și fișierele de configurare necesare pentru funcționarea sistemului. Depozitul nu este legat de o locație concretă — dezvoltatorul îl poate crea local, apoi îl poate conecta la un server remote.

Git folosește modelul de depozit distribuit: fiecare participant la proiect are o copie completă a istoricului pe propriul computer. Aceasta înseamnă că majoritatea operațiilor — commit, vizualizarea istoricului, crearea ramurilor — se execută local fără a apela la server.

Conform documentației Git, arhitectura distribuită face sistemul rezistent la defecțiuni: dacă serverul cade, orice depozit local poate deveni sursa pentru restaurarea istoricului complet al proiectului.

Depozit local și remote

Depozitul local — este copia proiectului pe computerul dezvoltatorului. Conține întreg istoricul commiturilor, ramurilor și tagurilor și permite executarea operațiilor commit, branch, merge și rebase fără conexiune la rețea.

Depozitul remote este găzduit pe un server și servește ca punct de sincronizare pentru toți membrii echipei. Dezvoltatorii trimit modificările lor cu comanda git push și preiau modificările altora cu comanda git pull.

Conexiunea dintre depozitul local și cel remote se configurează prin remote origin — URL-ul serverului stocat în configurația Git. Un depozit local poate fi conectat la mai multe depozite remote, ceea ce este util la lucrul cu forkuri.

Principalul avantaj al acestui model — dezvoltatorul poate lucra asupra codului în mod offline, sincronizând modificările doar atunci când este gata să trimită rezultatul.

Diferențele între depozitul local și cel remote

Cum stochează Git datele în depozit

Modelul de stocare al Git diferă fundamental de alte sisteme de control al versiunilor. În loc să stocheze o listă de modificări (delta) între versiuni, Git stochează instantanee complete ale tuturor fișierelor proiectului la momentul fiecărui commit.

Fiecare obiect din depozit este identificat printr-un hash SHA-1 unic de 40 de caractere. Dacă conținutul unui fișier nu s-a schimbat între commituri, Git nu creează un nou obiect, ci reutilizează unul existent — astfel se economisește spațiu.

Git folosește patru tipuri de obiecte: blob (conținutul fișierului), tree (structura directorului), commit (instantaneu cu metadate) și tag (referință numită către un commit). Toate obiectele sunt stocate în dosarul .git/objects.

Conform Git Internals, modelul obiectelor Git asigură integritatea datelor: orice modificare a conținutului unui fișier duce la un hash nou, ceea ce face imposibilă modificarea ascunsă a istoricului.

Structura dosarului .git

Dosarul .git — este inima depozitului. Fără el, Git nu poate urmări modificările, iar un director obișnuit rămâne doar o colecție de fișiere. Înțelegerea structurii acestui dosar ajută la diagnosticarea problemelor cu depozitul.

• objects/ — toate obiectele depozitului: bloburi, arbori, commituri, taguri. Stocate în formă comprimată.
• refs/ — referințe către commituri: heads (ramuri), tags (etichete), remotes (ramuri remote).
• HEAD — fișierul care indică ramura sau commitul activ curent.
• config — setările depozitului: URL remote, nume utilizator, email și alți parametri.
• index — staging area (indexul), unde Git stochează informații despre fișierele pregătite pentru commit.
• logs/ — jurnalele de actualizare a referințelor (reflog), care stochează istoricul deplasării HEAD și a ramurilor.

Fișierul HEAD merită o atenție deosebită. În stare normală conține o referință simbolică către o ramură, de exemplu ref: refs/heads/main. În starea detached HEAD indică direct către un commit — aceasta înseamnă că noile commituri nu vor fi atașate niciunei ramuri.

Operații principale cu depozitul

Lucrul cu depozitul Git include un set de operații de bază pe care dezvoltatorul le execută zilnic. Fiecare operație modifică starea depozitului, adăugând obiecte noi sau mutând referințe.

• git init — creează un depozit gol nou în directorul curent. Git creează dosarul .git cu structura inițială.
• git clone — copiază un depozit remote existent pe mașina locală împreună cu întreg istoricul commiturilor.
• git add — adaugă modificările fișierelor în staging area (index), pregătindu-le pentru commit.
• git commit — creează o instantanee a proiectului pe baza datelor din index și o salvează ca un nou obiect commit.
• git push — trimite commiturile noi din depozitul local în cel remote, actualizând ramurile de pe server.
• git pull — preia commiturile noi din depozitul remote și le îmbină cu ramura locală curentă.

Operațiile push și pull — sunt singurele care necesită conexiune la serverul remote. Toate celelalte operații se execută complet local, ceea ce asigură o viteză mare de lucru chiar și cu un istoric voluminos.

Ciclul de viață al unui fișier în depozit

Fiecare fișier din depozit trece prin patru stări: untracked (neurmărit), modified (modificat), staged (pregătit) și committed (comis). Git urmărește doar fișierele care au fost adăugate explicit prin git add sau se află deja în istoricul commiturilor.

Înțelegerea acestui model — cheia pentru o lucrare eficientă cu Git. Dezvoltatorul poate pregăti selectiv pentru commit doar o parte din fișierele modificate, creând commituri logic complete cu descrieri clare.

Platforme populare pentru stocarea depozitelor

Depozitele remote sunt de obicei găzduite pe platforme specializate care oferă interfață web, sistem de gestionare a accesului și instrumente suplimentare pentru dezvoltarea colaborativă.

• GitHub — cea mai mare platformă cu peste 100 de milioane de depozite. Oferă Actions, Pull Requests, Issues și Wiki. Gratuită pentru proiecte publice.
• GitLab — platformă cu CI/CD integrat, Container Registry și pipeline DevOps încorporat. Disponibilă ca SaaS și versiune self-hosted.
• Bitbucket — soluție de la Atlassian cu integrare Jira și Trello. Populară în mediul corporativ datorită setărilor flexibile de acces.

Alegerea platformei depinde de dimensiunea echipei, cerințele de confidențialitate și integrările necesare. Pentru dezvoltarea mobilă se alege adesea GitHub datorită suportului larg al comunității și integrării cu instrumentele CI/CD pentru iOS și Android.

Exemple de comenzi pentru lucrul cu depozitul

Să analizăm un scenariu practic: un dezvoltator clonează un depozit existent, creează o ramură nouă, face modificări și le trimite pe server. Fiecare comandă demonstrează lucrul cu diferite componente ale depozitului.

# Clonarea depozitului remote
git clone https://github.com/user/mobile-app.git

# Navigarea în directorul proiectului
cd mobile-app

# Crearea unei noi ramuri feature și comutarea pe ea
git checkout -b feature/auth

# Verificarea stării fișierelor modificate
git status

# Adăugarea tuturor modificărilor în staging area
git add .

# Crearea unui commit cu descriere
git commit -m "Add authentication module"

# Trimiterea modificărilor în depozitul remote
git push origin feature/auth

Comanda git status — una dintre cele mai utile în munca de zi cu zi. Afișează ce fișiere au fost modificate, care sunt pregătite pentru commit și care nu sunt deloc urmărite de Git.

Vizualizarea istoricului commiturilor

Pentru analiza istoricului depozitului se folosește comanda git log cu diverse flaguri de formatare. Aceasta afișează cronologia commiturilor, autorii, datele și identificatorii SHA-1.

# Vizualizarea istoricului cu graficul ramurilor
git log --oneline --graph --all

# Vizualizarea modificărilor într-un commit specific
git show a1b2c3d

# Compararea stării curente cu ultimul commit
git diff HEAD

# Vizualizarea istoricului unui fișier specific
git log --follow src/MainActivity.kt

Flagul --graph afișează un grafic ASCII al ramificărilor, ceea ce este deosebit de util în depozitele cu activitate intensă pe mai multe ramuri. Pentru proiectele mobile cu lansări frecvente, graficul vizual ajută la evaluarea rapidă a structurii dezvoltării.