Git-da Release Branch — bu nima, maqsadi va ish jarayoni

Git-da Release Branch nima

Release Branch (reliz shoxchasi) — bu Git Flow-dagi vaqtinchalik shoxcha bo'lib, jamoa joriy funksiyalar to'plami chiqarishga tayyor deb qaror qilganda develop-dan yaratiladi. U relizning yakuniy tayyorgarligi qancha davom etsa, shuncha mavjud bo'ladi — bir necha soatdan bir necha kungacha.

Release shoxchasining asosiy maqsadi — keyingi versiyalar ishlanmasini to'xtatmasdan, reliz uchun ma'lum funksiyalar to'plamini muzlatishdir. Release shoxchasi chiqarishga tayyorlanayotganda, boshqa ishlab chiqaruvchilar keyingi reliz uchun feature shoxchalarini develop-ga birlashtirishni davom ettirishlari mumkin.

Release shoxchasida yangi funksiyalar yaratilmaydi — faqat xato tuzatishlar, ilova versiyasini yangilash, lokalizatsiya va hujjatlar. Barcha ishlar tugagach, release shoxchasi main-ga birlashtiriladi (reliz sifatida belgilanadi) va qaytib develop-ga (xato tuzatishlar kelajak versiyalarga o'tishi uchun).

Atlassian, 2024 maʼlumotlariga ko'ra, release shoxchalari muntazam reliz sikliga ega loyihalar uchun muhim ahamiyatga ega — ular chiqarish jarayonining bashorat qilish mumkinligi va barqarorligini taʼminlaydi.

Release shoxchasining hayot sikli

Hayot sikli — release shoxchasining yaratilishdan o'chirilishgacha bo'lgan bir necha bosqichni o'z ichiga oladi. Har bir bosqichni tushunish jamoaga harakatlarni muvofiqlashtirish va xatolardan qochishga yordam beradi.

1. Yaratish — develop-ning so'nggi commit-idan release/2.5.0 nomli shoxcha yaratiladi. develop keyingi versiya uchun feature shoxchalarini qabul qilishni davom ettiradi.
2. Tayyorgarlik — release shoxchasida build.gradle, Info.plist va boshqa konfiguratsiya fayllarida ilova versiyasi yangilanadi.
3. Xato tuzatish — yakuniy test jarayonida topilgan muhim xatolar tuzatiladi. Faqat xatolar — yangi funksiyalar yo'q.
4. Yakuniy test — QA jamoasi release shoxchasida regressiya testini o'tkazadi. Yangi xatolar tuzatish uchun o'sha shoxchaga yuboriladi.
5. Main-ga birlashish — release shoxchasi --no-ff bayrog'i bilan main-ga birlashtiriladi. Reliz tegi yaratiladi: v2.5.0.
6. Develop-ga birlashish — release shoxchasi qaytib develop-ga birlashtiriladi, shunda relizdagi xato tuzatishlar joriy ishlanmaga o'tadi.
7. O'chirish — release shoxchasi lokal va masofadan o'chiriladi, chunki uning vazifasi bajarilgan.

6-band — develop-ga qaytib birlashish — ko'pincha unutiladi, lekin bu juda muhim. Usiz release-da qilingan xato tuzatishlar develop-ga o'tmaydi va keyingi relizda xuddi shu xatolar yana paydo bo'lishi mumkin.

Release shoxchasi bosqichlarining odatiy davomiyliklari

Release shoxchasining umri relizning murakkabligi va develop-dagi kod sifatiga bog'liq. O'rtacha o'lchamdagi mobil ilova uchun tayyorgarlik odatda 2 dan 5 ish kunigacha davom etadi.

Release shoxchasida nima qilinadi

Release shoxchasida qat'iy cheklangan vazifalar to'plami bajariladi. Ushbu ro'yxatdan har qanday chetga chiqish Git Flow modelini buzadi va reliz barqarorligi uchun xavf tug'diradi.

Yangi funksiyalarni taqiqlash qoidasi — release shoxchasidagi eng muhim qoida. Agar funksiya relizga ulgurmagan bo'lsa, keyingi siklini kutadi. Tugallanmagan funksiyani release shoxchasiga kiritish urinishi — muddatlarni buzish va ishlab chiqarishdagi xatolarning asosiy sababidir.

Mobil loyihada versiyani yangilash

Release shoxchasida ilova versiyasining raqami majburiy ravishda yangilanadi. Android uchun bu build.gradle dagi versionCode va versionName maydonlari, iOS uchun — Info.plist dagi CFBundleShortVersionString.

// build.gradle (app-level) — release shoxchasida versiyani yangilash
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// iOS uchun — Info.plist ni yangilash
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Release va hotfix o'rtasidagi farqlar

Boshlang'ich ishlab chiqaruvchilar ko'pincha release va hotfix shoxchalarini chalkashtirishadi, garchi ularning maqsadi tubdan farq qilsa. Shoxcha turini tanlashdagi xato muhim tuzatishning kechikishiga yoki reliz jarayonining buzilishiga olib kelishi mumkin.

• Manba — release develop-dan yaratiladi, hotfix — main-dan. Bu qolgan hamma narsani belgilaydigan asosiy farq.
• Shoshilinchlik — release rejalashtirilgan: jamoa o'zi tayyorgarlikni qachon boshlashni hal qiladi. Hotfix shoshilinch: ishlab chiqarishdagi muammo darhol tuzatishni talab qiladi.
• Tarkib — release bir nechta tuzatish va versiya yangilanishini o'z ichiga olishi mumkin. Hotfix faqat bitta muhim tuzatishni o'z ichiga oladi.
• Birlashish — release main va develop-ga birlashtiriladi. Hotfix ham main va develop-ga birlashtiriladi, lekin ustuvor tartibda.
• Yashash muddati — release 1 kundan 7 kungacha yashaydi. Hotfix 30 daqiqadan 1 kungacha yashaydi.

Agar xato relizni tayyorlash jarayonida (release shoxchasida) topilgan bo'lsa — bu oddiy xato tuzatish. Agar xato ishlab chiqarishda (main da) topilgan bo'lsa — bu hotfix va u main-dan yaratiladi, hatto release shoxchasi mavjud bo'lsa ham.

Release shoxchalarini nomlash qoidalari

Yagona release shoxchalarini nomlash standarti repozitoriy bo'ylab navigatsiyani soddalashtiradi va CI/CD tizimlariga shoxchaning reliz jarayoniga tegishli ekanligini avtomatik aniqlashga imkon beradi.

• release/X.Y.Z — Git Flow standart formati, bu yerda X.Y.Z reliz versiyasi. Misol: release/2.5.0.
• release/nom — relizning kod nomi bilan muqobil format. Misol: release/merlin.
• release/sana — reliz sanasi bilan format. Kamdan kam ishlatiladi, chunki versiya sanadan muhimroq. Misol: release/2024-12-01.

release/X.Y.Z formati — afzal ko'riladi, chunki u shoxchani relizga tayinlanadigan versiya raqami bilan aniq bog'laydi. Bu qidirish va CI/CD skriptlari bilan avtomatik ishlov berishni soddalashtiradi.

Develop-ga qaytib birlashish strategiyasi

Qaytib birlashish (merge back) release shoxchasini develop-ga — eng muhim va bir vaqtning o'zida tez-tez o'tkazib yuboriladigan operatsiyalardan biridir. Usiz release-da qilingan barcha xato tuzatishlar faqat reliz versiyasida qoladi va keyingi reliz sikliga o'tmaydi.

Qaytib birlashish jarayoni release shoxchasi allaqachon main-ga birlashtirilganidan so'ng amalga oshiriladi. Avval release develop-ga birlashtiriladi, keyin — o'chiriladi. Bu develop relizni tayyorlash jarayonida qilingan barcha tuzatishlarni o'z ichiga olishini kafolatlaydi.

Qaytib birlashishdan so'ng konfliktlar yuzaga kelishi mumkin — ayniqsa develop-da bir xil fayllarni o'zgartirgan yangi feature shoxchalari paydo bo'lgan bo'lsa. Reliz uchun mas'ul ishlab chiqaruvchi bu konfliktlarni hal qiladi va develop-ni serverga yuboradi.

Ba'zi jamoalar qaytib birlashish uchun merge o'rniga rebase dan foydalanadi, shunda tarix chiziqli bo'ladi. Biroq merge develop uchun xavfsizroq, chunki boshqa ishlab chiqaruvchilar tomonidan allaqachon ishlatilgan commitlar tarixini qayta yozmaydi.

Release bilan ishlash uchun buyruq namunalari

Release shoxchasi bilan to'liq ishlash siklini ko'rib chiqaylik: 2.5.0 versiyali mobil ilovaning muvaffaqiyatli relizidan so'ng yaratishdan o'chirishgacha.

# 1. Develop-dan release shoxchasini yaratish
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Versiyani yangilash va xato tuzatishlar
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Xatolarni tuzatish (faqat bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Release shoxchasini serverga yuborish
git push origin release/2.5.0

# 5. Release ni main-ga birlashtirish
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. Develop-ga qaytib birlashish
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Release shoxchasini o'chirish
git branch -d release/2.5.0
git push origin --delete release/2.5.0

5 va 6-buyruqlar — ikki tomonlama birlashish — juda muhim. Avval main reliz kodini va tegni oladi, keyin develop release-dagi xato tuzatishlar bilan sinxronlanadi. Agar 6-qadam o'tkazib yuborilsa, relizdagi tuzatishlar keyingi ishlanma siklga o'tmaydi.

Reliz jarayonini avtomatlashtirish

Muntazam relizlarga ega mobil loyihalar uchun release shoxchasini yaratish va versiyani yangilash jarayoni CI/CD skriptlari orqali avtomatlashtirilishi mumkin. GitHub Actions tugmani bosganda avtomatik versiya yangilanishi bilan release shoxchasini yaratadigan workflow yaratishga imkon beradi.

Muntazam relizlarga ega mobil loyihalar uchun release shoxchasini yaratish va versiyani yangilash jarayoni CI/CD skriptlari orqali avtomatlashtirilishi mumkin. GitHub Actions tugmani bosganda avtomatik versiya yangilanishi bilan release shoxchasini yaratadigan workflow yaratishga imkon beradi.

# GitHub Actions — release shoxchasini yaratishni avtomatlashtirish
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}