Ghid de Strategii de Branching în Producție: GitFlow, GitHub Flow și Trunk-Based Development în Git

Modul în care o echipă își organizează ramurile (branches) în Git determină în mod direct ritmul de lansare al versiunilor (release cadence), stabilitatea mediilor de producție și frecvența blocajelor cauzate de conflictele masive de cod. Alegerea unei strategii greșite de ramificare este principala cauză a fenomenului de „Merge Hell” (zile întregi pierdute cu rezolvarea divergențelor de cod).

1. Modelul GitFlow: Structură Strictă pentru Lansări Programate

Creat de Vincent Driessen în 2010, GitFlow utilizează două ramuri principale cu viață infinită și mai multe tipuri de ramuri secundare temporare:

• main (sau master): reflectă întotdeauna codul aflat în producție. Fiecare comitere pe main este etichetată cu o versiune (ex: v1.4.0).
• develop: ramura centrală de integrare continuă unde dezvoltatorii își combină funcționalitățile finalizate.
• feature/*: ramuri pornite din develop pentru dezvoltarea de capabilități noi. Se reunesc în develop prin Pull Request.
• release/*: pornite din develop când se apropie o lansare programată; aici se rezolvă doar bug-uri minore de lansare, iar la final se îmbină atât în main, cât și în develop.
• hotfix/*: pornite direct din main pentru incidente critice apărute în producție; după rezolvare, se îmbină urgent în main și develop.

# 1. Începerea unei funcționalități noi din develop:
git switch develop
git pull origin develop
git switch -c feature/plati-stripe

# ... comiteri de lucru ...
git commit -m "feat(checkout): integreaza Stripe SDK"

# 2. Finalizarea funcționalității și deschiderea Pull Request către develop:
git push -u origin feature/plati-stripe
# După aprobare și review, se îmbină în develop

# 3. Pregătirea lansării unei versiuni noi (Release branch):
git switch develop
git switch -c release/v2.1.0
# Se rulează teste finale, bump de versiune în package.json
git commit -am "chore: pregatire lansare v2.1.0"

# 4. Lansarea în producție: îmbinare în main cu tag și revenire în develop:
git switch main
git merge --no-ff release/v2.1.0
git tag -a v2.1.0 -m "Release v2.1.0"
git switch develop
git merge --no-ff release/v2.1.0
git branch -d release/v2.1.0

Când este indicat GitFlow: În proiecte software tradiționale cu versiuni distribuite și instalate de clienți (aplicații desktop, firmware, sisteme enterprise cu lansări semestriale rigide). Nu este recomandat pentru aplicații web moderne cu livrare continuă (CI/CD zilnic).

2. Modelul GitHub Flow: Agilitate Maximă pentru CI/CD Web

GitHub Flow este o strategie minimalistă și extrem de eficientă, ideală pentru servicii web, aplicații SaaS și microservicii cu implementare automată continuă:

• Există o singură ramură permanentă: main. Codul de pe main este întotdeauna gata de a fi trimis în producție.
• Orice funcționalitate, refactorizare sau remediere de bug se dezvoltă pe o ramură scurtă creată direct din main (ex: user-avatar-upload).
• Se deschide un Pull Request (PR) cât mai devreme pentru feedback și rularea automată a testelor unitare și e2e în pipeline-ul CI.
• După aprobarea recenziei de cod (code review) și trecerea testelor CI, ramura se îmbină în main și este implementată automat în producție în câteva minute.

# 1. Creare ramură descriptivă din main actualizat:
git switch main
git pull --rebase origin main
git switch -c fix-session-timeout

# 2. Lucru și trimitere regulată pe server:
git commit -m "fix(auth): creste timeout token la 3600 secunde"
git push -u origin fix-session-timeout

# 3. Deschiderea PR-ului prin CLI (GitHub CLI gh):
gh pr create --title "fix: crestere timeout sesiune" --body "Rezolva incidentul #402"

# 4. După aprobare și CI verde, îmbinare cu Squash (pentru un istoric curat):
gh pr merge --squash --delete-branch

3. Trunk-Based Development (TBD): Tehnica de Elită a Echipelor Performante

Adoptat la scală mare de giganți tehnologici precum Google, Meta și Netflix, Trunk-Based Development obligă toți inginerii software să integreze modificările frecvent (de mai multe ori pe zi) direct pe trunchiul principal (main sau trunk), fie direct, fie prin ramuri extrem de scurte (Short-Lived Feature Branches cu o durată de viață mai mică de 24-48 ore).

Cum se evită erorile neterminate în producție? Feature Flags!

Dacă o funcționalitate complexă necesită 2 săptămâni de dezvoltare, în TBD codul neterminat este comitet zilnic în main, dar este ascuns de utilizatorii finali printr-un comutator de funcționalitate (Feature Flag sau Feature Toggle):

// Codul este integrat continuu în main fără a fi activat pentru public:
if (featureFlags.isEnabled('NOUL_CHECKOUT_V2', currentUser)) {
    afiseazaNoulFluxCheckout();
} else {
    afiseazaCheckoutClasic();
}

4. Tabel Comparativ între Strategiile de Branching

5. Reguli de Aur pentru Menținerea Ramurilor Curate

• Durata maximă de viață: O ramură de feature nu trebuie să stea deschisă mai mult de 2-3 zile. Ramurile care rămân deschise săptămâni întregi acumulează divergențe uriașe și devin un coșmar la îmbinare.
• Dimensiunea Pull Request-urilor: Limitați PR-urile la sub 300 de linii de cod modificate. PR-urile gigantice primesc recenzii superficiale și ascund erori subtile.
• Sincronizare zilnică: Dacă lucrați pe o ramură, aduceți zilnic modificările din main folosind git pull --rebase origin main pentru a rezolva eventualele conflicte incremental, linie cu linie.