Git و GitHub

استراتيجيات التعاون الجماعي

13 دقيقة الدرس 34 من 35

استراتيجيات التعاون الجماعي

في هذا الدرس، سنستكشف استراتيجيات التعاون الجماعي الفعال باستخدام Git و GitHub. هذه الممارسات تضمن التنسيق السلس وجودة الكود ونجاح المشروع عند العمل مع مطورين متعددين.

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

الإعداد المناسب للمستودع أمر حاسم للتعاون الجماعي:

قائمة تحقق إعداد المستودع الأولي:

✓ إنشاء اسم مستودع ذي معنى
✓ إضافة README.md شامل
✓ تضمين ملف LICENSE
✓ إعداد .gitignore لمجموعة التقنيات الخاصة بك
✓ إضافة إرشادات CONTRIBUTING.md
✓ إنشاء CODE_OF_CONDUCT.md
✓ إعداد قوالب القضايا
✓ إنشاء قالب طلب السحب
✓ تكوين قواعد حماية الفرع
✓ إعداد GitHub Actions لـ CI/CD

ملفات المستودع الأساسية:

# README.md - نظرة عامة على المشروع
- وصف المشروع
- تعليمات التثبيت
- أمثلة الاستخدام
- روابط التوثيق
- رابط إرشادات المساهمة
- معلومات الترخيص

# CONTRIBUTING.md - إرشادات المساهمة
- كيفية إعداد بيئة التطوير
- معايير واتفاقيات الترميز
- اتفاقيات تسمية الفروع
- إرشادات رسالة الالتزام
- عملية طلب السحب
- توقعات مراجعة الكود

# .github/PULL_REQUEST_TEMPLATE.md
## Description
وصف موجز للتغييرات

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update

## Testing
- [ ] Tests pass locally
- [ ] Added new tests
- [ ] Updated documentation

## Related Issues
Closes #123

نصيحة محترف: أنشئ قالب مستودع مع كل هذه الملفات مكونة مسبقاً، بحيث يمكن للمشاريع الجديدة أن تبدأ بأفضل الممارسات المدمجة.

قواعد حماية الفرع

حماية الفرع تمنع الدفع المباشر إلى الفروع المهمة وتفرض معايير الجودة:

# تكوين حماية الفرع
1. اذهب إلى Settings > Branches
2. أضف قاعدة حماية الفرع
3. نمط اسم الفرع: main (أو master)
4. قم بتكوين إعدادات الحماية

إعدادات الحماية الموصى بها:

✓ طلب طلب سحب قبل الدمج
  - طلب الموافقات: 1-2 مراجعين
  - رفض الموافقات القديمة على الالتزامات الجديدة
  - طلب مراجعة من أصحاب الكود

✓ طلب اجتياز فحوصات الحالة
  - طلب تحديث الفروع
  - إضافة الفحوصات المطلوبة (الاختبارات، التدقيق، البناء)

✓ طلب حل المحادثة
  - يجب حل جميع التعليقات

✓ طلب التزامات موقعة (اختياري)
  - يضمن صحة الالتزام

✓ طلب تاريخ خطي (اختياري)
  - يمنع التزامات الدمج، يفرض إعادة الأساس

✓ تضمين المسؤولين
  - حتى المسؤولين يجب أن يتبعوا هذه القواعد

✗ السماح بالدفع القسري: أبداً
✗ السماح بالحذف: أبداً

حرج: احم دائماً فروع الإنتاج/الرئيسية الخاصة بك. دفع قسري واحد يمكن أن يدمر تاريخ الفريق ويسبب اضطرابات كبيرة.

ملف CODEOWNERS

CODEOWNERS يعين المراجعين تلقائياً بناءً على مسارات الملفات:

# .github/CODEOWNERS

# المالكون العامون (احتياطي لكل شيء)
*       @org/senior-developers

# كود الواجهة الأمامية
*.js    @org/frontend-team
*.jsx   @org/frontend-team
*.css   @org/frontend-team
/src/components/  @org/frontend-team @jane

# كود الواجهة الخلفية
*.py    @org/backend-team
*.java  @org/backend-team
/src/api/  @org/backend-team @john

# قاعدة البيانات
*.sql   @org/database-team @bob
/migrations/  @org/database-team

# DevOps و CI/CD
*.yml   @org/devops-team
*.yaml  @org/devops-team
Dockerfile  @org/devops-team
/.github/workflows/  @org/devops-team @alice

# التوثيق
*.md    @org/documentation-team
/docs/  @org/documentation-team

# الملفات الحساسة للأمان
/config/secrets/  @org/security-team
*.key   @org/security-team

كيف يعمل CODEOWNERS:

1. المطور ينشئ PR يلمس src/components/Button.js
2. GitHub يطلب تلقائياً المراجعة من @org/frontend-team
3. يجب أن يوافق عضو واحد على الأقل من فريق الواجهة الأمامية
4. بمجرد الموافقة واجتياز الفحوصات، يمكن دمج PR

الفوائد:
✓ تعيين المراجعين التلقائي
✓ يضمن مراجعة الخبراء ذوي الصلة للتغييرات
✓ يقلل من الاختناقات (يوزع المراجعات)
✓ يحسن جودة الكود
✓ توزيع المعرفة عبر الفريق

مهم: يعمل CODEOWNERS بشكل أفضل مع حماية الفرع التي تتطلب مراجعات أصحاب الكود. قم بتمكين "Require review from Code Owners" في إعدادات حماية الفرع.

المراجعات المطلوبة

وضع متطلبات مراجعة الكود واضحة لفريقك:

متطلبات المراجعة حسب نوع PR:

تغييرات صغيرة (1-50 سطر):
- موافقة واحدة مطلوبة
- دوران سريع متوقع
- أمثلة: إصلاحات الأخطاء المطبعية، تحديثات بسيطة

تغييرات متوسطة (51-300 سطر):
- 1-2 موافقات مطلوبة
- مراجعة مفصلة مطلوبة
- أمثلة: ميزات جديدة، إعادة الهيكلة

تغييرات كبيرة (301+ سطر):
- 2+ موافقات مطلوبة
- النظر في تقسيمها إلى PRs أصغر
- أمثلة: ميزات رئيسية، تغييرات معمارية

تغييرات حرجة:
- 2-3 موافقات + مراجعة فريق الأمان
- اختبار مكثف مطلوب
- أمثلة: المصادقة، المدفوعات، ترحيل البيانات

توقعات وقت استجابة المراجعة:

SLA مراجعة الفريق:

الأولوية 1 (إصلاح عاجل): 1-2 ساعات
الأولوية 2 (عالية): 24 ساعة
الأولوية 3 (عادية): 48 ساعة
الأولوية 4 (منخفضة): أسبوع واحد

مسؤوليات المراجع:
✓ الرد خلال الإطار الزمني لـ SLA
✓ تقديم ملاحظات بناءة
✓ اختبار التغييرات إن أمكن
✓ التحقق من مشاكل الأمان
✓ التحقق من تحديثات التوثيق
✓ الموافقة أو طلب التغييرات بوضوح

تكوين فحوصات الحالة

فحوصات الحالة التلقائية تضمن جودة الكود قبل الدمج:

فحوصات الحالة الأساسية:

1. الاختبارات التلقائية
   - اختبارات الوحدة
   - اختبارات التكامل
   - اختبارات شاملة
   - الحد الأدنى للتغطية: 80%

2. تدقيق الكود
   - ESLint (JavaScript/TypeScript)
   - Pylint (Python)
   - RuboCop (Ruby)
   - فرض اتساق نمط الكود

3. مسح الأمان
   - مسح ثغرات التبعيات
   - تحليل أمان الكود
   - كشف الأسرار

4. التحقق من البناء
   - بناء ناجح مطلوب
   - بدون تحذيرات بناء
   - بناء صورة Docker (إن وجدت)

5. فحوصات الأداء
   - حدود حجم الحزمة
   - ميزانية الأداء
   - درجات Lighthouse (الواجهة الأمامية)

مثال على سير عمل GitHub Actions لفحوصات الحالة:

name: Pull Request Checks

on:
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install dependencies
        run: npm install
      - name: Run linter
        run: npm run lint
      - name: Run tests
        run: npm test
      - name: Check coverage
        run: npm run coverage
      - name: Build
        run: npm run build

  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run security scan
        run: npm audit
      - name: Check for secrets
        uses: trufflesecurity/trufflehog@main

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

إدارة الوصول والأذونات

الأذونات المكونة بشكل صحيح تحافظ على الأمان مع تمكين التعاون:

مستويات أذونات المستودع:

Read:
- عرض الكود
- استنساخ المستودع
- فتح القضايا
- التعليق على القضايا/PRs
- الاستخدام لـ: المساهمين الخارجيين، أصحاب المصلحة

Triage:
- أذونات القراءة +
- إدارة القضايا وPRs
- تطبيق العلامات
- إغلاق/إعادة فتح القضايا
- الاستخدام لـ: مديري المجتمع، مديري المشاريع

Write:
- أذونات Triage +
- الدفع إلى الفروع غير المحمية
- إنشاء الفروع
- قبول/رفض PRs
- الاستخدام لـ: أعضاء الفريق العاديين

Maintain:
- أذونات الكتابة +
- إدارة إعدادات المستودع (محدودة)
- إدارة webhooks
- إدارة GitHub Pages
- الاستخدام لـ: المطورين الرئيسيين، قادة الفريق

Admin:
- جميع الأذونات
- حذف المستودع
- نقل الملكية
- إدارة إعدادات الأمان
- الاستخدام لـ: أصحاب المشاريع، القيادة العليا

استراتيجية الأذونات القائمة على الفريق:

# فرق على مستوى المنظمة
@org/developers          - وصول الكتابة إلى مستودعات الكود
@org/leads              - وصول الصيانة إلى مستودعات الفريق
@org/architects         - وصول المسؤول إلى المستودعات الأساسية
@org/contractors        - وصول القراءة إلى مستودعات محددة
@org/security-team      - وصول المسؤول إلى مستودعات الأمان

# أفضل الممارسات
✓ استخدام الفرق بدلاً من الأذونات الفردية
✓ اتباع مبدأ أقل امتياز
✓ مراجعة الأذونات ربع سنوياً
✓ إزالة الوصول على الفور عندما يغادر الأعضاء
✓ استخدام المتعاونين الخارجيين للوصول المؤقت
✓ تمكين متطلبات 2FA للمنظمة

سير عمل الفريق والاتفاقيات

وضع سير عمل واتفاقيات واضحة للاتساق:

سير العمل اليومي:

الصباح:
git checkout main
git pull origin main
مراجعة PRs المعينة
التحقق من إشعارات GitHub

أثناء التطوير:
إنشاء فرع ميزة من main
إجراء التزامات ذرية برسائل واضحة
الدفع بانتظام (مرة واحدة على الأقل يومياً)
الحفاظ على تحديث الفرع مع main

قبل طلب المراجعة:
المراجعة الذاتية لجميع التغييرات
تشغيل الاختبارات محلياً
تحديث التوثيق
إنشاء وصف PR واضح

بعد الموافقة:
دمج/ضغط حسب تفضيل الفريق
حذف فرع الميزة
التحقق من النشر (إذا كان تلقائياً)

اتفاقيات تسمية الفروع:

تسمية الفروع المتسقة:

feature/AUTH-123-user-login
bugfix/CORE-456-memory-leak
hotfix/critical-security-patch
release/v2.3.0
refactor/database-optimization
docs/update-api-reference

النمط: type/ticket-description
- استخدام رقم التذكرة إن وُجد
- الحفاظ على الوصف موجزاً لكن واضحاً
- استخدام الواصلات، وليس الشرطات السفلية
- جميع الأحرف صغيرة

التشغيل الآلي: استخدم Git hooks أو GitHub Actions لفرض اتفاقيات تسمية الفروع تلقائياً.

أفضل ممارسات التوثيق

التوثيق الجيد ضروري للتعاون الجماعي:

تسلسل التوثيق:

1. README.md - بداية سريعة ونظرة عامة
   - ما يفعله المشروع
   - كيفية التثبيت والتشغيل
   - رابط للتوثيق المفصل

2. دليل /docs - توثيق مفصل
   /docs
   ├── getting-started.md
   ├── architecture.md
   ├── api-reference.md
   ├── deployment.md
   └── troubleshooting.md

3. تعليقات الكود - توثيق مضمّن
   - شرح لماذا، وليس ما
   - توثيق الخوارزميات المعقدة
   - إضافة TODO/FIXME مع أرقام القضايا

4. توثيق API - للمكتبات/الخدمات
   - OpenAPI/Swagger لـ REST APIs
   - توثيق مخطط GraphQL
   - أمثلة الكود لكل نقطة نهاية

5. ADRs (سجلات قرارات المعمارية)
   /docs/adr
   ├── 001-use-postgresql.md
   ├── 002-adopt-microservices.md
   └── 003-choose-react.md

التوثيق في طلبات السحب:

متطلبات توثيق PR:

✓ تحديث README إذا كانت تغييرات تواجه المستخدم
✓ تحديث توثيق API لتغييرات نقطة النهاية
✓ إضافة/تحديث تعليقات الكود
✓ تحديث CHANGELOG.md
✓ إضافة أدلة الترحيل للتغييرات الكاسرة
✓ تضمين لقطات شاشة لتغييرات UI
✓ توثيق تغييرات التكوين

التواصل والتنسيق

التواصل الفعال يمنع التعارضات ويحسن التعاون:

قنوات الاتصال:

قضايا GitHub:
- تقارير الأخطاء
- طلبات الميزات
- تتبع المهام

طلبات السحب:
- مناقشات الكود
- ملاحظات التنفيذ
- القرارات التقنية

مناقشات GitHub:
- أسئلة عامة
- الأفكار والمقترحات
- مشاركة المجتمع

دردشة الفريق (Slack/Discord):
- أسئلة سريعة
- اجتماعات يومية
- إشعارات عاجلة

مكالمات الفيديو:
- مناقشات المعمارية
- مراجعات PR المعقدة
- تخطيط السبرنت

تجنب تعارضات الدمج من خلال التواصل:

استراتيجيات منع التعارضات:

1. التواصل المبكر:
   "أنا أعمل على إعادة هيكلة وحدة المصادقة"
   انشر في دردشة الفريق أو أنشئ قضية

2. الحفاظ على PRs صغيرة:
   الدمج بشكل متكرر لتقليل التداخل
   استهدف 200-300 سطر لكل PR

3. التنسيق على الملفات المشتركة:
   إذا كان شخصان بحاجة لتحرير نفس الملف، قم بتنسيق التوقيت
   النظر في البرمجة الزوجية

4. تحديث الفروع بانتظام:
   دمج main في فرعك يومياً
   حل التعارضات تدريجياً

5. استخدام علامات الميزات:
   نشر ميزات غير مكتملة وراء العلامات
   الدمج في main مبكراً، التمكين عندما تكون جاهزة

تمرين تطبيقي:

إعداد التعاون الجماعي:

أنشئ مستودعاً جديداً مع README و CONTRIBUTING.md و .gitignore
قم بإعداد قواعد حماية الفرع لفرع main
أنشئ ملف CODEOWNERS مع 3 أنماط على الأقل
أضف قالب طلب سحب إلى .github/
أنشئ قوالب قضايا للأخطاء وطلبات الميزات
قم بإعداد سير عمل GitHub Actions أساسي للاختبارات
اكتب توثيقاً لسير عمل Git الخاص بفريقك
قم بتكوين أذونات المستودع لأدوار الفريق المختلفة

الملخص

في هذا الدرس، تعلمت:

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

التالي: في الدرس الأخير، سنتناول سيناريوهات العالم الحقيقي الكاملة باستخدام Git و GitHub في التطوير المهني!