Develop Branch في Git — ما هو، الغرض منه ومبادئ العمل

ما هو Develop Branch في Git

Develop Branch (branch التطوير) هي branch طويلة العمر في Git Flow تعمل كمركز رئيسي لتكامل الكود من جميع المطورين. يتم دمج feature branches فيها بعد اكتمال التطوير ومراجعة الكود.

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

على عكس main، حيث كل إصدار كود هو release، يحتوي develop على تدفق مستمر من التغييرات. تظهر commits في develop عند دمج feature branches، وهو ما يمكن أن يحدث عدة مرات في اليوم.

وفقًا لـ Vincent Driessen، 2010، يعتبر develop عنصرًا أساسيًا في نموذج branching ناجح، حيث يفصل العمل المسود عن الإصدارات الجاهزة للنشر.

الاختلافات بين develop و main branch

فهم الاختلافات بين develop و main أمر بالغ الأهمية لسير عمل Git Flow الصحيح. تؤدي هذه الفروع وظائف مختلفة ولها متطلبات استقرار مختلفة.

يتيح التقسيم إلى develop و main للفريق دمج الكود الجديد باستمرار دون المخاطرة باستقرار إصدار الإنتاج. يمكن للمطورين رؤية الكود الخاص بهم في develop فور الموافقة على PR، حتى قبل الإصدار الرسمي.

دور develop في Git Flow

في نموذج Git Flow، يحتل develop مكانًا مركزيًا بين feature branches (مصدر التغييرات) و release branches (التحضير للإصدار). فهم هذا التسلسل الهرمي هو أساس التفرع الفعال.

• Feature → Develop — يتم دمج كل وظيفة مكتملة في develop عبر Pull Request مع مراجعة الكود.
• Develop → Release — عندما تتراكم تغييرات كافية للإصدار، يتم إنشاء release branch من develop.
• Release → Main + Develop — بعد التحضير النهائي، يتم دمج release branch في main (إصدار) وإعادتها إلى develop (إصلاحات الأخطاء).
• Hotfix → Main + Develop — يتم إنشاء الإصلاحات الحرجة من main ودمجها في كلا الفرعين.

يضمن هذا الهيكل أن develop يحتوي دائمًا على أحدث الكود مع جميع الوظائف الجديدة، بينما يحتوي main على كود إنتاج معتمد فقط. هذا مهم بشكل خاص لمشاريع التطبيقات مع دورات مراجعة طويلة في App Store و Google Play.

علاقة develop مع فروع Git Flow الأخرى

يعمل develop كحلقة وصل مركزية بين feature و release و hotfix branches. فهم اتجاهات الدمج ضروري لمنع التعارضات وفقدان الـ commits.

متطلبات جودة الكود في develop

جودة الكود في develop يجب أن تكون عالية، ولكن ليست مطلقة. على عكس main، حيث كل خطأ يعني hotfix عاجل، يسمح develop بعيوب طفيفة سيتم إصلاحها قبل الإصدار.

الحد الأدنى من المتطلبات للكود قبل الدمج في develop:

• التجميع — يجب أن يتم تجميع الكود بدون أخطاء. build مكسور في develop يعيق عمل الفريق بأكمله.
• اختبارات الوحدة — يجب أن تجتاز جميع الاختبارات الحالية. يجب أن يكون الكود الجديد مغطى بالاختبارات بنسبة 70% على الأقل.
• نمط الكود — يجب أن يتوافق الكود مع معايير التنسيق والتسمية المقبولة في الفريق.
• لا لـ API القديم — لا يُسمح باستخدام الطرق القديمة في الكود الجديد.

يجب تشغيل الفحوصات الآلية في خط أنابيب CI/CD عند كل push إلى develop. إذا انكسر الـ build، يجب على المطور المسؤول إصلاح المشكلة في غضون ساعة أو التراجع عن commit الخاص به.

فحوصات CI/CD لـ develop

إعداد GitHub Actions لـ develop يضمن أن كل PR يمر بفحوصات آلية قبل الدمج. يشمل خط الأنابيب النموذجي البناء والاختبارات والـ linting.

# GitHub Actions — التحقق من develop بعد الدمج
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

قواعد الدمج في develop

الدمج في develop يجب أن يتبع قواعد صارمة للحفاظ على استقرار branch التكامل. انتهاك هذه القواعد يؤدي إلى تعارضات و builds مكسورة وإضاعة وقت الفريق.

• فقط عبر Pull Request — الدفع المباشر إلى develop محظور. جميع التغييرات تخضع لمراجعة الكود.
• موافقة واحدة على الأقل — يجب أن يحصل PR على موافقة مطور واحد على الأقل غير مشارك في المهمة.
• Squash merge — يوصى بدمج جميع commits feature branch في commit واحد عند الدمج في develop للحصول على تاريخ نظيف.
• تحديث PR — قبل الدمج، يجب تحديث PR بالنسبة لآخر commit في develop (rebase أو merge).

قاعدة تحديث PR مهمة بشكل خاص. إذا تم إنشاء feature branch منذ أسبوع وتقدم develop بمقدار 50 commit، قد يؤدي الدمج المباشر إلى تعارضات يفضل حلها في سياق PR بدلاً من develop.

حماية develop من عمليات الدمج غير الصحيحة

قواعد حماية branch هي إعدادات على مستوى GitHub أو GitLab أو Bitbucket تمنع التغييرات غير الصحيحة في develop. تضمن أنه حتى الدفع العرضي لا يكسر branch التكامل.

قواعد الحماية الموصى بها لـ develop:

• اشتراط pull request — منع الدفع المباشر إلى develop. جميع التغييرات فقط عبر PR.
• اشتراط الموافقات — 1-2 موافقة على الأقل قبل دمج PR.
• اشتراط فحوصات الحالة — حظر الدمج إذا لم ينجح خط أنابيب CI/CD.
• اشتراط التحديث — يجب تحديث branch PR بالنسبة إلى develop قبل الدمج.
• تقييد وصول الدفع — تقييد حقوق الدفع إلى develop للمطورين الكبار فقط.

إعداد حماية develop يستغرق 10 دقائق ولكنه يمنع أسابيع من التوقف المتعلق بـ branch تكامل مكسور. بالنسبة لمشاريع التطبيقات مع فرق متعددة المنصات، هذا مهم بشكل خاص.

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

لنفكر في يوم نموذجي لمطور: في الصباح يقوم بتحديث develop، وينشئ feature branch جديدة، وبعد إكمال المهمة يدمج التغييرات مرة أخرى في develop.

# المزامنة الصباحية لـ develop
git checkout develop
git pull origin develop

# إنشاء feature branch جديدة من develop
git checkout -b feature/add-push-notifications

# العمل على الوظيفة...
git add . && git commit -m "Add FCM integration"

# تحديث develop أثناء التطوير
git fetch origin develop
git rebase origin/develop

# بعد الموافقة على PR — تحديث develop المحلي
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

أمر git pull في develop يقوم بعمليتين في وقت واحد: git fetch (يجلب commits جديدة من الخادم) و git merge (يدمجها مع الفرع المحلي). بالنسبة لـ develop، هذه هي طريقة المزامنة القياسية.

استعادة develop بعد دمج فاشل

إذا وصل كود كسر الـ build إلى develop، يجب التصرف بسرعة. كل ساعة توقف لـ develop تعني عمل محظور لفريق التطوير بأكمله.

إذا وصل كود كسر الـ build إلى develop، استخدم git revert لإنشاء commit جديد يلغي التغييرات الإشكالية. لا تستخدم git reset في develop — فهو يعيد كتابة التاريخ الذي يمتلكه أعضاء الفريق الآخرون بالفعل.

# العثور على commit الإشكالي
git log --oneline develop

# إلغاء commit عبر revert (آمن)
git revert a1b2c3d

# إرسال الإصلاح إلى develop البعيد
git push origin develop

# عرض التغييرات في commit معين
git show a1b2c3d --stat