Develop Branch în Git — ce este, scopul și principiul de funcționare

Ce este Develop Branch în Git

Develop Branch (ramura de dezvoltare) — este o ramură de lungă durată în Git Flow, care servește ca nod central pentru integrarea codului de la toți dezvoltatorii. În ea sunt îmbinate ramurile feature după finalizarea dezvoltării și trecerea prin code review.

Codul în develop se află întotdeauna într-o stare gata pentru crearea unei lansări, deși încă nu a fost publicat în producție. Aceasta înseamnă că toate funcționalitățile din develop au trecut prin review, testare și verificări de integrare, dar încă așteaptă ciclul lor de lansare.

Spre deosebire de main, unde fiecare versiune de cod este o lansare, develop conține un flux continuu de modificări. Commiturile în develop apar pe măsură ce ramurile feature sunt îmbinate, ceea ce poate avea loc de mai multe ori pe zi.

Conform datelor Vincent Driessen, 2010, develop este un element cheie al unui model de branching de succes, deoarece separă munca în desfășurare de versiunile gata de lansare.

Diferențele dintre develop și main branch

Înțelegerea diferențelor dintre develop și main este esențială pentru lucrul corect în Git Flow. Aceste ramuri îndeplinesc funcții diferite și au cerințe diferite de stabilitate.

Separarea în develop și main permite echipei să integreze continuu cod nou fără a risca stabilitatea versiunii de producție. Dezvoltatorii își pot vedea codul în develop imediat după aprobarea PR, chiar înainte de lansarea oficială.

Rolul develop în Git Flow

În modelul Git Flow, develop ocupă un loc central între ramurile feature (sursa modificărilor) și ramurile release (pregătirea pentru lansare). Înțelegerea acestei ierarhii este baza ramificării eficiente.

• Feature → Develop — fiecare funcționalitate finalizată este îmbinată în develop prin Pull Request cu code review.
• Develop → Release — când se acumulează un volum suficient de modificări pentru o lansare, din develop se creează ramura release.
• Release → Main + Develop — după pregătirea finală, ramura release este îmbinată în main (lansare) și înapoi în develop (corecturi de bug-uri).
• Hotfix → Main + Develop — corecturile critice sunt create din main și îmbinate în ambele ramuri.

O astfel de structură garantează că develop conține întotdeauna cea mai recentă versiune de cod cu toate funcționalitățile noi, iar main — doar cod de producție verificat. Acest lucru este deosebit de important pentru proiectele mobile cu un ciclu lung de revizuire în App Store și Google Play.

Legătura develop cu alte ramuri Git Flow

Develop acționează ca o verigă centrală între ramurile feature, release și hotfix. Înțelegerea direcțiilor de îmbinare este baza pentru prevenirea conflictelor și a pierderii commiturilor.

Cerințe de calitate a codului în develop

Calitatea codului în develop trebuie să fie ridicată, dar nu absolută. Spre deosebire de main, unde fiecare eroare înseamnă un hotfix urgent, develop permite mici deficiențe care vor fi corectate înainte de lansare.

Cerințe minime pentru cod înainte de îmbinarea în develop:

• Compilare — codul trebuie să se compileze fără erori. O compilare stricată în develop blochează munca întregii echipe.
• Teste unitare — toate testele existente trebuie să treacă. Codul nou trebuie să aibă o acoperire de teste de minimum 70%.
• Code style — codul trebuie să respecte standardele de formatare și denumire acceptate în echipă.
• Fără API-uri depreciate — utilizarea metodelor învechite nu este permisă în codul nou.

Verificările automate în pipeline-ul CI/CD trebuie să se ruleze la fiecare push în develop. Dacă compilarea se strică, dezvoltatorul responsabil trebuie să corecteze problema într-o oră sau să revină la commitul său.

Verificări CI/CD pentru develop

Configurarea GitHub Actions pentru develop garantează că fiecare PR înainte de îmbinare trece printr-o verificare automată. Pipeline-ul tipic include compilare, teste și linting.

# GitHub Actions — verificarea develop după îmbinare
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

Reguli de îmbinare în develop

Îmbinarea în develop trebuie să respecte reguli stricte pentru a menține stabilitatea ramurii de integrare. Încălcarea acestor reguli duce la conflicte, compilări stricate și pierdere de timp a echipei.

• Doar prin Pull Request — push-ul direct în develop este interzis. Toate modificările trec prin code review.
• Minim un approve — PR trebuie să obțină aprobarea a cel puțin unui dezvoltator care nu a participat la sarcină.
• Squash merge — se recomandă combinarea tuturor commiturilor ramurii feature într-unul singur la îmbinarea în develop pentru o istorie curată.
• Actualitatea PR — înainte de îmbinare, PR trebuie actualizat față de ultimul commit al develop (rebase sau merge).

Regula actualității PR este deosebit de importantă. Dacă ramura feature a fost creată acum o săptămână, iar develop a mers înainte cu 50 de commituri, îmbinarea directă poate duce la conflicte care sunt mai bine rezolvate în contextul PR-ului, nu în develop.

Protejarea develop de îmbinări incorecte

Branch protection rules (reguli de protejare a ramurii) — sunt setări la nivel de GitHub, GitLab sau Bitbucket care previn modificările incorecte în develop. Ele garantează că nici măcar un push accidental nu va strica ramura de integrare.

Reguli de protejare recomandate pentru develop:

• Require pull request — interzice push-ul direct în develop. Toate modificările doar prin PR.
• Require approvals — minim 1-2 aprobări înainte de îmbinarea PR.
• Require status checks — blochează îmbinarea dacă pipeline-ul CI/CD nu a trecut.
• Require up-to-date — ramura PR trebuie actualizată față de develop înainte de îmbinare.
• Restrict push access — limitează drepturile de push în develop doar pentru dezvoltatorii seniori.

Configurarea protejării develop durează 10 minute, dar previne săptămâni de întreruperi legate de o ramură de integrare stricată. Pentru proiectele mobile cu echipe multi-platformă, acest lucru este deosebit de relevant.

Exemple de comenzi pentru lucrul cu develop

Să examinăm o zi tipică a unui dezvoltator: dimineața actualizează develop, creează o nouă ramură feature, iar după finalizarea sarcinii îmbină modificările înapoi în develop.

# Sincronizarea de dimineață a develop
git checkout develop
git pull origin develop

# Crearea unei noi ramuri feature din develop
git checkout -b feature/add-push-notifications

# Lucrul la funcționalitate...
git add . && git commit -m "Add FCM integration"

# Actualizarea develop în timpul dezvoltării
git fetch origin develop
git rebase origin/develop

# După aprobarea PR — actualizarea develop local
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

Comanda git pull în develop efectuează simultan două operații: git fetch (preia noile commituri de pe server) și git merge (le îmbină cu ramura locală). Pentru develop, aceasta este modalitatea standard de sincronizare.

Restabilirea develop după o îmbinare stricată

Dacă în develop a ajuns un cod care a stricat compilarea, trebuie acționat rapid. Fiecare oră de întrerupere a develop înseamnă muncă blocată pentru întreaga echipă de dezvoltatori.

Dacă în develop a ajuns un cod care a stricat compilarea, folosiți git revert pentru a crea un nou commit care anulează modificările problematice. Nu folosiți git reset în develop — aceasta rescrie istoria care există deja la alți participanți.

# Găsirea commitului problemă
git log --oneline develop

# Anularea commitului prin revert (sigur)
git revert a1b2c3d

# Trimiterea corecturii în develop la distanță
git push origin develop

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