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 تین منظرناموں میں ضروری ہے: ایک سنگین بگ صارفین کو بلاک کرتا ہے (کریش، ڈیٹا کا نقصان)، ایک سیکیورٹی کمزوری کو فوری بندش کی ضرورت ہے، یا اہم کاروباری منطق ٹوٹ گئی ہے (ادائیگیاں، تصدیق)۔ اگر بگ سنگین نہیں ہے تو اسے 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 کے لیے علیحدہ برانچ قسم استعمال نہیں کرتا۔ اس کے بجائے، ڈویلپر main سے ایک عام feature برانچ بناتا ہے، اصلاح کرتا ہے اور Pull Request کھولتا ہے۔ جائزے اور CI چیک کے بعد، برانچ main میں ضم ہو جاتی ہے اور فوری طور پر تعینات ہو جاتی ہے۔ فائدہ سادگی ہے، نقصان ہنگامی اصلاحات کے لیے مخصوص چینل کی کمی ہے۔

Trunk-based ڈویلپمنٹ hotfix کو (سنگین صورتوں کے لیے) براہ راست 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 میں کم سے کم تبدیلیاں ہونی چاہئیں۔ کوڈ کو ری فیکٹر نہ کریں یا نئی خصوصیات شامل نہ کریں — صرف ہدفی اصلاح جو مسئلہ حل کرتی ہے۔

اصلاح کو کمٹ کرنا

Hotfix میں کمٹ میں ایک معلوماتی پیغام ہونا چاہیے جو مسئلہ اور اس کے حل کو واضح طور پر بیان کرتا ہو۔ فارمیٹ: قسم(علاقہ): مختصر وضاحت + tracker میں کام کا لنک۔

# تبدیل شدہ فائلیں شامل کریں
git add src/ui/login/LoginActivity.kt

# وضاحت کے ساتھ کمٹ بنائیں
git commit -m "fix(login): handle null intent on activity resume

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

کمٹ پیغام میں مسئلے کی وضاحت اور کام کا لنک شامل ہونا چاہیے۔ اس سے تاریخ میں تلاش آسان ہو جاتی ہے اور ساتھیوں کو یہ سمجھنے میں مدد ملتی ہے کہ کیا اور کیوں ٹھیک کیا گیا۔ موبائل پروجیکٹس کے لیے، اس ایپلیکیشن ورژن کو بھی شامل کرنا عام ہے جس میں بگ پایا گیا تھا۔

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 پرچم اس بات کو یقینی بناتا ہے کہ ضم کرنے والا کمٹ بنایا جائے، چاہے hotfix کو fast-forward کے ذریعے لاگو کیا جا سکتا ہو۔ یہ معلومات محفوظ رکھتا ہے کہ ایک ہنگامی اصلاح کی گئی تھی اور مستقبل میں تاریخ کے تجزیہ کو آسان بناتا ہے۔

Hotfix، Feature اور Release برانچوں میں فرق

Hotfix مقصد، دورانیہ اور ضم کرنے کے قوانین کے لحاظ سے feature اور release برانچوں سے بنیادی طور پر مختلف ہے۔ ان فرقوں کو سمجھنا ٹیم میں Git کے عمل کو صحیح طریقے سے منظم کرنے کے لیے بہت ضروری ہے۔

Feature برانچ نئی فعالیت کے لیے ہوتی ہے۔ یہ کئی دنوں سے کئی ہفتوں تک چلتی ہے، develop سے بنائی جاتی ہے اور develop میں واپس ضم ہوتی ہے۔ Feature میں متعدد کمٹ شامل ہو سکتے ہیں، بشمول تجرباتی، جو بعد میں squash یا rebase کے ذریعے کمپریس کیے جاتے ہیں۔

Release برانچ ریلیز کو تعیناتی کے لیے تیار کرتی ہے۔ یہ develop سے بنائی جاتی ہے، اس میں استحکام کے دوران پائے جانے والے بگز کو ٹھیک کیا جاتا ہے، اور یہ نئی فعالیت قبول نہیں کرتی۔ مکمل ہونے پر، release main (ٹیگ کے ساتھ) اور develop میں ضم ہوتی ہے۔

Hotfix دوسری طرف، براہ راست main کے ساتھ بنایا اور ضم کیا جاتا ہے، develop کو نظرانداز کرتے ہوئے (اگرچہ اصلاح کے بعد develop کے ساتھ بھی ہم آہنگ کیا جاتا ہے)۔ اس میں کم سے کم تبدیلیاں ہوتی ہیں اور کم سے کم وقت کے لیے موجود رہتا ہے۔ جہاں feature یا release برانچوں کو اگلے چکر تک ملتوی کیا جا سکتا ہے، hotfix کو ملتوی نہیں کیا جا سکتا۔

موبائل ڈویلپمنٹ کے لیے، یہ فرق خاص طور پر اہم ہے: App Store اور Google Play مرکزی ریلیز سے علیحدہ پیچ ورژن جاری کرنے کی اجازت دیتے ہیں۔ Hotfix برانچ اس بات کو یقینی بناتی ہے کہ پیچ ریلیز نامکمل خصوصیات کے ساتھ مخلوط نہ ہو۔

Hotfix کے ساتھ کام کرتے وقت عام غلطیاں

Hotfix کے ساتھ کام کرتے وقت غلطیاں ہنگامی اصلاح کے فوائد کو ختم کر سکتی ہیں۔ آئیے پانچ سب سے عام مسائل پر نظر ڈالتے ہیں جو Git Flow استعمال کرنے والی ٹیموں میں پیدا ہوتے ہیں۔

• develop سے hotfix بنانا — اگر hotfix develop سے بنایا جاتا ہے، تو نامکمل خصوصیات پیچ میں آ سکتی ہیں۔ Hotfix صرف main سے بنایا جانا چاہیے تاکہ یقینی بنایا جا سکے کہ اصلاح میں صرف مستحکم کوڈ شامل ہے۔
• ایک hotfix میں متعدد اصلاحات — ہر اصلاح اپنی علیحدہ hotfix برانچ میں ہونی چاہیے۔ ایک برانچ میں متعدد بگز کو ملانا کوڈ کے جائزے کو پیچیدہ بناتا ہے، رجعت کا خطرہ بڑھاتا ہے، اور ضرورت پڑنے پر واپس لینا مشکل بناتا ہے۔
• develop میں ضم کرنا چھوڑنا — اگر hotfix develop میں ضم نہیں کیا جاتا، تو اصلاح اگلی ریلیز میں ضائع ہو جائے گی۔ ٹیم دیکھے گی کہ وہی بگ دوبارہ ظاہر ہوا ہے اور اسے دوبارہ ٹھیک کرنا پڑے گا۔
• غلط ورژن ٹیگ — hotfix کو پیچ اضافہ ملنا چاہیے (v2.3.0 → v2.3.1)، معمولی (v2.4.0) یا اہم (v3.0.0) اضافہ نہیں۔ معنوی ورژننگ کی خلاف ورزی بلڈ سسٹم کو توڑ دیتی ہے اور صارفین کو الجھن میں ڈال دیتی ہے۔
• CI چیک کی کمی — ہنگامی hotfix کو بھی خودکار ٹیسٹ پاس کرنے چاہئیں۔ CI چھوڑنے سے نئی خرابی متعارف کرانے کا خطرہ بڑھ جاتا ہے۔ تیز رفتار چیک کے ساتھ hotfix برانچوں کے لیے علیحدہ pipeline رکھنے کی سفارش کی جاتی ہے۔

ان میں سے ہر غلطی پیچ ریلیز میں تاخیر یا پروڈکشن میں نئے مسائل کی وجہ بنتی ہے۔ ٹیموں کو CONTRIBUTING.md میں hotfix کے ساتھ کام کرنے کے قواعد دستاویز کرنے چاہئیں اور انہیں CI/CD چیک کے ذریعے خودکار کرنا چاہیے۔