Feature Branch în Git: ce este, cum să creezi și să lucrezi cu ramuri

Ce este Feature Branch în Git

Feature Branch (ramura de funcție) „ este o ramură temporară în Git, creată din develop pentru dezvoltarea unei funcționalități separate. Spre deosebire de ramurile de lungă durată main și develop, ramurile feature există pentru o perioadă limitată „ de la câteva ore la câteva săptămâni.

Scopul principal al feature branch este de a izola modificările legate de o singură sarcină de restul codului. Dezvoltatorul poate experimenta, poate face numeroase commit-uri și chiar poate strica codul în ramura sa, fără a afecta munca celorlalți membri ai echipei.

După finalizarea dezvoltării, ramura feature este îmbinată înapoi în develop prin Pull Request cu revizuire obligatorie a codului. După îmbinare, ramura este de obicei ștearsă pentru a menține repository-ul curat.

Potrivit Vincent Driessen, 2010, modelul Git Flow cu ramuri feature a devenit standardul industriei datorită separării clare a responsabilităților între diferitele tipuri de ramuri.

Fluxul de lucru cu Feature Branch

Fluxul de lucru cu feature branch constă dintr-o succesiune de pași pe care dezvoltatorul îi execută pentru fiecare funcție nouă. Acest proces minimizează conflictele de îmbinare și asigură controlul calității codului.

1. Crearea ramurii din ultimul commit al develop. Dezvoltatorul comută pe develop, îl actualizează și creează o nouă ramură feature.
2. Dezvoltare și commit-uri în ramura feature. Dezvoltatorul face modificări, creează commit-uri cu descrieri clare și împinge periodic ramura în repository-ul remote.
3. Sincronizarea cu develop „ în timpul dezvoltării, ramura principală poate avansa. Dezvoltatorul execută rebase sau merge develop în ramura sa feature.
4. Crearea Pull Request „ când funcția este gata, dezvoltatorul deschide un PR pentru revizuirea codului. Echipa verifică codul și lasă comentarii.
5. Îmbinare și ștergere „ după aprobarea PR, ramura este îmbinată în develop și ștearsă atât local, cât și remote.

Sincronizarea periodică cu develop este esențială. Cu cât o ramură feature trăiește mai mult fără a îmbina modificările din develop, cu atât este mai mare probabilitatea conflictelor la îmbinarea finală.

Frecvența sincronizării ramurii feature

Reguli de denumire a ramurilor feature

Denumirea ramurilor „ o parte importantă a disciplinei de echipă. Un standard unitar de denumire permite identificarea rapidă a sarcinii la care se lucrează și a persoanei care o execută.

• feature/nume „ prefixul feature/ este utilizat în Git Flow clasic. Exemplu: feature/added-auth-module.
• feature/JIRA-123-descriere „ legătura cu numărul sarcinii în sistemul de urmărire. Exemplu: feature/PROJ-42-add-login.
• feature/tip/nume „ format extins cu indicarea tipului sarcinii. Exemplu: feature/feat/analytics-dashboard.

Utilizarea ID-ului sarcinii din JIRA, Trello sau alt sistem este cea mai bună practică. Acesta leagă automat codul de sarcină și simplifică căutarea ramurilor prin git log.

Procesul Pull Request

Pull Request (sau Merge Request în GitLab) „ este o solicitare de îmbinare a ramurii feature în develop. PR nu este doar o operațiune tehnică, ci un proces de revizuire a codului în echipă care îmbunătățește calitatea codului și răspândește cunoștințele în cadrul echipei.

Un PR bun conține un titlu cu o descriere scurtă a sarcinii, un link către ticket și o descriere a modificărilor. Dezvoltatorul trebuie să indice exact ce s-a făcut, ce fișiere au fost modificate și dacă există riscuri potențiale pentru alte părți ale proiectului.

Echipa examinează codul în PR, lasă comentarii, solicită modificări (change requests) și aprobă îmbinarea (approve). După aprobare, se execută merge sau squash merge.

Timpul mediu de verificare a PR în dezvoltarea mobilă este de la 4 la 24 de ore. Biblioteca Danger automatizează o parte din verificări, rulând linter-e și teste direct în PR.

Recomandări pentru crearea unui PR bun

• Dimensiune „ nu mai mult de 300-400 de linii de modificări. PR-urile mari sunt greu de revizuit, calitatea verificării scade.
• Un PR „ o sarcină „ evitați amestecarea modificărilor fără legătură într-o singură solicitare.
• Capturi de ecran „ pentru modificările UI, atașați capturi de ecran înainte și după.
• Teste „ pentru funcționalitatea nouă, scrieți teste unitare și includeți-le în PR.

Strategii de îmbinare a ramurilor feature

După aprobarea PR, ramura feature poate fi îmbinată în develop în diferite moduri. Alegerea strategiei de îmbinare influențează istoricul commit-urilor și posibilitatea de revenire a modificărilor.

• Merge commit „ creează un commit de îmbinare, păstrând întregul istoric al commit-urilor ramurii feature. Istoricul rămâne complet, dar graful de ramificare devine mai complex.
• Squash merge „ combină toate commit-urile ramurii feature într-unul singur și îl adaugă deasupra develop. Istoricul devine mai curat, dar informațiile despre commit-urile intermediare se pierd.
• Rebase and merge „ rescrie commit-urile ramurii feature deasupra ultimului commit develop și îmbină fără un commit suplimentar. Istoricul rămâne liniar.

Pentru proiectele mobile cu lansări frecvente, cel mai des se utilizează squash merge: oferă un istoric curat în develop, iar detaliile dezvoltării rămân în descrierea PR și în sarcina tracker-ului.

Greșeli tipice la lucrul cu Feature Branch

Chiar și dezvoltatorii experimentați fac greșeli atunci când lucrează cu ramurile feature. Cunoașterea problemelor tipice ajută la evitarea pierderii de timp și date.

• Durata prea lungă de viață a ramurii „ ramura feature trăiește mai mult de 2-3 săptămâni fără sincronizare cu develop, ceea ce duce la conflicte masive de îmbinare.
• Commit-uri cu descrieri neclare „ mesaje de tip „fix” sau „update” nu permit înțelegerea a ce a fost modificat și de ce.
• Amestecarea sarcinilor „ într-o singură ramură feature se dezvoltă două funcții fără legătură, ceea ce face imposibilă revenirea selectivă.
• Lipsa sincronizării „ dezvoltatorul nu face git fetch și nu actualizează develop, ceea ce duce la conflicte la merge-ul final.

Cea mai bună modalitate de a evita aceste probleme este să conveniți asupra regulilor de lucru la începutul proiectului și să utilizați verificări automate în pipeline-ul CI/CD.

Exemple de comenzi pentru lucrul cu Feature Branch

Să analizăm un scenariu practic: un dezvoltator începe o nouă funcție de autentificare într-o aplicație mobilă. Creează o ramură feature, lucrează la cod și finalizează sarcina cu un Pull Request.

# Actualizarea develop și crearea ramurii feature
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Lucrul la funcție: commit-uri
git add src/ui/login/
git commit -m "Add login screen layout"

# Trimiterea ramurii feature pe server
git push origin feature/add-login-screen

# Sincronizarea cu develop (rebase)
git fetch origin develop
git rebase origin/develop

# După aprobarea PR: actualizarea local develop și ștergerea ramurii
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

Comanda git branch -d șterge ramura numai după ce modificările sale au fost complet îmbinate. Dacă ramura nu este îmbinată, Git va sugera utilizarea git branch -D pentru ștergerea forțată „ utilizați acest flag cu prudență.

Automatizarea verificărilor în ramura feature

Pipeline-ul CI/CD trebuie să ruleze pentru fiecare ramură feature înainte de crearea PR. Acest lucru permite detectarea problemelor într-un stadiu incipient, înainte ca codul să ajungă la revizuirea altor dezvoltatori.

# GitHub Actions pentru verificarea ramurii feature
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

Pipeline-ul verifică dacă codul se compilează, testele trec și stilul codului corespunde standardelor acceptate în echipă. Numai după trecerea tuturor verificărilor se poate crea un Pull Request.