Feature Branch در Git: چیست، چگونه ایجاد کنیم و با شاخه‌ها کار کنیم

Feature Branch در Git چیست

Feature Branch (شاخه ویژگی) « یک شاخه موقت در Git است که از develop برای توسعه یک قابلیت جداگانه ایجاد می‌شود. بر خلاف شاخه‌های طولانی‌مدت main و develop، شاخه‌های feature برای مدت محدود « از چند ساعت تا چند هفته وجود دارند.

هدف اصلی feature branch جداسازی تغییرات مرتبط با یک وظیفه از بقیه کد است. توسعه‌دهنده می‌تواند در شاخه خود آزمایش کند، commitهای زیادی انجام دهد و حتی کد را خراب کند، بدون اینکه روی کار سایر اعضای تیم تأثیر بگذارد.

پس از اتمام توسعه، شاخه feature از طریق Pull Request با بررسی کد اجباری به develop بازگردانده می‌شود. پس از ادغام، شاخه معمولاً حذف می‌شود تا مخزن تمیز بماند.

به گزارش Vincent Driessen, 2010، مدل Git Flow با شاخه‌های feature به دلیل تقسیم واضح مسئولیت بین انواع مختلف شاخه‌ها به استاندارد صنعت تبدیل شد.

گردش کار با Feature Branch

گردش کار با feature branch شامل دنباله‌ای از مراحل است که توسعه‌دهنده برای هر ویژگی جدید انجام می‌دهد. این فرآیند تعارضات ادغام را به حداقل می‌رساند و کنترل کیفیت کد را تضمین می‌کند.

1. ایجاد شاخه از آخرین commit develop. توسعه‌دهنده به develop سوئیچ می‌کند، آن را به‌روز می‌کند و یک شاخه feature جدید ایجاد می‌کند.
2. توسعه و commitها در شاخه feature. توسعه‌دهنده تغییرات را اعمال می‌کند، commitهایی با توضیحات واضح ایجاد می‌کند و به طور دوره‌ای شاخه را به مخزن راه دور push می‌کند.
3. همگام‌سازی با develop « در طول توسعه، شاخه اصلی ممکن است جلو بیفتد. توسعه‌دهنده rebase یا merge develop را در شاخه feature خود انجام می‌دهد.
4. ایجاد Pull Request « وقتی ویژگی آماده شد، توسعه‌دهنده یک PR برای بررسی کد باز می‌کند. تیم کد را بررسی و نظرات خود را ثبت می‌کند.
5. ادغام و حذف « پس از تأیید PR، شاخه در develop ادغام و هم به صورت محلی و هم از راه دور حذف می‌شود.

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

دفعات همگام‌سازی شاخه feature

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

نام‌گذاری شاخه‌ها « بخش مهمی از انضباط تیمی است. یک استاندارد نام‌گذاری یکپارچه به شما امکان می‌دهد به سرعت تعیین کنید روی چه وظیفه‌ای کار می‌شود و چه کسی آن را انجام می‌دهد.

• feature/نام « پیشوند feature/ در Git Flow کلاسیک استفاده می‌شود. مثال: feature/added-auth-module.
• feature/JIRA-123-توضیحات « اتصال به شماره وظیفه در سیستم رهگیری. مثال: feature/PROJ-42-add-login.
• feature/نوع/نام « فرمت گسترده با مشخص کردن نوع وظیفه. مثال: feature/feat/analytics-dashboard.

استفاده از شناسه وظیفه از JIRA، Trello یا سیستم دیگر بهترین روش است. این به طور خودکار کد را به وظیفه متصل می‌کند و جستجوی شاخه‌ها را از طریق git log ساده می‌کند.

فرآیند Pull Request

Pull Request (یا Merge Request در GitLab) « درخواستی برای ادغام شاخه feature در develop است. PR فقط یک عملیات فنی نیست، بلکه فرآیند بررسی کد تیمی است که کیفیت کد را بهبود می‌بخشد و دانش را در تیم منتشر می‌کند.

یک PR خوب شامل عنوانی با توضیح مختصر وظیفه، لینک به تیکت و شرح تغییرات است. توسعه‌دهنده باید مشخص کند دقیقاً چه کاری انجام شده، چه فایل‌هایی تغییر کرده‌اند و آیا خطرات بالقوه‌ای برای سایر بخش‌های پروژه وجود دارد.

تیم کد را در PR بررسی می‌کند، نظرات می‌گذارد، تغییرات درخواست می‌کند (change requests) و ادغام را تأیید می‌کند (approve). پس از تأیید، merge یا squash merge انجام می‌شود.

میانگین زمان بررسی PR در توسعه موبایل از 4 تا 24 ساعت است. کتابخانه Danger بخشی از بررسی‌ها را خودکار می‌کند و لینترها و تست‌ها را مستقیماً در PR اجرا می‌کند.

توصیه‌هایی برای ایجاد یک PR خوب

• اندازه « بیش از 300-400 خط تغییرات نباشد. PRهای بزرگ بررسی دشواری دارند، کیفیت بررسی کاهش می‌یابد.
• یک PR « یک وظیفه « از مخلوط کردن تغییرات نامرتبط در یک درخواست خودداری کنید.
• تصاویر « برای تغییرات UI، تصاویر قبل و بعد را ضمیمه کنید.
• تست‌ها « برای قابلیت جدید، تست‌های واحد بنویسید و آنها را در PR بگنجانید.

استراتژی‌های ادغام شاخه‌های feature

پس از تأیید PR، شاخه feature می‌تواند به روش‌های مختلف در develop ادغام شود. انتخاب استراتژی ادغام بر تاریخچه commitها و امکان بازگشت تغییرات تأثیر می‌گذارد.

• Merge commit « یک commit ادغام ایجاد می‌کند و کل تاریخچه commitهای شاخه feature را حفظ می‌کند. تاریخچه کامل می‌ماند، اما گراف انشعاب پیچیده‌تر می‌شود.
• Squash merge « تمام commitهای شاخه feature را در یکی ادغام می‌کند و آن را روی develop قرار می‌دهد. تاریخچه تمیزتر می‌شود، اما اطلاعات مربوط به commitهای میانی از بین می‌رود.
• Rebase and merge « commitهای شاخه feature را روی آخرین commit develop بازنویسی می‌کند و بدون commit اضافی ادغام می‌کند. تاریخچه خطی می‌ماند.

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

اشتباهات رایج هنگام کار با Feature Branch

حتی توسعه‌دهندگان با تجربه نیز هنگام کار با شاخه‌های feature اشتباه می‌کنند. آگاهی از مشکلات رایج به جلوگیری از اتلاف وقت و داده کمک می‌کند.

• عمر بیش از حد شاخه « شاخه feature بیش از 2-3 هفته بدون همگام‌سازی با develop عمر می‌کند که منجر به تعارضات عظیم ادغام می‌شود.
• commitهایی با توضیحات نامشخص « پیام‌هایی مانند «fix» یا «update» مشخص نمی‌کنند چه چیزی و چرا تغییر کرده است.
• مخلوط کردن وظایف « در یک شاخه feature دو عملکرد نامرتبط توسعه می‌یابد که بازگشت انتخابی را غیرممکن می‌کند.
• عدم همگام‌سازی « توسعه‌دهنده git fetch انجام نمی‌دهد و develop را به‌روز نمی‌کند، در نتیجه در merge نهایی تعارضات ایجاد می‌شود.

بهترین راه برای جلوگیری از این مشکلات، توافق بر سر قوانین کار در شروع پروژه و استفاده از بررسی‌های خودکار در خط لوله CI/CD است.

نمونه دستورات کار با Feature Branch

یک سناریوی عملی را در نظر بگیرید: توسعه‌دهنده یک ویژگی جدید احراز هویت در برنامه موبایل را شروع می‌کند. یک شاخه feature ایجاد می‌کند، روی کد کار می‌کند و وظیفه را با Pull Request به پایان می‌رساند.

# به‌روزرسانی develop و ایجاد شاخه feature
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# کار روی ویژگی: commitها
git add src/ui/login/
git commit -m "Add login screen layout"

# ارسال شاخه feature به سرور
git push origin feature/add-login-screen

# همگام‌سازی با develop (rebase)
git fetch origin develop
git rebase origin/develop

# پس از تأیید PR: به‌روزرسانی local develop و حذف شاخه
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

دستور git branch -d شاخه را فقط پس از ادغام کامل تغییراتش حذف می‌کند. اگر شاخه ادغام نشده باشد، Git استفاده از git branch -D را برای حذف اجباری پیشنهاد می‌کند « این پرچم را با احتیاط استفاده کنید.

خودکارسازی بررسی‌ها در شاخه feature

خط لوله CI/CD باید برای هر شاخه feature قبل از ایجاد PR اجرا شود. این امکان شناسایی مشکلات در مراحل اولیه را فراهم می‌کند، قبل از اینکه کد برای بررسی به سایر توسعه‌دهندگان برسد.

# GitHub Actions برای بررسی شاخه feature
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

خط لوله بررسی می‌کند که کد کامپایل می‌شود، تست‌ها پاس می‌شوند و سبک کد مطابق با استانداردهای پذیرفته شده در تیم است. فقط پس از گذراندن تمام بررسی‌ها می‌توان Pull Request ایجاد کرد.