Feature Branch Git-də: nədir, necə yaratmaq və brançlarla işləmək

Feature Branch nədir Git-də

Feature Branch (funksiya budağı) — bu, ayrıca funksionallığın işlənməsi üçün develop-dan yaradılan Git-də müvəqqəti budaqdır. Uzunömürlü main və develop budaqlarından fərqli olaraq, feature budaqları məhdud müddət — bir neçə saatdan bir neçə həftəyə qədər mövcud olur.

Feature branch-in əsas məqsədi bir tapşırıqla əlaqəli dəyişiklikləri qalan koddan təcrid etməkdir. Tərtibatçı öz budağında təcrübələr apara bilər, çoxlu commitlər edə bilər və hətta kodu sındıra bilər, komandanın digər üzvlərinin işinə təsir etmədən.

İşlənmə tamamlandıqdan sonra feature budağı Pull Request vasitəsilə məcburi kod icmalı ilə develop-ə geri birləşdirilir. Birləşdirmədən sonra budaq adətən silinir ki, repozitori təmiz qalsın.

Vincent Driessen, 2010-a görə, feature budaqları ilə Git Flow modeli müxtəlif budaq növləri arasında aydın məsuliyyət bölgüsü sayəsində sənaye standartına çevrildi.

Feature Branch ilə iş workflow-u

Workflow feature branch ilə tərtibatçının hər yeni funksiya üçün yerinə yetirdiyi addımlar ardıcıllığından ibarətdir. Bu proses birləşdirmə münaqişələrini minimuma endirir və kod keyfiyyətinə nəzarəti təmin edir.

1. Budağın yaradılması develop-in son commit-indən. Tərtibatçı develop-a keçir, onu yeniləyir və yeni feature budağı yaradır.
2. İşlənmə və commitlər feature budağında. Tərtibatçı dəyişikliklər edir, aydın təsvirlərlə commitlər edir və dövri olaraq budağı uzaq repozitoriyə push edir.
3. Develop ilə sinxronizasiya — işlənmə zamanı əsas budaq irəli gedə bilər. Tərtibatçı öz feature budağına rebase və ya merge develop edir.
4. Pull Request-in yaradılması — funksiya hazır olduqda, tərtibatçı kod icmalı üçün PR açır. Komanda kodu yoxlayır və şərhlər buraxır.
5. Birləşdirmə və silmə — PR təsdiqləndikdən sonra budaq develop-ə birləşdirilir və həm lokal, həm də uzaqdan silinir.

Dövri develop ilə sinxronizasiya kritik əhəmiyyətlidir. Feature budağı develop-dən dəyişiklikləri birləşdirmədən nə qədər uzun yaşayırsa, son birləşdirmədə münaqişə ehtimalı bir o qədər yüksəkdir.

Feature budağının sinxronizasiya tezliyi

Feature budaqlarının adlandırma qaydaları

Budaqların adlandırılması — komanda intizamının vacib hissəsidir. Vahid ad standartı hansı tapşırıq üzərində iş getdiyini və onu kimin yerinə yetirdiyini tez müəyyən etməyə imkan verir.

• feature/ad — feature/ prefiksi klassik Git Flow-da istifadə olunur. Nümunə: feature/added-auth-module.
• feature/JIRA-123-təsvir — izləmə sistemində tapşırıq nömrəsinə bağlama. Nümunə: feature/PROJ-42-add-login.
• feature/növ/ad — tapşırıq növünü göstərən genişləndirilmiş format. Nümunə: feature/feat/analytics-dashboard.

JIRA, Trello və ya digər sistemdən tapşırıq ID-si istifadə etmək ən yaxşı təcrübədir. O, avtomatik olaraq kodu tapşırıqla əlaqələndirir və git log vasitəsilə budaqların axtarışını asanlaşdırır.

Pull Request prosesi

Pull Request (və ya GitLab-da Merge Request) — feature budağının develop-ə birləşdirilməsi üçün sorğudur. PR sadəcə texniki əməliyyat deyil, kod keyfiyyətini artıran və komanda daxilində bilikləri yayan komanda kod icmalı prosesidir.

Yaxşı PR tapşırığın qısa təsviri ilə başlıq, ticketa keçid və dəyişikliklərin təsvirini ehtiva edir. Tərtibatçı dəqiq nə edildiyini, hansı faylların dəyişdirildiyini və layihənin digər hissələri üçün potensial risklərin olub-olmadığını göstərməlidir.

Komanda PR-də kodu nəzərdən keçirir, şərhlər buraxır, dəyişikliklər tələb edir (change requests) və birləşdirməni təsdiqləyir (approve). Təsdiqləmədən sonra merge və ya squash merge yerinə yetirilir.

Mobil inkişafda PR-nin orta yoxlama müddəti 4 ilə 24 saat arasındadır. Danger kitabxanası yoxlamaların bir hissəsini avtomatlaşdırır, linterləri və testləri birbaşa PR-də işə salır.

Yaxşı PR yaratmaq üçün tövsiyələr

• Ölçü — 300-400 sətirdən çox olmamalıdır. Böyük PR-ləri nəzərdən keçirmək çətindir, yoxlama keyfiyyəti aşağı düşür.
• Bir PR — bir tapşırıq — bir sorğuda əlaqəsiz dəyişiklikləri qarışdırmaqdan çəkinin.
• Ekran görüntüləri — UI dəyişiklikləri üçün əvvəl və sonra ekran görüntüləri əlavə edin.
• Testlər — yeni funksionallıq üçün vahid testlər yazın və onları PR-ə daxil edin.

Feature budaqlarının birləşdirmə strategiyaları

PR təsdiqləndikdən sonra feature budağı develop-ə müxtəlif yollarla birləşdirilə bilər. Birləşdirmə strategiyasının seçimi commit tarixçəsinə və dəyişikliklərin geri qaytarılma imkanına təsir edir.

• Merge commit — feature budağının bütün commit tarixçəsini qoruyaraq birləşdirmə commit-i yaradır. Tarixçə tam qalır, lakin budaqlanma qrafiki mürəkkəbləşir.
• Squash merge — feature budağının bütün commit-lərini birinə birləşdirir və develop-in üstünə əlavə edir. Tarixçə təmizlənir, lakin aralıq commit-lər haqqında məlumat itir.
• Rebase and merge — feature budağının commit-lərini develop-in son commit-inin üstünə yenidən yazır və əlavə commit olmadan birləşdirir. Tarixçə xətti qalır.

Tez buraxılışları olan mobil layihələr üçün ən çox squash merge istifadə olunur: develop-də təmiz tarixçə verir, işlənmə detalları isə PR təsvirində və tracker tapşırığında qalır.

Feature Branch ilə işdə tipik səhvlər

Hətta təcrübəli tərtibatçılar feature budaqları ilə işdə səhvlərə yol verirlər. Tipik problemləri bilmək vaxt və məlumat itkisinin qarşısını almağa kömək edir.

• Budağın çox uzun yaşaması — feature budağı develop ilə sinxronizasiya olmadan 2-3 həftədən çox yaşayır, bu da kütləvi birləşdirmə münaqişələrinə səbəb olur.
• Qeyri-müəyyən təsvirlərlə commitlər — “fix” və ya “update” kimi mesajlar nəyin dəyişdirildiyini və niyə dəyişdirildiyini anlamağa imkan vermir.
• Tapşırıqların qarışdırılması — bir feature budağında iki əlaqəsiz funksiya işlənir ki, bu da seçmə geri qaytarmanı qeyri-mümkün edir.
• Sinxronizasiyanın olmaması — tərtibatçı git fetch etmir və develop-i yeniləmir, buna görə son merge-də münaqişələr yaranır.

Bu problemlərin qarşısını almağın ən yaxşı yolu layihənin başlanğıcında iş qaydalarını müəyyən etmək və CI/CD pipeline-da avtomatik yoxlamalardan istifadə etməkdir.

Feature Branch ilə iş üçün əmr nümunələri

Praktik ssenarini nəzərdən keçirək: tərtibatçı mobil tətbiqdə yeni avtorizasiya funksiyasına başlayır. Feature budağı yaradır, kod üzərində işləyir və tapşırığı Pull Request ilə tamamlayır.

# Develop-in yenilənməsi və feature budağının yaradılması
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Funksiya üzərində iş: commitlər
git add src/ui/login/
git commit -m "Add login screen layout"

# Feature budağının serverə göndərilməsi
git push origin feature/add-login-screen

# Develop ilə sinxronizasiya (rebase)
git fetch origin develop
git rebase origin/develop

# PR təsdiqləndikdən sonra: lokal develop-in yenilənməsi və budağın silinməsi
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

git branch -d əmri budağı yalnız onun dəyişiklikləri tam birləşdirildikdən sonra silir. Budaq birləşdirilməyibsə, Git məcburi silmə üçün git branch -D istifadə etməyi təklif edəcək — bu flag-ı ehtiyatla istifadə edin.

Feature budağında yoxlamaların avtomatlaşdırılması

CI/CD pipeline hər feature budağı üçün PR yaradılmazdan əvvəl işə düşməlidir. Bu, kod digər tərtibatçıların icmalına düşməzdən əvvəl problemləri erkən mərhələdə aşkar etməyə imkan verir.

# Feature budağını yoxlamaq üçün GitHub Actions
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 kodun kompilyasiya olunduğunu, testlərin keçdiyini və kod stilinin komandada qəbul edilmiş standartlara uyğun olduğunu yoxlayır. Yalnız bütün yoxlamalardan keçdikdən sonra Pull Request yaradıla bilər.