Feature Branch Git-da: nima, qanday yaratish va branchlar bilan ishlash

Feature Branch Git-da nima

Feature Branch (funksiya branchi) — bu Git-da alohida funksionallikni ishlab chiqish uchun develop-dan yaratilgan vaqtinchalik branchdir. Uzoq muddatli main va develop branchlaridan farqli o'laroq, feature branchlari cheklangan vaqt — bir necha soatdan bir necha haftagacha mavjud bo'ladi.

Feature branchning asosiy maqsadi bir vazifa bilan bog'liq o'zgarishlarni qolgan koddan ajratishdir. Dasturchi o'z branchida tajriba o'tkazishi, ko'plab commitlar qilishi va hatto kodni buzishi mumkin, jamoa a'zolarining ishiga ta'sir qilmasdan.

Ishlab chiqish tugagandan so'ng, feature branch Pull Request orqali majburiy kod ko'rib chiqish bilan develop-ga qayta birlashtiriladi. Birlashtirishdan so'ng, branch odatda o'chiriladi, shunda repozitori toza qoladi.

Vincent Driessen, 2010 ma'lumotlariga ko'ra, feature branchlari bilan Git Flow modeli turli branch turlari o'rtasidagi aniq mas'uliyat taqsimoti tufayli sanoat standartiga aylandi.

Feature Branch bilan ishlash workflow-i

Workflow feature branch bilan dasturchining har bir yangi funksiya uchun bajaradigan qadamlar ketma-ketligidan iborat. Bu jarayon birlashtirish to'qnashuvlarini minimallashtiradi va kod sifatini nazorat qilishni ta'minlaydi.

1. Branch yaratish develop-ning oxirgi commitidan. Dasturchi develop-ga o'tadi, uni yangilaydi va yangi feature branch yaratadi.
2. Ishlab chiqish va commitlar feature branchida. Dasturchi o'zgarishlar kiritadi, aniq tavsiflar bilan commitlar qiladi va davriy ravishda branchni uzoq repozitoriyaga push qiladi.
3. Develop bilan sinxronlash — ishlab chiqish davomida asosiy branch oldinga ketishi mumkin. Dasturchi o'z feature branchiga rebase yoki merge develop qiladi.
4. Pull Request yaratish — funksiya tayyor bo'lganda, dasturchi kod ko'rib chiqish uchun PR ochadi. Jamoa kodni tekshiradi va sharhlar qoldiradi.
5. Birlashtirish va o'chirish — PR tasdiqlangandan so'ng, branch develop-ga birlashtiriladi va ham lokal, ham uzoqdan o'chiriladi.

Davriy develop bilan sinxronlash juda muhim. Feature branch develop-dan o'zgarishlarni birlashtirmasdan qancha uzoq yashasa, yakuniy birlashtirishda to'qnashuvlar ehtimoli shuncha yuqori bo'ladi.

Feature branch sinxronlash chastotasi

Feature branchlarini nomlash qoidalari

Branchlarni nomlash — jamoa intizomining muhim qismi. Yagona nomlash standarti qaysi vazifa ustida ish olib borilayotganini va uni kim bajarayotganini tez aniqlash imkonini beradi.

• feature/nom — feature/ prefiksi klassik Git Flow-da ishlatiladi. Misol: feature/added-auth-module.
• feature/JIRA-123-tavsif — kuzatish tizimidagi vazifa raqamiga bog'lash. Misol: feature/PROJ-42-add-login.
• feature/tur/nom — vazifa turini ko'rsatadigan kengaytirilgan format. Misol: feature/feat/analytics-dashboard.

JIRA, Trello yoki boshqa tizimdan vazifa ID-si dan foydalanish eng yaxshi amaliyotdir. U avtomatik ravishda kodni vazifa bilan bog'laydi va git log orqali branchlarni qidirishni soddalashtiradi.

Pull Request jarayoni

Pull Request (yoki GitLab-da Merge Request) — feature branchni develop-ga birlashtirish so'rovidir. PR shunchaki texnik operatsiya emas, balki kod sifatini oshiradigan va jamoa ichida bilimlarni tarqatadigan jamoa kod ko'rib chiqish jarayonidir.

Yaxshi PR vazifaning qisqa tavsifi bilan sarlavha, ticketga havola va o'zgarishlar tavsifini o'z ichiga oladi. Dasturchi aniq nima qilinganligini, qaysi fayllar o'zgartirilganini va loyihaning boshqa qismlari uchun potensial xavflar mavjudligini ko'rsatishi kerak.

Jamoa PR-dagi kodni ko'rib chiqadi, sharhlar qoldiradi, o'zgarishlarni so'raydi (change requests) va birlashtirishni tasdiqlaydi (approve). Tasdiqlashdan so'ng merge yoki squash merge amalga oshiriladi.

Mobil ishlanmada PRni o'rtacha tekshirish vaqti 4 dan 24 soatgacha. Danger kutubxonasi tekshiruvlarning bir qismini avtomatlashtiradi, linterlar va testlarni to'g'ridan-to'g'ri PR-da ishga tushiradi.

Yaxshi PR yaratish bo'yicha tavsiyalar

• Hajm — 300-400 qatordan oshmasligi kerak. Katta PRlarni ko'rib chiqish qiyin, tekshirish sifati pasayadi.
• Bitta PR — bitta vazifa — bitta so'rovda bog'liq bo'lmagan o'zgarishlarni aralashtirishdan saqlaning.
• Ekran tasvirlari — UI o'zgarishlari uchun oldin va keyin ekran tasvirlarini ilova qiling.
• Testlar — yangi funksionallik uchun unit-testlar yozing va ularni PR-ga qo'shing.

Feature branchlarini birlashtirish strategiyalari

PR tasdiqlangandan so'ng, feature branch develop-ga turli yo'llar bilan birlashtirilishi mumkin. Birlashtirish strategiyasini tanlash commitlar tarixiga va o'zgarishlarni qaytarish imkoniyatiga ta'sir qiladi.

• Merge commit — feature branchning barcha commitlar tarixini saqlab, birlashtirish commitini yaratadi. Tarix to'liq qoladi, ammo tarmoqlanish grafigi murakkablashadi.
• Squash merge — feature branchning barcha commitlarini bittaga birlashtiradi va develop-ning ustiga qo'shadi. Tarix tozalanadi, ammo oraliq commitlar haqidagi ma'lumot yo'qoladi.
• Rebase and merge — feature branchning commitlarini develop-ning oxirgi commiti ustiga qayta yozadi va qo'shimcha commitsiz birlashtiradi. Tarix chiziqli qoladi.

Tez nashr qilinadigan mobil loyihalar uchun ko'pincha squash merge ishlatiladi: develop-da toza tarix beradi, ishlab chiqish tafsilotlari esa PR tavsifida va tracker vazifasida qoladi.

Feature Branch bilan ishlashda odatiy xatolar

Hatto tajribali dasturchilar ham feature branchlari bilan ishlashda xatolarga yo'l qo'yadilar. Odatiy muammolarni bilish vaqt va ma'lumot yo'qotilishining oldini olishga yordam beradi.

• Branchning juda uzoq yashashi — feature branch develop bilan sinxronlashmasdan 2-3 haftadan ko'proq yashaydi, bu katta birlashtirish to'qnashuvlariga olib keladi.
• Noaniq tavsiflar bilan commitlar — “fix” yoki “update” kabi xabarlar nima va nima uchun o'zgartirilganini tushunishga imkon bermaydi.
• Vazifalarni aralashtirish — bitta feature branchda ikkita bog'liq bo'lmagan funksiya ishlab chiqiladi, bu esa tanlab qaytarishni imkonsiz qiladi.
• Sinxronlashning yo'qligi — dasturchi git fetch qilmaydi va develop-ni yangilamaydi, shuning uchun yakuniy merge-da to'qnashuvlar yuzaga keladi.

Bu muammolarning oldini olishning eng yaxshi usuli — loyiha boshida ish qoidalarini kelishib olish va CI/CD pipeline-da avtomatik tekshiruvlardan foydalanishdir.

Feature Branch bilan ishlash uchun buyruq misollari

Amaliy ssenariyni ko'rib chiqaylik: dasturchi mobil ilovada yangi autentifikatsiya funksiyasini boshlaydi. Feature branch yaratadi, kod ustida ishlaydi va vazifani Pull Request bilan yakunlaydi.

# Develop-ni yangilash va feature branch yaratish
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Funksiya ustida ishlash: commitlar
git add src/ui/login/
git commit -m "Add login screen layout"

# Feature branchni serverga yuborish
git push origin feature/add-login-screen

# Develop bilan sinxronlash (rebase)
git fetch origin develop
git rebase origin/develop

# PR tasdiqlangandan so'ng: lokal develop-ni yangilash va branchni o'chirish
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

git branch -d buyrug'i branchni faqat uning o'zgarishlari to'liq birlashtirilgandan keyin o'chiradi. Agar branch birlashtirilmagan bo'lsa, Git git branch -D dan majburiy o'chirish uchun foydalanishni taklif qiladi — bu bayroqni ehtiyotkorlik bilan ishlating.

Feature branchida tekshiruvlarni avtomatlashtirish

CI/CD pipeline har bir feature branch uchun PR yaratishdan oldin ishga tushishi kerak. Bu kod boshqa dasturchilarning ko'rib chiqishiga tushishidan oldin muammolarni erta bosqichda aniqlash imkonini beradi.

# Feature branchni tekshirish uchun 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 kodning kompilyatsiya qilinishini, testlarning o'tishini va kod uslubining jamoada qabul qilingan standartlarga mos kelishini tekshiradi. Faqat barcha tekshiruvlardan o'tgandan keyin Pull Request yaratish mumkin.