Git Flow: ce este, modelul de ramificare și utilizarea în proiecte

Ce este Git Flow?

Git Flow — este un model de ramificare Git care stabilește o structură strictă a ramurilor și reguli de îmbinare pentru gestionarea dezvoltării, lansărilor și remedierilor. Vincent Driessen a publicat articolul „A successful Git branching model” în ianuarie 2010 și de atunci Git Flow a devenit standardul de facto în dezvoltarea corporativă Java și .NET. Ideea principală — împărțirea codului în cinci tipuri de ramuri cu diferite niveluri de stabilitate.

Potrivit Atlassian Git Tutorials, 2024, Git Flow se bazează pe două ramuri permanente: main (fost master) și develop. Toate celelalte ramuri sunt temporare: feature, release, hotfix. Fiecare tip de ramură are un ciclu de viață și reguli de îmbinare clar definite. În dezvoltarea mobilă, Git Flow este utilizat în proiecte cu cicluri de lansare regulate (2–4 săptămâni) și suport pentru mai multe versiuni.

Git Flow se deosebește de modelele simple (GitHub Flow) prin faptul că necesită o ramură separată develop pentru integrare. Acest lucru adaugă un pas în procesul de îmbinare, dar asigură o izolare suplimentară a funcțiilor neterminate de codul gata de lansare.

Vincent Driessen și istoria Git Flow

În 2010, Vincent Driessen a publicat postarea „A successful Git branching model”, care a devenit una dintre cele mai citate din istoria Git. Modelul a fost creat pentru un proiect cu lansări fixe și suport paralel pentru versiuni. În 2020, Driessen a recunoscut că Git Flow este depășit pentru practicile moderne CI/CD, dar modelul rămâne relevant pentru proiecte cu ciclu lung de lansare și necesitatea de a suporta versiuni vechi.

# Inițializarea Git Flow
git flow init

# Crearea ramurii feature
git flow feature start "add-auth"

# Finalizarea ramurii feature (îmbinare în develop)
git flow feature finish "add-auth"

# Crearea release
git flow release start "1.2.0"
git flow release finish "1.2.0"

Ramura Main: cod de lansare și etichetare

Main (fost master) — ramura principală care conține doar codul de lansare gata de implementare. Fiecare commit în main trebuie să corespundă unei versiuni specifice a produsului, marcată cu o etichetă (tag) în formatul versionării semantice, de exemplu v1.0.0, v1.1.0. Nicio dezvoltare directă în main nu se efectuează — modificările ajung aici doar prin ramurile release sau hotfix.

Potrivit semver.org, 2024, etichetele în main folosesc formatul MAJOR.MINOR.PATCH. MAJOR se incrementează la modificări incompatibile ale API, MINOR — la adăugarea de funcționalități cu compatibilitate inversă, PATCH — la remedierea erorilor. În Git Flow, fiecare finish release creează automat un commit în main cu eticheta versiunii.

Main — singura ramură care este implementată în producție. Pentru proiectele mobile, aceasta înseamnă că la push în main se pornește pipeline-ul de construire a App Bundle sau IPA și publicarea în Google Play / App Store. În setările CI/CD GitLab, main este protejată împotriva force-push și ștergere.

Versionarea semantică și etichetele

Fiecare commit în main este însoțit de o etichetă în format SemVer: vMAJOR.MINOR.PATCH. MAJOR — pentru modificări incompatibile ale API, MINOR — pentru funcționalități noi cu compatibilitate inversă, PATCH — pentru remedierea erorilor. Exemplu: v2.1.0 înseamnă a doua lansare majoră cu funcții noi și fără remedieri de erori. În Git Flow, etichetele sunt create automat la finish release sau hotfix prin comanda git flow release finish.

Ramura Develop: linia de integrare a dezvoltării

Develop — a doua ramură permanentă Git Flow, destinată integrării tuturor funcțiilor finalizate. Dezvoltatorii îmbină ramurile feature în develop după ce trec de revizuirea codului și verificările CI/CD. Develop conține cea mai recentă versiune stabilă a codului, incluzând toate funcțiile implementate ale sprintului curent.

Potrivit DataSift Git Flow Guide, 2024, develop poate fi temporar instabilă din cauza integrărilor neterminate. Pentru a preveni problemele, echipele practică Continuous Integration (CI): fiecare funcție înainte de îmbinarea în develop trece printr-un set complet de teste. Dacă CI eșuează — dezvoltatorul remediază codul până la următoarea îmbinare. Develop este întotdeauna legată de versiunea curentă a main: imediat după lansare, develop este sincronizată cu main prin îmbinare.

Ramurile Feature: dezvoltarea funcționalităților noi

Ramurile feature — ramuri temporare pentru dezvoltarea funcțiilor individuale, remedierea erorilor sau experimente. Fiecare ramură feature este creată din develop și după finalizare se îmbină înapoi în develop. Numele ramurii feature conține de obicei numărul sarcinii sau o descriere scurtă: feature/APP-123-add-oauth, feature/redesign-profile. În Git Flow, ramurile feature pot exista pentru o perioadă nelimitată.

Potrivit Pro Git Book, 2024, ramurile feature sunt un mediu de dezvoltare izolat: modificările într-o ramură nu afectează altele până la momentul îmbinării. În proiectele mobile, ramurile feature sunt sincronizate cu develop prin rebase sau merge pentru a evita conflictele mari la finalizare. Se recomandă rebase-ul ramurii feature pe develop înainte de a crea un MR.

# Crearea manuală a ramurii feature (fără git flow)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# Crearea MR în GitLab prin CLI
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Ramurile Release: pregătirea lansării

Ramurile release — ramuri temporare create din develop pentru pregătirea lansării. Când develop conține un set suficient de funcții pentru o nouă versiune, echipa creează ramura release/X.Y.Z (de exemplu, release/2.1.0). În această ramură se fac doar modificări finale: incrementarea versiunii, actualizarea localizării, testarea finală, remedierea erorilor critice.

Potrivit Atlassian Git Tutorials, 2024, ramura release rezolvă o problemă cheie: izolarea modificărilor finale de dezvoltarea paralelă. În timp ce release se pregătește pentru lansare, în develop continuă să fie îmbinate funcții noi pentru următoarea lansare. După finalizare, ramura release este îmbinată în main (cu etichetă) și în develop (pentru a sincroniza incrementarea versiunii).

Ramurile Hotfix: remedieri urgente în producție

Ramurile hotfix — ramuri temporare pentru remedierea urgentă a erorilor critice în producție. Singurul tip de ramură Git Flow care este creat din main, nu din develop. Formatul numelui: hotfix/X.Y.Z+1 (de exemplu, hotfix/2.1.1). După finalizare, ramura hotfix este îmbinată simultan în main (ca o nouă lansare de patch) și în develop (pentru ca remedierea să nu se piardă la următoarele lansări).

Potrivit DataSift Git Flow Guide, 2024, ramurile hotfix trebuie să fie cât mai scurte — doar remediere și test. Hotfix nu trebuie să includă funcții noi sau refactorizări. În dezvoltarea mobilă, hotfix este utilizat pentru remedierea căderilor critice (rată crash > 0.1%), vulnerabilităților de securitate sau erorilor blocante din App Store.

Avantaje și dezavantaje ale Git Flow pentru dezvoltarea mobilă

Git Flow oferă o structură clară care este deosebit de utilă pentru echipele mari și proiectele cu lansări regulate. Avantaje: izolarea funcțiilor neterminate în ramurile feature, posibilitatea de a pregăti o lansare fără a bloca dezvoltarea, suport pentru mai multe versiuni prin hotfix. Dezavantaje: complexitate pentru începători, necesitatea rebase-ului regulat al ramurilor feature, conflicte în ramurile cu durată lungă de viață.

Potrivit Martin Fowler, 2024, principalul dezavantaj al Git Flow — ramurile feature cu durată lungă de viață. Dacă o funcție se dezvoltă 2+ săptămâni fără sincronizare cu develop, conflictul la îmbinare devine semnificativ. Pentru proiectele mobile se recomandă sincronizarea zilnică a ramurii feature prin rebase pe develop.

Git Flow nu este recomandat pentru proiecte cu Continuous Deployment (fiecare commit în main → în producție). Pentru astfel de proiecte, GitHub Flow sau Trunk-Based Development oferă un model mai simplu și mai rapid. Dar pentru proiecte cu cicluri de lansare și suport pentru versiuni vechi, Git Flow rămâne alegerea optimă.

Când Git Flow dăunează echipei

Git Flow devine o problemă în trei cazuri: echipa mai mică de 5 persoane (complexitate excesivă), Continuous Deployment (întârziere în livrare), lipsa disciplinei de rebase (ramurile feature cu durată lungă de viață creează conflicte de îmbinare). Dacă echipa petrece mai mult de 20% din timp îmbinând ramuri și rezolvând conflicte — Git Flow nu este potrivit pentru această echipă, chiar și la dimensiune mare.

Alternative la Git Flow: GitHub Flow și Trunk-Based Development

Alternativele la Git Flow oferă un proces mai simplu pentru echipele care practică CI/CD. GitHub Flow folosește doar o ramură permanentă (main) și ramuri feature. Fiecare funcție este creată din main, după revizuire și CI se îmbină înapoi în main și este imediat implementată. GitHub Flow este mai simplu, dar nu suportă izolarea funcțiilor neterminate și pregătirea paralelă a lansării.

Potrivit GitHub Docs, 2024, Trunk-Based Development (TBD) merge și mai departe: toți dezvoltatorii lucrează într-o singură ramură (trunk), folosind ramuri feature de scurtă durată (1–2 zile). Feature toggles (comutatoare de funcții) controlează vizibilitatea codului neterminat. TBD necesită disciplină CI/CD înaltă și automatizare a testării.

• GitHub Flow — un main + ramuri feature, ideal pentru CI/CD și echipe mici
• GitLab Flow — dezvoltă Git Flow cu ramuri de mediu (staging, production)
• Trunk-Based Development — o ramură + feature toggles, maxim CI/CD, minim îmbinări
• One Flow — Git Flow simplificat fără ramura develop, doar main + feature + release