Release Branch في Git — ما هو، الغرض منه وسير العمل

ما هو Release Branch في Git

Release Branch (فرع الإصدار) هو فرع مؤقت في Git Flow، يتم إنشاؤه من develop عندما يقرر الفريق أن المجموعة الحالية من الميزات جاهزة للإصدار. إنه موجود تمامًا للمدة التي يستغرقها التحضير النهائي للإصدار — من بضع ساعات إلى بضعة أيام.

الغرض الرئيسي من فرع الإصدار هو تجميد مجموعة محددة من الميزات للإصدار دون إيقاف تطوير الإصدارات التالية. بينما يتم تحضير فرع الإصدار للنشر، يمكن للمطورين الآخرين الاستمرار في دمج فروع الميزات في develop للإصدار التالي.

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

وفقًا Atlassian، 2024، فإن فروع الإصدار ضرورية جدًا للمشاريع ذات دورات الإصدار المنتظمة — فهي تضمن قابلية التوقع والاستقرار في عملية النشر.

دورة حياة فرع الإصدار

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

1. الإنشاء — من آخر commit في develop يتم إنشاء فرع باسم release/2.5.0. يستمر develop في قبول فروع الميزات للإصدار التالي.
2. التحضير — في فرع الإصدار يتم تحديث نسخة التطبيق في build.gradle و Info.plist وملفات التكوين الأخرى.
3. إصلاح الأخطاء — يتم إصلاح الأخطاء الحرجة التي تم العثور عليها أثناء الاختبارات النهائية. فقط الأخطاء — لا ميزات جديدة.
4. الاختبار النهائي — يقوم فريق QA باختبارات الانحدار على فرع الإصدار. تُرسل الأخطاء الجديدة للإصلاح في نفس الفرع.
5. الدمج في main — يتم دمج فرع الإصدار في main مع العلم --no-ff. يتم إنشاء علامة الإصدار: v2.5.0.
6. الدمج في develop — يتم دمج فرع الإصدار عائدًا إلى develop لتصل إصلاحات الإصدار إلى التطوير الحالي.
7. الحذف — يتم حذف فرع الإصدار محليًا وعن بُعد، حيث اكتملت مهمته.

الخطوة 6 — الدمج العكسي في develop — غالبًا ما تُنسى، لكنها ضرورية جدًا. بدونها، لن تصل إصلاحات الأخطاء التي تمت في فرع الإصدار إلى develop، وقد تظهر نفس الأخطاء مرة أخرى في الإصدار التالي.

المدد النموذجية لمراحل فرع الإصدار

يعتمد عمر فرع الإصدار على تعقيد الإصدار وجودة الكود في develop. في المتوسط، يستغرق التحضير من 2 إلى 5 أيام عمل لتطبيق محمول متوسط الحجم.

ما يتم عمله في فرع الإصدار

في فرع الإصدار يتم تنفيذ مجموعة محدودة بدقة من المهام. أي انحراف عن هذه القائمة ينتهك نموذج Git Flow ويخلق مخاطر لاستقرار الإصدار.

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

تحديث النسخة في مشروع محمول

في فرع الإصدار يتم تحديث رقم نسخة التطبيق إلزاميًا. لنظام Android، هذه هي الحقول versionCode و versionName في build.gradle؛ لنظام iOS — CFBundleShortVersionString في Info.plist.

// build.gradle (مستوى التطبيق) — تحديث النسخة في فرع release
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// لنظام iOS — تحديث Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

الاختلافات بين release و hotfix

غالبًا ما يخلط المطورون المبتدئون بين فرعي release و hotfix، على الرغم من أن الغرض منهما مختلف جوهريًا. اختيار نوع الفرع الخاطئ يمكن أن يؤخر الإصلاح الحرج أو يعطل عملية الإصدار.

• المصدر — يتم إنشاء release من develop، و hotfix من main. هذا هو الفرق الرئيسي الذي يحدد كل شيء آخر.
• الاستعجال — release مخطط له: الفريق يقرر متى يبدأ التحضير. Hotfix عاجل: مشكلة في الإنتاج تتطلب إصلاحًا فوريًا.
• المحتوى — release قد يتضمن عدة إصلاحات وتحديث نسخة. Hotfix يحتوي على إصلاح حرج واحد فقط.
• الدمج — يتم دمج release في main و develop. يتم دمج hotfix أيضًا في main و develop، لكن بشكل عاجل.
• العمر — يعيش release من 1 إلى 7 أيام. يعيش hotfix من 30 دقيقة إلى يوم واحد.

إذا تم العثور على خطأ أثناء تحضير الإصدار (في فرع release) — فهو إصلاح خطأ عادي. إذا تم العثور على خطأ في الإنتاج (على main) — فهو hotfix، ويتم إنشاؤه من main، حتى لو كان فرع release موجودًا بالفعل.

قواعد تسمية فروع الإصدار

معيار موحد لتسمية فروع الإصدار يبسط التنقل في المستودع ويسمح لأنظمة CI/CD بتحديد تلقائيًا أن الفرع ينتمي إلى عملية الإصدار.

• release/X.Y.Z — تنسيق Git Flow القياسي، حيث X.Y.Z هو نسخة الإصدار. مثال: release/2.5.0.
• release/الاسم — تنسيق بديل باسم رمزي للإصدار. مثال: release/merlin.
• release/التاريخ — تنسيق مع تاريخ الإصدار. يُستخدم نادرًا، لأن النسخة أهم من التاريخ. مثال: release/2024-12-01.

التنسيق release/X.Y.Z هو المفضل، لأنه يربط الفرع بشكل صريح برقم النسخة الذي سيتم تعيينه للإصدار. هذا يبسط البحث والمعالجة التلقائية بواسطة نصوص CI/CD.

استراتيجية الدمج العكسي في develop

الدمج العكسي (merge back) لفرع الإصدار في develop هو واحد من أهم العمليات وفي نفس الوقت أكثرها تجاهلاً. بدونه، تبقى جميع إصلاحات الأخطاء التي تمت في فرع الإصدار فقط في نسخة الإصدار ولا تصل إلى دورة الإصدار التالية.

يتم تنفيذ عملية الدمج العكسي بعد أن تم دمج فرع الإصدار بالفعل في main. أولاً، يتم دمج release في develop، ثم يتم حذفه. هذا يضمن أن develop يحتوي على جميع الإصلاحات التي تمت أثناء تحضير الإصدار.

بعد الدمج العكسي، قد تحدث تعارضات — خاصة إذا ظهرت بالفعل فروع ميزات جديدة في develop كانت قد عدلت نفس الملفات. المطور المسؤول عن الإصدار يحل هذه التعارضات ويدفع develop إلى الخادم.

بعض الفرق تستخدم rebase بدلاً من merge للدمج العكسي للحفاظ على تاريخ خطي. ومع ذلك، فإن merge أكثر أمانًا لـ develop، لأنه لا يعيد كتابة تاريخ commits الذي قد يكون مستخدمًا بالفعل من قبل مطورين آخرين.

أمثلة على أوامر العمل مع release

دعنا نستعرض الدورة الكاملة للعمل مع فرع release: من الإنشاء إلى الحذف بعد إصدار ناجح لتطبيق محمول نسخة 2.5.0.

# 1. إنشاء فرع release من develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. تحديث النسخة وإصلاح الأخطاء
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. إصلاح الأخطاء (إصلاحات فقط)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. إرسال فرع release إلى الخادم
git push origin release/2.5.0

# 5. دمج release في main
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. الدمج العكسي في develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. حذف فرع release
git branch -d release/2.5.0
git push origin --delete release/2.5.0

الأمران 5 و 6 — الدمج المزدوج — ضروريان جدًا. أولاً، يتلقى main كود الإصدار والعلامة، ثم يتزامن develop مع إصلاحات release. إذا تم تخطي الخطوة 6، فإن إصلاحات الإصدار لن تصل إلى دورة التطوير التالية.

أتمتة عملية الإصدار

للمشاريع المحمولة ذات الإصدارات المنتظمة، يمكن أتمتة عملية إنشاء فرع release وتحديث النسخة عبر نصوص CI/CD. يتيح GitHub Actions إنشاء سير عمل يؤدي عند الضغط على زر إلى إنشاء فرع release مع تحديث تلقائي للنسخة.

للمشاريع المحمولة ذات الإصدارات المنتظمة، يمكن أتمتة عملية إنشاء فرع release وتحديث النسخة عبر نصوص CI/CD. يتيح GitHub Actions إنشاء سير عمل يؤدي عند الضغط على زر إلى إنشاء فرع release مع تحديث تلقائي للنسخة.

# GitHub Actions — أتمتة إنشاء فرع release
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}