Release Branch در Git — چیست، هدف و فرآیند کار

Release Branch در Git چیست

Release Branch (شاخه انتشار) — شاخه موقتی در Git Flow است که از develop ایجاد می‌شود وقتی تیم تصمیم می‌گیرد مجموعه قابلیت‌های فعلی برای انتشار آماده است. این شاخه دقیقاً به اندازه مدت زمان آماده‌سازی نهایی انتشار وجود دارد — از چند ساعت تا چند روز.

هدف اصلی شاخه release — تثبیت مجموعه مشخصی از قابلیت‌ها برای انتشار بدون توقف توسعه نسخه‌های بعدی است. در حالی که شاخه release برای انتشار آماده می‌شود، سایر توسعه‌دهندگان می‌توانند به ادغام شاخه‌های feature در develop برای انتشار بعدی ادامه دهند.

در شاخه release قابلیت‌های جدید ایجاد نمی‌شود — فقط رفع باگ، به‌روزرسانی نسخه برنامه، بومی‌سازی و مستندات. پس از اتمام همه کارها، شاخه release در main ادغام می‌شود (به عنوان انتشار نشانه‌گذاری می‌شود) و دوباره در develop (تا رفع باگ‌ها به نسخه‌های آینده برسند).

به گفته Atlassian, 2024، شاخه‌های release برای پروژه‌های با چرخه‌های انتشار منظم حیاتی هستند — آنها قابلیت پیش‌بینی و ثبات فرآیند انتشار را تضمین می‌کنند.

چرخه حیات شاخه release

چرخه حیات شاخه release از ایجاد تا حذف شامل چند مرحله است. درک هر مرحله به تیم کمک می‌کند اقدامات را هماهنگ کرده و از اشتباهات جلوگیری کند.

1. ایجاد — از آخرین commit develop شاخه‌ای با نام release/2.5.0 ایجاد می‌شود. develop به پذیرش شاخه‌های feature برای نسخه بعدی ادامه می‌دهد.
2. آماده‌سازی — در شاخه release نسخه برنامه در build.gradle، Info.plist و سایر فایل‌های پیکربندی به‌روزرسانی می‌شود.
3. رفع باگ — باگ‌های بحرانی یافت شده در فرآیند تست نهایی رفع می‌شوند. فقط باگ‌ها — بدون قابلیت جدید.
4. تست نهایی — تیم QA تست رگرسیون را روی شاخه release انجام می‌دهد. باگ‌های جدید برای رفع به همان شاخه ارسال می‌شوند.
5. ادغام در main — شاخه release با پرچم --no-ff در main ادغام می‌شود. تگ انتشار ایجاد می‌شود: v2.5.0.
6. ادغام در develop — شاخه release دوباره در develop ادغام می‌شود تا رفع باگ‌های انتشار وارد توسعه جاری شوند.
7. حذف — شاخه release به صورت محلی و از راه دور حذف می‌شود، زیرا وظیفه آن انجام شده است.

بند ۶ — ادغام معکوس در develop — اغلب فراموش می‌شود، اما حیاتی است. بدون آن، رفع باگ‌های انجام شده در release وارد develop نمی‌شوند و در انتشار بعدی همان اشتباهات ممکن است دوباره ظاهر شوند.

مدت‌های معمول مراحل شاخه release

عمر شاخه release به پیچیدگی انتشار و کیفیت کد در develop بستگی دارد. به طور متوسط آماده‌سازی برای یک برنامه موبایل متوسط ۲ تا ۵ روز کاری طول می‌کشد.

در شاخه release چه کاری انجام می‌شود

در شاخه release مجموعه محدودی از وظایف انجام می‌شود. هرگونه انحراف از این لیست مدل Git Flow را نقض کرده و برای ثبات انتشار ریسک ایجاد می‌کند.

قانون ممنوعیت قابلیت‌های جدید — مهم‌ترین قانون در شاخه release است. اگر قابلیتی به انتشار نرسیده، منتظر چرخه بعدی می‌ماند. تلاش برای وارد کردن قابلیت ناتمام به شاخه release — دلیل اصلی تأخیر در مهلت‌ها و باگ‌های تولید است.

به‌روزرسانی نسخه در پروژه موبایل

در شاخه release شماره نسخه برنامه حتماً به‌روزرسانی می‌شود. برای Android این فیلدهای versionCode و versionName در build.gradle هستند، برای iOS — CFBundleShortVersionString در Info.plist.

// build.gradle (app-level) — به‌روزرسانی نسخه در شاخه release
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// برای iOS — به‌روزرسانی Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

تفاوت‌های release و hotfix

توسعه‌دهندگان تازه‌کار اغلب شاخه‌های release و hotfix را اشتباه می‌گیرند، اگرچه هدف آنها اساساً متفاوت است. اشتباه در انتخاب نوع شاخه می‌تواند منجر به تأخیر رفع بحرانی یا اختلال در فرآیند انتشار شود.

• منبع — release از develop ایجاد می‌شود، hotfix — از main. این تفاوت اصلی است که بقیه موارد را تعیین می‌کند.
• فوریت — release برنامه‌ریزی شده: تیم خودش تصمیم می‌گیرد چه زمانی آماده‌سازی را شروع کند. Hotfix فوری است: مشکل در تولید نیاز به رفع فوری دارد.
• محتوا — release می‌تواند شامل چندین رفع و به‌روزرسانی نسخه باشد. Hotfix فقط شامل یک رفع بحرانی است.
• ادغام — release در main و develop ادغام می‌شود. Hotfix نیز در main و develop ادغام می‌شود، اما با اولویت.
• عمر — release از ۱ تا ۷ روز عمر می‌کند. Hotfix از ۳۰ دقیقه تا ۱ روز عمر می‌کند.

اگر باگ در فرآیند آماده‌سازی انتشار (در شاخه release) کشف شود — این یک رفع باگ معمولی است. اگر باگ در تولید (روی main) کشف شود — این hotfix است و حتی اگر شاخه release وجود داشته باشد، از main ایجاد می‌شود.

قوانین نام‌گذاری شاخه‌های release

استاندارد یکپارچه نام‌گذاری شاخه‌های release پیمایش در مخزن را ساده می‌کند و به سیستم‌های CI/CD اجازه می‌دهد به طور خودکار تشخیص دهند که شاخه به فرآیند انتشار مربوط است.

• release/X.Y.Z — قالب استاندارد Git Flow، که در آن X.Y.Z نسخه انتشار است. مثال: release/2.5.0.
• release/نام — قالب جایگزین با نام کد انتشار. مثال: release/merlin.
• release/تاریخ — قالب با تاریخ انتشار. به ندرت استفاده می‌شود، زیرا نسخه مهم‌تر از تاریخ است. مثال: release/2024-12-01.

قالب release/X.Y.Z — ترجیح داده می‌شود، زیرا شاخه را به وضوح به شماره نسخه‌ای که به انتشار اختصاص می‌یابد مرتبط می‌کند. این کار جستجو و پردازش خودکار توسط اسکریپت‌های CI/CD را ساده می‌کند.

استراتژی ادغام معکوس در develop

ادغام معکوس (merge back) شاخه release در develop — یکی از مهم‌ترین و در عین حال اغلب نادیده گرفته شده‌ترین عملیات‌ها است. بدون آن، تمام رفع باگ‌های انجام شده در release فقط در نسخه انتشار باقی می‌مانند و وارد چرخه انتشار بعدی نمی‌شوند.

فرآیند ادغام معکوس پس از آن انجام می‌شود که شاخه release قبلاً در main ادغام شده است. ابتدا release در develop ادغام می‌شود، سپس — حذف می‌شود. این تضمین می‌کند که develop شامل تمام اصلاحات انجام شده در فرآیند آماده‌سازی انتشار است.

پس از ادغام معکوس ممکن است تضادهایی ایجاد شود — به خصوص اگر در develop شاخه‌های feature جدیدی ظاهر شده باشند که همان فایل‌ها را تغییر داده‌اند. توسعه‌دهنده مسئول انتشار این تضادها را حل کرده و develop را به سرور ارسال می‌کند.

برخی تیم‌ها برای ادغام معکوس به جای merge از rebase استفاده می‌کنند تا تاریخچه خطی بماند. با این حال merge برای develop ایمن‌تر است، زیرا تاریخچه commit‌هایی را که ممکن است توسط سایر توسعه‌دهندگان استفاده شده باشند بازنویسی نمی‌کند.

نمونه دستورات کار با release

بیایید چرخه کامل کار با شاخه release را بررسی کنیم: از ایجاد تا حذف پس از انتشار موفق برنامه موبایل نسخه ۲.۵.۰.

# 1. ایجاد شاخه release از develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. به‌روزرسانی نسخه و رفع باگ
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. رفع باگ‌ها (فقط bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. ارسال شاخه release به سرور
git push origin release/2.5.0

# 5. ادغام release در main
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
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. حذف شاخه release
git branch -d release/2.5.0
git push origin --delete release/2.5.0

دستورات ۵ و ۶ — ادغام دوگانه — حیاتی هستند. ابتدا main کد انتشار و تگ را دریافت می‌کند، سپس develop با رفع باگ‌های release همگام‌سازی می‌شود. اگر مرحله ۶ حذف شود، اصلاحات انتشار وارد چرخه توسعه بعدی نمی‌شوند.

خودکارسازی فرآیند انتشار

برای پروژه‌های موبایل با انتشار منظم، فرآیند ایجاد شاخه release و به‌روزرسانی نسخه می‌تواند از طریق اسکریپت‌های CI/CD خودکار شود. GitHub Actions امکان ایجاد workflow را فراهم می‌کند که با کلیک دکمه، شاخه release با به‌روزرسانی خودکار نسخه ایجاد کند.

برای پروژه‌های موبایل با انتشار منظم، فرآیند ایجاد شاخه release و به‌روزرسانی نسخه می‌تواند از طریق اسکریپت‌های CI/CD خودکار شود. GitHub Actions امکان ایجاد workflow را فراهم می‌کند که با کلیک دکمه، شاخه release با به‌روزرسانی خودکار نسخه ایجاد کند.

# GitHub Actions — خودکارسازی ایجاد شاخه release
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 }}