Git și controlul versiunilor în dezvoltarea mobilă: ce este, comenzi de bază și cum funcționează

Controlul versiunilor și Git: ce este?

Git este un sistem distribuit de control al versiunilor (VCS) creat de Linus Torvalds în 2005 pentru dezvoltarea nucleului Linux. Spre deosebire de sistemele centralizate (SVN, CVS), Git stochează o copie completă a istoricului proiectului pe fiecare computer al dezvoltatorului. Aceasta înseamnă că puteți face commituri, naviga prin istoric și crea ramuri chiar și fără conexiune la internet.

Git funcționează cu instantaneie (snapshots) — fiecare commit salvează starea tuturor fișierelor proiectului la momentul salvării. Dacă un fișier nu s-a modificat, Git creează o referință la versiunea anterioară, economisind spațiu. Conform analizei GitHub (2025), depozitul mediu conține 1.200 de commituri și 15 ramuri.

La IT Sectr, folosim Git din 2017 în toate proiectele. Experiența noastră arată că configurarea corectă a Git din prima zi economisește echipei până la 30% din timpul de îmbinare și rezolvare a conflictelor. Git a devenit standardul de facto — este suportat de toate IDE-urile moderne (Android Studio, Xcode, VS Code) și sistemele CI/CD.

# Configurarea de bază Git
git config --global user.name "Numele Tău"
git config --global user.email "email@tau.com"

# Crearea unui nou depozit
git init my-project
cd my-project

# Adăugarea fișierelor și commit
git add README.md
git commit -m "Initial commit"

# Lucrul cu un depozit la distanță
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Codul de mai sus arată secvența de bază: inițializarea unui depozit, primul commit și publicarea pe un server la distanță. Comanda git init creează un folder ascuns .git care va stoca întregul istoric al proiectului. Fiecare git commit creează un punct de restaurare la care puteți reveni oricând.

Concepte de bază: Repository, Branch, Commit

Înțelegerea celor trei concepte de bază — Repository, Branch și Commit — este esențială pentru lucrul cu orice sistem de control al versiunilor. Un depozit este un container pentru întregul proiect. Un commit este o stare salvată a fișierelor. O ramură este o linie separată de dezvoltare.

Repository (depozit) poate fi local (pe computerul dvs.) sau la distanță (pe un server GitHub, GitLab). Fiecare dezvoltator clonează depozitul la distanță pe mașina sa și lucrează cu o copie locală. Modificările sunt sincronizate prin push (trimitere) și pull (preluare). În controlul distribuit al versiunilor, fiecare dezvoltator stochează o copie completă a istoricului.

Branch (ramură) este un pointer către unul dintre commituri. Ramurile permit dezvoltarea paralelă: un dezvoltator lucrează la o funcționalitate nouă (feature branch), altul corectează o eroare (hotfix branch), un al treilea pregătește o lansare (release branch). Conform GitLab Flow (2025), proiectul mediu are 3–5 ramuri active simultan.

Commit este o unitate de modificare. Fiecare commit conține un hash unic (SHA-1), un mesaj, un autor și un marcaj temporal. O bună practică este să faceți commituri mici și semnificative cu mesaje descriptive — aceasta simplifică Code Review și revenirea la versiuni anterioare. Controlul versiunilor prin commituri vă oferă istoricul complet al proiectului.

Feature Branch

Feature Branch (ramură de funcționalitate) este o ramură temporară creată din develop sau main pentru a dezvolta o sarcină specifică. După finalizarea lucrului, ramura este îmbinată înapoi prin Pull Request și ștearsă. Această practică permite izolarea modificărilor fără a afecta stabilitatea bazei de cod principale.

Flux de lucru tipic: creați ramura feature/add-login → faceți mai multe commituri → creați Pull Request → treceți prin Code Review → îmbinați în develop. La IT Sectr folosim exact această abordare: fiecare sarcină Jira corespunde unei ramuri de funcționalitate separate. Aceasta simplifică urmărirea modificărilor și revenirea dacă este necesar.

Rebase vs Merge

Merge creează un commit de îmbinare care combină două ramuri. Acesta păstrează istoricul complet, inclusiv liniile de dezvoltare paralele. Rebase rescrie istoricul: preia commiturile dintr-o ramură și le "reaplică" peste alta, creând un istoric liniar.

Merge este mai potrivit pentru ramurile publice și echipele mari unde cronologia este importantă. Rebase este convenabil pentru ramurile de funcționalitate personale înainte de a crea un PR — face istoricul mai curat și mai ușor de înțeles. Cu toate acestea, rebase nu trebuie aplicat niciodată ramurilor pe care alți dezvoltatori lucrează, deoarece rescrie istoricul.

# Crearea și comutarea la o ramură de funcționalitate
git checkout -b feature/add-login main

# Lucrul în ramură
git add login-screen/
git commit -m "Add login screen layout"

# Rebase pe cel mai recent main înainte de PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push în depozitul la distanță
git push origin feature/add-login

Acest exemplu arată un flux de lucru tipic: crearea unei ramuri de funcționalitate din main, câteva commituri și rebase pentru a obține un istoric liniar curat înainte de trimiterea pentru revizuire. Această abordare minimizează conflictele de îmbinare.

Git Flow vs Trunk-Based Development

Git Flow și Trunk-Based Development sunt două strategii principale de control al versiunilor care determină modul în care o echipă organizează lucrul cu Git. Alegerea depinde de dimensiunea echipei, frecvența lansărilor și cerințele de stabilitate.

Git Flow este un model strict cu mai multe ramuri permanente: main (cod de lansare), develop (dezvoltare curentă), feature/* (funcționalități noi), release/* (pregătire lansare) și hotfix/* (corecturi urgente). Acest model este bun pentru proiecte cu cicluri de lansare clare (de exemplu, aplicații mobile cu versiunile 1.0, 2.0).

Trunk-Based Development este o abordare cu o singură ramură principală (trunk/main) în care toți dezvoltatorii îmbină modificările de mai multe ori pe zi. Se folosesc flaguri de funcționalitate pentru a ascunde funcționalitățile incomplete. Această abordare este populară în dezvoltarea web și startup-uri unde viteza de livrare este importantă.

Git Flow

Git Flow, propus de Vincent Driessen în 2010, rămâne unul dintre cele mai populare modele. Principalul său avantaj este separarea strictă a codului pe etape ale ciclului de viață. Ramura main conține doar cod de lansare, develop conține dezvoltarea curentă, iar ramurile de funcționalitate izolează funcționalitățile noi unele de altele.

Ramurile hotfix sunt create din main pentru corecturi urgente și după îmbinare sunt îmbinate înapoi atât în main, cât și în develop. Ramurile release sunt create din develop când echipa este pregătită pentru o lansare. Li se adaugă doar corecturi de erori și metadate (versiune, build). După lansare, ramura release este îmbinată în main și develop. Conform unui sondaj JetBrains (2024), 37% dintre echipe folosesc Git Flow. Acest model de control al versiunilor rămâne standardul pentru proiecte cu lansări fixe.

# Exemplu Git Flow: începerea lucrului la o lansare
git checkout -b release/1.2.0 develop

# Corectarea erorilor în ramura release
git commit -m "Fix login button crash"

# Finalizarea lansării — îmbinarea în main și develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# Ștergerea ramurii release
git branch -d release/1.2.0

Codul ilustrează crearea unei ramuri release, stabilizarea acesteia și îmbinarea în ramurile principale. Flag-ul --no-ff garantează un commit de îmbinare, păstrând informația că modificările provin din ramura release.

Pull Request și Code Review

Pull Request (PR) este un mecanism prin care un dezvoltator propune modificări din ramura sa în ramura principală. PR este un element cheie al controlului versiunilor în munca de echipă — nu este doar o modalitate de a îmbina codul, ci un proces de discuție, revizuire și control al calității. În GitLab, mecanismul similar se numește Merge Request (MR), dar esența este aceeași: informarea echipei despre modificări și obținerea aprobării.

Un PR bun ar trebui să fie mic (până la 300 de linii de cod), concentrat pe o singură sarcină și să conțină o descriere a ceea ce s-a făcut și de ce. Conform unui studiu Google (2025), PR-urile de peste 400 de linii durează de două ori mai mult pentru revizuire, iar probabilitatea de detectare a erorilor scade cu 30%. Code Review este verificarea codului de către un alt dezvoltator înainte de îmbinare.

La IT Sectr, practicăm Code Review obligatoriu pentru fiecare PR. Acest lucru nu numai că îmbunătățește calitatea codului, dar ajută și la răspândirea cunoștințelor în cadrul echipei. Code Review verifică: dacă codul respectă principiile arhitecturale, dacă există erori, dacă există suficiente teste, dacă variabilele sunt denumite corect. Toate comentariile sunt discutate în PR până la îmbinare.

Platforme: GitHub, GitLab, Bitbucket

Git este un protocol, dar pentru colaborare este necesară o platformă de control al versiunilor care oferă interfață web, gestionare a accesului, CI/CD și instrumente de revizuire. Trei platforme domină piața: GitHub, GitLab și Bitbucket.

GitHub este cea mai mare platformă cu peste 56 de milioane de dezvoltatori. Deținută de Microsoft, oferă Actions (CI/CD), Pages (găzduire), Discussions și Copilot. Planul gratuit include depozite private nelimitate pentru echipe de până la 3 persoane. GitHub este popular în comunitatea open-source.

GitLab este o platformă DevOps completă cu CI/CD integrat, registru de containere și gestionare a infrastructurii. Spre deosebire de GitHub, GitLab poate fi instalat pe propriul server (Self-Managed). Bitbucket de la Atlassian este strâns integrat cu Jira și Confluence, ceea ce îl face alegerea pentru echipele care folosesc deja ecosistemul Atlassian.