Git و GitHub
التطوير القائم على الجذع
التطوير القائم على الجذع
التطوير القائم على الجذع (Trunk-Based Development - TBD) هو سير عمل للتحكم في الإصدارات حيث يتعاون المطورون على الكود في فرع واحد يسمى "الجذع" (trunk) أو "الرئيسي" (main)، مع مقاومة الرغبة في إنشاء فروع ميزات طويلة العمر. يعزز هذا النهج التكامل المستمر ويتيح النشر السريع.
ما هو التطوير القائم على الجذع؟
في التطوير القائم على الجذع، يعمل جميع المطورين على الفرع الرئيسي (الجذع) ويقومون بالتزام تغييراتهم بشكل متكرر. فروع الميزات، إذا تم استخدامها على الإطلاق، تكون قصيرة العمر (عادة أقل من 24 ساعة) وتُدمج مرة أخرى في الجذع بسرعة.
المبدأ الأساسي: يؤكد التطوير القائم على الجذع على "التكامل المبكر، التكامل المتكرر" لتقليل تعارضات الدمج وتمكين التسليم المستمر.
الخصائص الأساسية
1. فرع رئيسي واحد:
- يتم دمج جميع الأكواد في trunk/main
- الجذع دائماً في حالة قابلة للإصدار
- لا توجد فروع ميزات طويلة العمر
2. فروع ميزات قصيرة العمر:
- الفروع تعيش لساعات، وليس أيام/أسابيع
- تُنشأ لمهام محددة
- تُدمج بسرعة عبر طلبات السحب
3. التزامات متكررة:
- يلتزم المطورون عدة مرات في اليوم
- تغييرات صغيرة ومتزايدة
- تكامل مستمر مع الجذع
4. أعلام الميزات:
- الميزات غير المكتملة مخفية خلف الأعلام
- تسمح بدمج الكود غير المكتمل بأمان
- تمكين/تعطيل الميزات في وقت التشغيل
سير عمل التطوير القائم على الجذع
إليك كيفية عمل المطورين في TBD:
# 1. سحب أحدث التغييرات من الجذع
git checkout main
git pull origin main
# 2. إنشاء فرع ميزة قصير العمر
git checkout -b feature/add-login-validation
# 3. إجراء تغييرات صغيرة ومركزة
# تحرير الملفات...
git add .
git commit -m "Add email validation to login form"
# 4. دفع وإنشاء طلب سحب (في غضون ساعات)
git push origin feature/add-login-validation
# 5. بعد المراجعة، الدمج في main وحذف الفرع
# عبر واجهة GitHub أو:
git checkout main
git merge feature/add-login-validation
git branch -d feature/add-login-validation
git push origin --delete feature/add-login-validation
# 6. سحب التغييرات المدمجة
git pull origin main
أفضل ممارسة: يجب دمج فروع الميزات في غضون يوم عمل واحد. إذا عاش فرعك لفترة أطول، فأنت لا تمارس التطوير القائم على الجذع الحقيقي.
أعلام الميزات للعمل غير المكتمل
تسمح أعلام الميزات بدمج الكود غير المكتمل في الجذع دون عرضه للمستخدمين:
مثال: علم ميزة PHP
// config/features.php
return [
'new_dashboard' => env('FEATURE_NEW_DASHBOARD', false),
'ai_recommendations' => env('FEATURE_AI_RECS', false),
];
// في الكود الخاص بك
if (config('features.new_dashboard')) {
return view('dashboard.new');
} else {
return view('dashboard.legacy');
}
// ملف .env
FEATURE_NEW_DASHBOARD=false # مخفي في الإنتاج
FEATURE_AI_RECS=true # مُفعل في الإنتاج
الفائدة: تفصل أعلام الميزات بين النشر وإصدار الميزة. انشر الكود في أي وقت، أطلق الميزات عندما تكون جاهزة.
فروع الإصدار في TBD
بينما فروع الميزات قصيرة العمر، تُستخدم فروع الإصدار لإصدارات الإنتاج:
استراتيجية فرع الإصدار:
# إنشاء فرع الإصدار من main
git checkout main
git checkout -b release/v2.1.0
# إصلاحات الأخطاء لهذا الإصدار تذهب هنا
git commit -m "Fix critical login bug for v2.1.0"
# وضع علامة على الإصدار
git tag -a v2.1.0 -m "Release version 2.1.0"
git push origin release/v2.1.0
git push origin v2.1.0
# اختيار انتقائي لإصلاحات الأخطاء إلى main
git checkout main
git cherry-pick <commit-hash>
# يبقى فرع الإصدار للإصلاحات العاجلة
مزايا التطوير القائم على الجذع
✓ تقليل تعارضات الدمج:
- التكامل المتكرر يعني اختلافات أصغر
- يتم اكتشاف التعارضات وحلها مبكراً
✓ ردود فعل أسرع:
- يتم مراجعة واختبار التغييرات بسرعة
- يتم اكتشاف المشكلات في غضون ساعات، وليس أسابيع
✓ التكامل المستمر:
- تعمل الاختبارات التلقائية على كل التزام
- يتم إصلاح البناءات المعطلة فوراً
✓ سير عمل مبسط:
- لا توجد استراتيجيات تفريع معقدة
- أسهل لأعضاء الفريق الجدد
✓ يتيح النشر المستمر:
- الفرع الرئيسي قابل للنشر دائماً
- الإصدار في أي وقت بثقة
✓ جودة كود أفضل:
- المراجعات المتكررة تلتقط المشكلات مبكراً
- التغييرات الأصغر أسهل للمراجعة
التحديات والحلول
التحدي: التغييرات المدمرة
الحل: استخدام أعلام الميزات والتوافق العكسي
التحدي: الميزات غير المكتملة
الحل: الإخفاء خلف أعلام الميزات، استخدام التجريدات
التحدي: يتطلب انضباط الفريق
الحل: أتمتة الفحوصات، الفرض من خلال CI/CD
التحدي: يتطلب CI/CD قوي
الحل: الاستثمار في الاختبار والنشر التلقائي
التحدي: سرعة مراجعة الكود
الحل: إبقاء PRs صغيرة، إعطاء الأولوية للمراجعات، أتمتة الفحوصات
مهم: يتطلب التطوير القائم على الجذع اختبارات آلية ممتازة. بدون اختبارات شاملة، يصبح التكامل المتكرر محفوفاً بالمخاطر.
متطلبات CI/CD لـ TBD
يعتمد التطوير القائم على الجذع الناجح على الأتمتة القوية:
الفحوصات التلقائية الأساسية:
1. الاختبارات التلقائية:
- اختبارات الوحدة (تعمل في ثوان)
- اختبارات التكامل (تعمل في دقائق)
- تغطية كود بحد أدنى 80%
2. التدقيق والتنسيق:
- فحوصات نمط الكود
- التحليل الثابت
- مسح الأمان
3. التحقق من البناء:
- فحوصات التجميع
- التحقق من التبعيات
- بناء الأصول
4. خط أنابيب النشر:
- نشر التجريب
- اختبارات الدخان
- نشر الإنتاج
مثال: GitHub Actions لـ TBD
# .github/workflows/trunk.yml
name: Trunk Integration
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run tests
run: |
composer install
php artisan test
- name: Code quality
run: |
./vendor/bin/phpstan analyse
./vendor/bin/php-cs-fixer fix --dry-run
- name: Security scan
run: composer audit
deploy:
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- name: Deploy to staging
run: ./deploy-staging.sh
متى تستخدم التطوير القائم على الجذع
✓ جيد لـ:
- الفرق التي تمارس التكامل المستمر
- المشاريع ذات الاختبار التلقائي القوي
- منتجات SaaS مع النشر المستمر
- ممارسات DevOps الناضجة
- الفرق ذات الثقة العالية والخبرة
✗ ليس مثالياً لـ:
- الفرق بدون اختبار تلقائي
- المشاريع ذات الإصدارات النادرة
- المصادر المفتوحة مع العديد من المساهمين الخارجيين
- قواعد الكود القديمة بدون CI/CD
- الفرق الجديدة على سير عمل Git
نصيحة: ابدأ بـ GitHub Flow إذا كنت جديداً على سير عمل Git التعاوني. انتقل إلى التطوير القائم على الجذع عندما يكون لدى فريقك ممارسات CI/CD ناضجة.
TBD مقابل سير العمل الأخرى
Git Flow:
- فروع متعددة طويلة العمر (develop, feature, release, hotfix)
- المزيد من الاحتفالات والعمليات
- أفضل للإصدارات المجدولة
GitHub Flow:
- فروع الميزات + main
- أرضية وسط بين Git Flow و TBD
- جيد للنشر المستمر
التطوير القائم على الجذع:
- الحد الأدنى من التفريع (أو بدون فروع)
- أقصى تكرار للتكامل
- الأفضل لفرق DevOps النخبة
أفضل الممارسات لـ TBD
1. الالتزام بشكل متكرر: مرة واحدة على الأقل يومياً للجذع
2. إبقاء PRs صغيرة: أقل من 400 سطر من الكود
3. المراجعة السريعة: مراجعة PRs في غضون 1-2 ساعة
4. إصلاح الفشل فوراً: البناءات المعطلة هي الأولوية القصوى
5. استخدام أعلام الميزات: للميزات غير المكتملة
6. أتمتة كل شيء: الاختبارات، النشر، التراجع
7. البرمجة الزوجية: تقلل الحاجة للمراجعات الرسمية
8. التفريع بالتجريد: لإعادة الهيكلة الكبيرة
تمرين عملي:
السيناريو: يريد فريقك اعتماد التطوير القائم على الجذع. تحتاج إلى تنفيذ ميزة جديدة (صفحة ملف المستخدم) ستستغرق 3 أيام لإكمالها، ولكنك تريد الالتزام بالجذع يومياً.
المهمة:
- تصميم نظام علم ميزة لميزة ملف المستخدم
- تقسيم العمل إلى أجزاء قابلة للدمج يومياً
- كتابة رسائل التزام لعمل كل يوم
الحل:
اليوم 1: واجهة برمجة التطبيقات الخلفية
git checkout -b feature/profile-api
# بناء نقطة نهاية بيانات الملف الشخصي (مخفية خلف العلم)
git commit -m "Add user profile API endpoint (behind feature flag)"
# الدمج في main - واجهة برمجة التطبيقات موجودة ولكن غير معروضة للواجهة الأمامية
اليوم 2: هيكل الواجهة الأمامية
git checkout -b feature/profile-ui
# بناء مكونات واجهة المستخدم للملف الشخصي (مخفية خلف العلم)
git commit -m "Add profile page UI components (feature flagged)"
# الدمج في main - واجهة المستخدم موجودة ولكن المسار ليس عاماً
اليوم 3: التكامل والصقل
git checkout -b feature/profile-integration
# ربط الواجهة الأمامية بالخلفية، التنسيق، الاختبارات
git commit -m "Integrate profile page and add tests"
# الدمج في main - مكتملة ولكن لا تزال خلف العلم
# تفعيل العلم عند الاستعداد: FEATURE_USER_PROFILE=true
الملخص
في هذا الدرس، تعلمت:
- يستخدم التطوير القائم على الجذع فرعاً رئيسياً واحداً للتعاون
- فروع الميزات قصيرة العمر (أقل من 24 ساعة)
- أعلام الميزات تمكن دمج الكود غير المكتمل بأمان
- الأتمتة القوية لـ CI/CD ضرورية لنجاح TBD
- TBD يقلل من تعارضات الدمج ويتيح النشر المستمر
- الأنسب للفرق الناضجة مع ممارسات اختبار ممتازة
التالي: في الدرس التالي، سنستكشف أفضل ممارسات مراجعة الكود لضمان الجودة في التطوير التعاوني!