Develop Branch در Git — چیست، هدف و اصل کار

Develop Branch در Git چیست

Develop Branch (شاخه توسعه) — یک شاخه طولانی‌عمر در Git Flow است که به عنوان گره مرکزی برای یکپارچه‌سازی کد از همه توسعه‌دهندگان عمل می‌کند. شاخه‌های feature پس از اتمام توسعه و گذراندن کد-ریویو در آن ادغام می‌شوند.

کد در develop همیشه در وضعیتی آماده برای ایجاد release قرار دارد، اگرچه هنوز در تولید منتشر نشده است. این بدان معناست که تمام ویژگی‌های موجود در develop بررسی، تست و تأیید یکپارچه‌سازی را پشت سر گذاشته‌اند، اما هنوز منتظر چرخه release خود هستند.

برخلاف main، که در آن هر نسخه از کد یک release است، develop حاوی جریان پیوسته‌ای از تغییرات است. commitها در develop با ادغام شاخه‌های feature ظاهر می‌شوند، که ممکن است چندین بار در روز رخ دهد.

به گزارش Vincent Driessen، 2010، develop عنصر کلیدی یک مدل شاخه‌بندی موفق است، زیرا کارهای در حال انجام را از نسخه‌های آماده انتشار جدا می‌کند.

تفاوت‌های develop و main branch

درک تفاوت‌های بین develop و main برای کار صحیح در Git Flow حیاتی است. این شاخه‌ها وظایف متفاوتی دارند و الزامات متفاوتی برای پایداری دارند.

جداسازی develop و main به تیم اجازه می‌دهد به طور مداوم کد جدید را یکپارچه کند بدون اینکه پایداری نسخه تولیدی به خطر بیفتد. توسعه‌دهندگان می‌توانند کد خود را بلافاصله پس از تأیید PR در develop ببینند، حتی قبل از release رسمی.

نقش develop در Git Flow

در مدل Git Flow، develop جایگاه مرکزی بین شاخه‌های feature (منبع تغییرات) و شاخه‌های release (آماده‌سازی برای انتشار) دارد. درک این سلسله‌مراتب اساس شاخه‌بندی مؤثر است.

• Feature → Develop — هر ویژگی تکمیل‌شده از طریق Pull Request با کد-ریویو در develop ادغام می‌شود.
• Develop → Release — وقتی حجم کافی از تغییرات برای release جمع شد، شاخه release از develop ایجاد می‌شود.
• Release → Main + Develop — پس از آماده‌سازی نهایی، شاخه release در main (release) و دوباره در develop (رفع باگ) ادغام می‌شود.
• Hotfix → Main + Develop — اصلاحات بحرانی از main ایجاد و در هر دو شاخه ادغام می‌شوند.

چنین ساختاری تضمین می‌کند که develop همیشه حاوی آخرین نسخه کد با تمام ویژگی‌های جدید است، و main — فقط کد تولیدی تأییدشده. این به ویژه برای پروژه‌های موبایل با چرخه طولانی بررسی در App Store و Google Play مهم است.

ارتباط develop با سایر شاخه‌های Git Flow

Develop به عنوان حلقه مرکزی بین شاخه‌های feature، release و hotfix عمل می‌کند. درک جهت‌های ادغام اساس جلوگیری از تعارضات و از دست رفتن commitها است.

الزامات کیفیت کد در develop

کیفیت کد در develop باید بالا باشد، اما مطلق نیست. برخلاف main، که در آن هر خطا به معنای hotfix فوری است، develop نواقص جزئی را که قبل از release برطرف می‌شوند مجاز می‌داند.

حداقل الزامات برای کد قبل از ادغام در develop:

• کامپایل — کد باید بدون خطا کامپایل شود. کامپایل خراب در develop کار کل تیم را مسدود می‌کند.
• تست‌های واحد — تمام تست‌های موجود باید پاس شوند. کد جدید باید حداقل 70% پوشش تست داشته باشد.
• Code style — کد باید با استانداردهای قالب‌بندی و نام‌گذاری پذیرفته‌شده در تیم مطابقت داشته باشد.
• عدم استفاده از API منسوخ — استفاده از روش‌های منسوخ در کد جدید مجاز نیست.

بررسی‌های خودکار در خط لوله CI/CD باید روی هر push به develop اجرا شوند. اگر کامپایل خراب شود، توسعه‌دهنده مسئول باید مشکل را ظرف یک ساعت برطرف کند یا commit خود را برگرداند.

بررسی‌های CI/CD برای develop

پیکربندی GitHub Actions برای develop تضمین می‌کند که هر PR قبل از ادغام بررسی خودکار را پشت سر می‌گذارد. خط لوله معمولی شامل کامپایل، تست‌ها و لینتینگ است.

# GitHub Actions — بررسی develop پس از ادغام
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

قوانین ادغام در develop

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

• فقط از طریق Pull Request — push مستقیم به develop ممنوع است. همه تغییرات کد-ریویو می‌شوند.
• حداقل یک تأیید — PR باید حداقل توسط یک توسعه‌دهنده که در任务 شرکت نداشته تأیید شود.
• Squash merge — توصیه می‌شود تمام commitهای شاخه feature در یک commit هنگام ادغام در develop برای تاریخچه تمیز ترکیب شوند.
• به‌روزرسانی PR — قبل از ادغام، PR باید نسبت به آخرین commit develop به‌روز شود (rebase یا merge).

قانون به‌روزرسانی PR به ویژه مهم است. اگر شاخه feature یک هفته پیش ایجاد شده و develop 50 commit جلوتر رفته باشد، ادغام مستقیم می‌تواند منجر به تعارضاتی شود که بهتر است در بافت PR حل شوند، نه در develop.

محافظت develop از ادغام‌های نادرست

Branch protection rules (قوانین محافظت از شاخه) — تنظیماتی در سطح GitHub، GitLab یا Bitbucket هستند که از تغییرات نادرست در develop جلوگیری می‌کنند. آنها تضمین می‌کنند که حتی یک push تصادفی شاخه یکپارچه‌سازی را خراب نمی‌کند.

قوانین محافظتی توصیه‌شده برای develop:

• Require pull request — push مستقیم به develop را ممنوع کن. همه تغییرات فقط از طریق PR.
• Require approvals — حداقل 1-2 تأیید قبل از ادغام PR.
• Require status checks — اگر خط لوله CI/CD پاس نشد، ادغام را مسدود کن.
• Require up-to-date — شاخه PR باید قبل از ادغام نسبت به develop به‌روز شود.
• Restrict push access — حقوق push به develop را فقط برای توسعه‌دهندگان ارشد محدود کن.

پیکربندی محافظت از develop 10 دقیقه طول می‌کشد، اما از هفته‌ها توقف مرتبط با خراب شدن شاخه یکپارچه‌سازی جلوگیری می‌کند. برای پروژه‌های موبایل با تیم‌های چندپلتفرمی این به ویژه مهم است.

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

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

# همگام‌سازی صبحگاهی develop
git checkout develop
git pull origin develop

# ایجاد شاخه feature جدید از develop
git checkout -b feature/add-push-notifications

# کار روی ویژگی...
git add . && git commit -m "Add FCM integration"

# به‌روزرسانی develop در طول توسعه
git fetch origin develop
git rebase origin/develop

# پس از تأیید PR — به‌روزرسانی develop محلی
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

دستور git pull در develop دو عملیات را همزمان انجام می‌دهد: git fetch (commitهای جدید را از سرور دریافت می‌کند) و git merge (آنها را با شاخه محلی ادغام می‌کند). برای develop این روش استاندارد همگام‌سازی است.

بازیابی develop پس از ادغام خراب

اگر کدی که کامپایل را خراب کرده وارد develop شد، باید سریع عمل کرد. هر ساعت توقف develop به معنای مسدود شدن کار کل تیم توسعه‌دهندگان است.

اگر کدی که کامپایل را خراب کرده وارد develop شد، از git revert برای ایجاد یک commit جدید که تغییرات مشکل‌دار را لغو می‌کند استفاده کنید. از git reset در develop استفاده نکنید — این تاریخچه‌ای را که سایر شرکت‌کنندگان دارند بازنویسی می‌کند.

# یافتن commit مشکل‌دار
git log --oneline develop

# لغو commit از طریق revert (ایمن)
git revert a1b2c3d

# ارسال اصلاحیه به develop راه دور
git push origin develop

# مشاهده تغییرات در یک commit خاص
git show a1b2c3d --stat