Git و GitHub
GitHub Flow
GitHub Flow
GitHub Flow هو سير عمل خفيف الوزن قائم على الفروع مصمم للفرق والمشاريع التي تنشر بانتظام. إنه أبسط من Git Flow ويركز على التسليم المستمر، مما يجعله مثالياً لتطبيقات الويب ومنتجات SaaS.
ما هو GitHub Flow؟
GitHub Flow هو سير عمل مبسط أنشأته GitHub يركز على البساطة والنشر المستمر. يستخدم فرعاً واحداً طويل الأمد فقط (main) وفروع ميزات قصيرة الأجل.
الفلسفة: يستند GitHub Flow على مبدأ أن أي شيء في فرع main يكون دائماً قابلاً للنشر. هذه البساطة تمكّن التكرار السريع والتسليم المستمر.
عملية GitHub Flow
يتكون GitHub Flow من ست خطوات بسيطة:
الخطوة 1: إنشاء فرع
تفرع من main لأي عمل جديد
الخطوة 2: إضافة التزامات
قم بإجراء التغييرات والالتزام بانتظام برسائل واضحة
الخطوة 3: فتح طلب سحب
ابدأ مناقشة حول تغييراتك
الخطوة 4: مناقشة ومراجعة
يراجع الفريق ويناقش الكود
الخطوة 5: نشر واختبار
انشر إلى الاختبار/الإنتاج للاختبار (اختياري)
الخطوة 6: دمج إلى Main
بعد الموافقة، ادمج وانشر إلى الإنتاج
تصور GitHub Flow
سير العمل مباشر:
main o---o---o---o---o---o
\ / \
feature o-----o o---o
\ \
another-feature o---o
الخطوة 1: إنشاء فرع
قم دائماً بالتفرع من main للعمل الجديد:
# تحديث main إلى أحدث إصدار
git checkout main
git pull origin main
# إنشاء فرع وصفي
git checkout -b add-user-profile
# أو في أمر واحد:
git checkout -b add-user-profile origin/main
# دفع الفرع إلى البعيد على الفور
git push -u origin add-user-profile
تسمية الفرع: استخدم أسماء وصفية تشرح ما يفعله الفرع:
add-login-form، fix-navbar-bug، update-readme
الخطوة 2: إضافة التزامات
قم بإجراء التغييرات والالتزام بشكل متكرر:
# إجراء تغييرات على الملفات
# ...
# مرحلة والالتزام
git add .
git commit -m "Add user profile page structure"
# الاستمرار في العمل
# ...
git commit -m "Add profile image upload"
git commit -m "Add profile edit functionality"
# دفع الالتزامات إلى البعيد
git push origin add-user-profile
أفضل ممارسات الالتزام:
✓ الالتزام كثيراً بتغييرات مركزة
✓ اكتب رسائل التزام واضحة ووصفية
✓ ادفع الالتزامات بانتظام لنسخ عملك احتياطياً
✓ يجب أن يمثل كل التزام وحدة منطقية
✓ استخدم زمن الحاضر: "Add feature" وليس "Added feature"
الخطوة 3: فتح طلب سحب
أنشئ PR بمجرد أن يكون لديك شيء للمناقشة:
# على GitHub:
1. انتقل إلى مستودعك
2. انقر على "Pull requests" → "New pull request"
3. حدد فرعك للمقارنة مع main
4. أضف العنوان والوصف
5. انقر على "Create pull request"
# أو استخدم GitHub CLI:
gh pr create --title "Add user profile feature" \
--body "Implements user profile with image upload"
PRs مبكرة: لا تنتظر حتى يكتمل العمل! أنشئ PR مسودة مبكراً للحصول على التعليقات وإظهار التقدم. يمكنك تحويله إلى جاهز للمراجعة لاحقاً.
الخطوة 4: مناقشة ومراجعة
تعاون من خلال مراجعة الكود:
كمؤلف:
- رد على جميع التعليقات
- قم بإجراء التغييرات المطلوبة
- ادفع التزامات جديدة لتحديث PR
- اطلب إعادة المراجعة بعد التغييرات
- كن منفتحاً على التعليقات
كمراجع:
- راجع الكود بدقة
- اطرح أسئلة للتوضيح
- اقترح تحسينات
- وافق عندما تكون راضياً
- كن بناءً ومحترماً
إجراء تغييرات بناءً على المراجعة:
# معالجة تعليقات المراجعة
git checkout add-user-profile
# إجراء التغييرات
# ...
git commit -m "Address review feedback: improve validation"
git push origin add-user-profile
# يتم تحديث PR تلقائياً مع التزامات جديدة
الخطوة 5: نشر واختبار (اختياري)
تنشر العديد من الفرق الفرع إلى الاختبار قبل الدمج:
# نشر الفرع إلى بيئة الاختبار
git checkout add-user-profile
git push staging add-user-profile
# أو استخدم أدوات النشر
# النشر إلى بيئة المعاينة
# اختبار التغييرات مباشرة
# إذا وُجدت مشكلات، أصلح وادفع
git commit -m "Fix styling issue"
git push origin add-user-profile
عمليات نشر المعاينة: أدوات مثل Netlify و Vercel و Heroku يمكنها نشر فروع PR تلقائياً إلى عناوين URL للمعاينة للاختبار.
الخطوة 6: دمج إلى Main
بمجرد الموافقة والاختبار، ادمج إلى main:
# على GitHub (موصى به):
1. انقر على "Merge pull request"
2. اختر استراتيجية الدمج (squash، merge، rebase)
3. انقر على "Confirm merge"
4. احذف الفرع (GitHub يطالب تلقائياً)
# أو من سطر الأوامر:
git checkout main
git pull origin main
git merge add-user-profile
git push origin main
git branch -d add-user-profile
قواعد حماية الفرع
فرض أفضل ممارسات GitHub Flow:
# على GitHub: الإعدادات → الفروع → قواعد حماية الفرع
القواعد الموصى بها لـ Main:
✓ طلب طلب سحب قبل الدمج
✓ طلب الموافقات (مراجع واحد على الأقل 1-2)
✓ طلب فحوصات الحالة لتمر (اختبارات CI)
✓ طلب أن تكون الفروع محدثة قبل الدمج
✓ طلب حل المحادثة قبل الدمج
✓ عدم السماح بتجاوز هذه القواعد
قواعد اختيارية:
- طلب مراجعة مالك الكود
- طلب التزامات موقعة
- تقييد من يمكنه الدفع إلى main
حرج: لا تلتزم مباشرة بـ main أبداً. استخدم دائماً طلبات السحب، حتى للتغييرات الصغيرة. هذا يضمن مراجعة الكود ويحافظ على سلامة النشر.
النشر المستمر
أتمتة النشر عند الدمج إلى main:
# .github/workflows/deploy.yml
name: Deploy to Production
on:
push:
branches: [ main ]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: تثبيت التبعيات
run: npm ci
- name: تشغيل الاختبارات
run: npm test
- name: البناء
run: npm run build
- name: النشر إلى الإنتاج
run: npm run deploy
env:
DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
متى تستخدم GitHub Flow
GitHub Flow مثالي لسيناريوهات معينة:
✓ مثالي لـ:
- تطبيقات الويب
- منتجات SaaS
- APIs والخدمات الدقيقة
- بيئات النشر المستمر
- فرق صغيرة إلى متوسطة
- مشاريع ذات عمليات نشر متكررة
- مشاريع المصدر المفتوح
✗ فكر في البدائل لـ:
- تطبيقات الهاتف المحمول (تأخيرات موافقة App Store)
- برامج سطح المكتب (إصدارات مجدولة)
- مشاريع ذات دورات QA طويلة
- إصدارات إنتاج متعددة
- مشاريع تتطلب فروع إصدار
GitHub Flow مقابل Git Flow
فهم الاختلافات الرئيسية:
GitHub Flow:
+ بسيط وسهل التعلم
+ فرع رئيسي واحد (main)
+ نشر مستمر سريع
+ الحد الأدنى من العبء
+ رائع لتطبيقات الويب
- لا توجد عملية إصدار منظمة
- غير مثالي لإصدارات متعددة
Git Flow:
+ إدارة إصدار منظمة
+ فروع متعددة طويلة الأجل
+ تحكم واضح في الإصدار
+ جيد للإصدارات المجدولة
- أكثر تعقيداً
- دورة نشر أبطأ
- عبء أعلى
أفضل ممارسات GitHub Flow
✓ احتفظ بفرع main دائماً قابلاً للنشر
✓ أنشئ فروعاً لجميع التغييرات
✓ استخدم أسماء فروع وصفية
✓ الالتزام والدفع بشكل متكرر
✓ افتح طلبات السحب مبكراً
✓ اكتب أوصاف PR مفصلة
✓ راجع الكود بدقة
✓ استخدم فحوصات الحالة (CI/CD)
✓ اختبر قبل الدمج
✓ انشر فوراً بعد الدمج
✓ احذف الفروع المدمجة
✓ احتفظ بالفروع قصيرة الأجل (ساعات/أيام، وليس أسابيع)
معالجة الإصلاحات العاجلة
الإصلاحات السريعة تتبع نفس العملية:
# الإصلاحات العاجلة تستخدم نفس سير العمل
git checkout main
git pull origin main
git checkout -b fix-critical-security-bug
# إصلاح المشكلة
git commit -m "Fix security vulnerability in auth"
git push -u origin fix-critical-security-bug
# إنشاء PR (يمكن وضع علامة عاجل)
gh pr create --title "HOTFIX: Security vulnerability" \
--body "Critical security fix" \
--label "urgent"
# مراجعة سريعة ودمج
# النشر تلقائياً إلى الإنتاج
السرعة مقابل الأمان: حتى بالنسبة للإصلاحات العاجلة، حافظ على عملية PR. المراجعة السريعة جيدة، ولكن لا تتخطى مراجعة الكود تماماً - زوج آخر من العيون يمكن أن يلتقط المشكلات.
إدارة بيئات متعددة
استراتيجية النشر لبيئات مختلفة:
الإعداد الشائع:
التطوير:
- نشر تلقائي لفروع PR إلى عناوين URL للمعاينة
- كل PR يحصل على بيئته الخاصة
الاختبار:
- نشر فرع main تلقائياً
- بيئة اختبار ما قبل الإنتاج
- مرآة للإنتاج
الإنتاج:
- نشر فرع main بعد مرور اختبارات الاختبار
- مشغل تلقائي أو يدوي
- مراقبة المشكلات
استراتيجية التراجع
معالجة المشكلات بعد النشر:
# الخيار 1: إلغاء التزام الدمج
git checkout main
git pull origin main
git revert -m 1 HEAD # إلغاء الدمج
git push origin main
# هذا ينشئ التزاماً جديداً يلغي التغييرات
# الخيار 2: إنشاء فرع إصلاح للأمام
git checkout main
git checkout -b fix-deployment-issue
# إصلاح المشكلة
git commit -m "Fix deployment issue"
# إنشاء PR ودمج بسرعة
# الخيار 3: استخدام أدوات النشر
# تسمح العديد من المنصات بالتراجع الفوري إلى الإصدار السابق
# مثال: Heroku، Vercel، AWS، إلخ.
نصائح تعاون الفريق
التواصل:
- استخدم أوصاف PR لشرح السياق
- اربط المشكلات و PRs ذات الصلة
- أضف لقطات شاشة لتغييرات واجهة المستخدم
- اذكر أعضاء الفريق للمدخلات
مراجعة الكود:
- راجع في غضون 24 ساعة
- كن محدداً في التعليقات
- اقترح، لا تطلب
- وافق عندما تكون راضياً
إدارة الفرع:
- احتفظ بالفروع محدثة مع main
- احذف بعد الدمج
- أغلق PRs القديمة
- فرع واحد لكل ميزة/إصلاح
تمرين عملي:
المهمة: ممارسة سير عمل GitHub Flow الكامل
- إنشاء مستودع جديد على GitHub
- إعداد قواعد حماية الفرع لـ main
- إنشاء فرع ميزة:
git checkout -b add-homepage - إضافة ملف index.html والالتزام
- دفع الفرع:
git push -u origin add-homepage - إنشاء طلب سحب على GitHub
- طلب مراجعة من زميل في الفريق (أو نفسك للتدريب)
- إجراء تغيير بناءً على "تعليقات المراجعة"
- دمج PR باستخدام "Squash and merge"
- حذف فرع الميزة
- إعداد GitHub Actions للنشر التلقائي عند الدمج إلى main
النتيجة المتوقعة: فهم كامل لـ GitHub Flow من إنشاء الفرع إلى النشر.
الأخطاء الشائعة التي يجب تجنبها
الخطأ: الالتزام مباشرة بـ main
الحل: استخدم قواعد حماية الفرع لمنع هذا
الخطأ: فروع طويلة الأجل
الحل: احتفظ بالفروع صغيرة وادمج بشكل متكرر
الخطأ: تخطي مراجعة الكود
الحل: طلب موافقات PR في حماية الفرع
الخطأ: عدم الاختبار قبل الدمج
الحل: استخدم CI/CD وفحوصات الحالة
الخطأ: دمج كود مكسور
الحل: تأكد من مرور جميع الاختبارات قبل الدمج
الخطأ: أوصاف PR ضعيفة
الحل: استخدم قوالب PR واشرح التغييرات بوضوح
الأدوات التي تدعم GitHub Flow
CI/CD:
- GitHub Actions
- CircleCI
- Travis CI
- Jenkins
النشر:
- Vercel
- Netlify
- Heroku
- AWS Amplify
مراجعة الكود:
- GitHub Code Review
- تطبيقات المراجعة (عمليات نشر المعاينة)
- الفحوصات الآلية (linters، الاختبارات)
إدارة المشروع:
- GitHub Projects
- GitHub Issues
- التكامل مع Jira، Linear، إلخ.
الملخص
في هذا الدرس، تعلمت:
- GitHub Flow هو سير عمل بسيط قائم على الفروع
- ست خطوات: فرع، التزام، PR، مراجعة، نشر، دمج
- يُستخدم فرع واحد طويل الأجل فقط (main)
- فرع Main دائماً قابل للنشر
- طلبات السحب هي محور سير العمل
- قواعد حماية الفرع تفرض أفضل الممارسات
- النشر المستمر يحدث في كل دمج
- مثالي لتطبيقات الويب والتسليم المستمر
- أبسط من Git Flow ولكن يتطلب انضباطاً
- استراتيجيات التراجع تتعامل مع مشكلات النشر
التالي: في الدرس التالي، سنستكشف التطوير المبني على الجذع، وهو سير عمل أبسط للفرق التي تريد تكراراً سريعاً للغاية!