Hotfix Branch: چیست، چگونه ایجاد و در توسعه موبایل استفاده کنیم

Hotfix Branch چیست؟

Hotfix Branch — یک شاخه موقت در Git است که برای رفع سریع نقص‌های بحرانی در محیط تولید ایجاد می‌شود. برخلاف شاخه‌های feature که از develop منشعب می‌شوند و چند روز یا هفته عمر می‌کنند، hotfix از main/master ایجاد می‌شود و دقیقاً به اندازه‌ای که برای رفع باگ نیاز است وجود دارد.

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

طبق داده‌های Google Play Console، میانگین زمان بررسی به‌روزرسانی در Google Play از 2 تا 24 ساعت است. برای App Store بررسی سریع می‌تواند از 1 تا 4 ساعت طول بکشد. شاخه‌های hotfix امکان آماده‌سازی رفع را حتی قبل از پایان بررسی و انتشار آن بلافاصله پس از تأیید فراهم می‌کنند.

اصل کار Hotfix

فرایند hotfix از سه مرحله تشکیل شده است: ایجاد شاخه از main، اعمال رفع و ادغام مجدد با main و develop. تفاوت کلیدی با رفع معمولی — hotfix همیشه با هر دو شاخه ادغام می‌شود تا رفع در انتشار بعدی از دست نرود.

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

چه زمانی Hotfix نیاز است

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

برای برنامه‌های موبایل hotfix همچنین می‌تواند شامل تغییرات سرور باشد، اگر معماری امکان تغییر از راه دور ویژگی‌ها را فراهم کند (feature flags). در این صورت شاخه hotfix ممکن است حداقل باشد یا اصلاً نیازی نباشد، اگر رفع در سمت سرور انجام شود.

مدل‌های انشعاب و جایگاه Hotfix

همه مدل‌های انشعاب از شاخه‌های hotfix پشتیبانی نمی‌کنند. Git Flow سنتی hotfix را به عنوان یک نوع کامل شاخه پیش‌بینی می‌کند، در حالی که رویکردهای مدرن‌تر (GitHub Flow، Trunk-based) مسئله رفع‌های اضطراری را متفاوت حل می‌کنند.

Git Flow و Hotfix

Git Flow — تنها مدلی است که در آن hotfix یک نوع شاخه داخلی در کنار feature و release است. در Git Flow hotfix از main ایجاد می‌شود و پس از اتمام هم با main (با برچسب نسخه) و هم با develop ادغام می‌شود. این تضمین می‌کند که رفع در انتشار بعدی از بین نرود.

GitHub Flow و Trunk-based

GitHub Flow از نوع جداگانه‌ای از شاخه برای hotfix استفاده نمی‌کند. در عوض، توسعه‌دهنده یک شاخه معمولی feature از main ایجاد می‌کند، رفع را اعمال کرده و Pull Request باز می‌کند. پس از بررسی و تست‌های CI، شاخه با main ادغام و بلافاصله مستقر می‌شود. مزیت — سادگی، نقطه ضعف — نبود کانال جداگانه برای رفع‌های فوری.

Trunk-based مسئله hotfix را از طریق commit مستقیم به main (برای موارد بحرانی) با بررسی اجباری پس از انجام حل می‌کند. این رویکرد نیاز به انضباط بالای تیم و تست‌های خودکار قابل اعتماد دارد، زیرا تغییرات بلافاصله به تولید می‌روند.

ایجاد Hotfix Branch

ایجاد hotfix با تغییر به شاخه اصلی و ایجاد یک شاخه جدید با پیشوند hotfix/ شروع می‌شود. بیایید فرایند گام به گام را با مثال رفع یک باگ بحرانی در برنامه موبایل بررسی کنیم.

ایجاد شاخه از main

اولین گام — به main تغییر وضعیت دهید و مطمئن شوید که شاخه به‌روز است. سپس یک شاخه hotfix با نام قابل فهم که ماهیت رفع را منعکس می‌کند ایجاد کنید.

# به main بروید و آخرین تغییرات را دریافت کنید
git checkout main
git pull origin main

# شاخه hotfix ایجاد کنید
git checkout -b hotfix/crash-on-login

پس از ایجاد شاخه می‌توان رفع را اعمال کرد. مهم: hotfix باید حداقل تعداد تغییرات را داشته باشد. نباید کد را بازسازی کرد یا قابلیت‌های جدید اضافه کرد — فقط رفع نقطه‌ای که مشکل را برطرف می‌کند.

ثبت رفع

Commit در hotfix باید پیام informative داشته باشد که به طور واضح مشکل و راه‌حل آن را توصیف کند. فرمت: نوع(حوزه): توضیح کوتاه + لینک به وظیفه در رهگیر.

# فایل‌های تغییر یافته را اضافه کنید
git add src/ui/login/LoginActivity.kt

# یک commit با توضیح ایجاد کنید
git commit -m "fix(login): handle null intent on activity resume

Fixes CRASH-142: NullPointerException when LoginActivity
receives onNewIntent after being destroyed by system"

پیام commit باید شامل توضیح مشکل و لینک به وظیفه باشد. این کار جستجو در تاریخچه را ساده می‌کند و به همکاران کمک می‌کند بفهمند چه چیزی و چرا رفع شده است. برای پروژه‌های موبایل معمولاً نسخه برنامه‌ای که باگ در آن کشف شده نیز ذکر می‌شود.

ادغام با main و develop

گام نهایی — hotfix را مجدداً با main (با برچسب نسخه پچ جدید) و با develop (برای حفظ رفع در انتشار بعدی) ادغام کنید. ابتدا ادغام با main با برچسب ایجاد می‌شود، سپس ادغام با develop.

# با main ادغام کرده و برچسب بسازید
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# با develop ادغام کنید
git checkout develop
git merge --no-ff hotfix/crash-on-login

# تغییرات را به سرور ارسال کنید
git push origin main --tags
git push origin develop

پرچم --no-ff ایجاد commit ادغام را تضمین می‌کند، حتی اگر hotfix از طریق fast-forward قابل اعمال باشد. این اطلاعات مربوط به انجام رفع اضطراری را حفظ کرده و تحلیل تاریخچه را در آینده ساده می‌کند.

تفاوت Hotfix با Feature و Release

Hotfix اساساً با شاخه‌های feature و release از نظر هدف، عمر و قوانین ادغام تفاوت دارد. درک این تفاوت‌ها برای سازماندهی صحیح فرایندهای Git در تیم حیاتی است.

شاخه feature برای عملکرد جدید طراحی شده است. از چند روز تا چند هفته عمر می‌کند، از develop ایجاد و به develop ادغام می‌شود. Feature می‌تواند شامل commitهای زیادی از جمله آزمایشی باشد که بعداً از طریق squash یا rebase فشرده می‌شوند.

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

Hotfix اما مستقیماً از main ایجاد و ادغام می‌شود و develop را دور می‌زند (هرچند پس از رفع با develop نیز همگام‌سازی می‌شود). حداقل تعداد تغییرات را دارد و حداقل زمان وجود دارد. اگر feature یا release می‌توانند تا چرخه بعدی به تعویق بیفتند، hotfix — نمی‌تواند.

برای توسعه موبایل این تفاوت به ویژه مهم است: App Store و Google Play اجازه انتشار نسخه‌های پچ را جدا از انتشارهای اصلی می‌دهند. شاخه hotfix فرایندی را تضمین می‌کند که در آن انتشار پچ با ویژگی‌های ناتمام混混 نشود.

اشتباهات رایج در کار با Hotfix

اشتباهات در کار با hotfix می‌توانند مزایای رفع اضطراری را از بین ببرند. بیایید پنج مشکل رایج که در تیم‌های استفاده‌کننده از Git Flow رخ می‌دهد بررسی کنیم.

• ایجاد hotfix از develop — اگر hotfix از develop ایجاد شود، ویژگی‌های ناتمام ممکن است وارد پچ شوند. Hotfix باید فقط از main ایجاد شود تا تضمین شود که فقط کد پایدار در رفع گنجانده شده است.
• چندین رفع در یک hotfix — هر رفع باید در یک شاخه hotfix جداگانه باشد. مخلوط کردن چند باگ در یک شاخه بررسی کد را دشوار می‌کند، ریسک بازگشت را افزایش می‌دهد و برگشت در صورت نیاز را مشکل می‌سازد.
• عدم ادغام با develop — اگر hotfix با develop ادغام نشود، رفع در انتشار بعدی از بین می‌رود. تیم کشف می‌کند که همان باگ دوباره ظاهر شده و مجبور به رفع مجدد آن می‌شود.
• برچسب نسخه نادرست — hotfix باید افزایش پچ دریافت کند (v2.3.0 → v2.3.1)، نه minor (v2.4.0) یا major (v3.0.0). نقض نسخه‌بندی معنایی سیستم ساخت را مختل کرده و کاربران را سردرگم می‌کند.
• فقدان بررسی‌های CI — حتی hotfix اضطراری باید از تست‌های خودکار عبور کند. عدم انجام CI ریسک ورود خطای جدید را افزایش می‌دهد. توصیه می‌شود برای شاخه‌های hotfix یک pipeline جداگانه با بررسی‌های سریع‌تر داشته باشید.

هر یک از این اشتباهات منجر به تأخیر در انتشار پچ یا ظهور مشکلات جدید در تولید می‌شود. تیم‌ها باید قوانین کار با hotfix را در CONTRIBUTING.md ثبت کرده و آنها را از طریق بررسی‌های CI/CD خودکار کنند.