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. فقط إصلاح موجه، بأقل قدر ضروري لحل المشكلة الحرجة. أي انحراف عن هذه القاعدة يزيد من خطر الانحدار (regression) ويؤخر إصدار التصحيح.

متى نحتاج 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. بدلاً من ذلك، ينشئ المطور فرع feature عادي من main، ويجري الإصلاح، ويفتح 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 على أقل عدد ممكن من التغييرات. لا تقم بإعادة هيكلة الكود أو إضافة ميزات جديدة — فقط الإصلاح الموجه الذي يحل المشكلة.

تسجيل الإصلاح

الالتزام (commit) في hotfix يجب أن يكون له رسالة إعلامية تصف بوضوح المشكلة وحلها. التنسيق: النوع(النطاق): وصف مختصر + رابط للمهمة في tracker.

# إضافة الملفات المعدلة
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"

يجب أن تحتوي رسالة الالتزام على وصف المشكلة ورابط للمهمة. هذا يبسط البحث في التاريخ ويساعد الزملاء على فهم ما تم إصلاحه ولماذا. لمشاريع الجوال، من المعتاد أيضًا تضمين إصدار التطبيق الذي تم العثور فيه على الخطأ.

الدمج في 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 على التزامات متعددة، بما في ذلك الالتزامات التجريبية، التي يتم ضغطها لاحقًا من خلال 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)، وليس زيادة ثانوية (v2.4.0) أو رئيسية (v3.0.0). انتهاك الإصدار الدلالي يعطل نظام البناء ويسبب ارتباكًا للمستخدمين.
• غياب فحوصات CI — حتى hotfix العاجل يجب أن يجتاز الاختبارات الآلية. تخطي CI يزيد من خطر إدخال خطأ جديد. يُوصى بوجود pipeline منفصل لفروع hotfix مع فحوصات مسرعة.

كل واحد من هذه الأخطاء يؤدي إلى تأخير إصدار التصحيح أو ظهور مشاكل جديدة في الإنتاج. يجب على الفرق توثيق قواعد العمل مع hotfix في CONTRIBUTING.md وأتمتتها من خلال فحوصات CI/CD.