ربط كلود بـ GitHub عبر MCP — إدارة المشاريع بالذكاء الاصطناعي

تخيّل أن تقول لكلود: "راجع آخر Pull Request وأخبرني بأي مشاكل في الكود" — فيذهب كلود لـ GitHub، يقرأ التعديلات، ويُقدّم لك مراجعة تفصيلية. أو تقول: "أنشئ Issue لهذه المشكلة" فيُنشئها مباشرة في مستودعك. هذا ما يُتيحه GitHub MCP.

المطورون يقضون ساعات طويلة في إدارة المشاريع على GitHub — كتابة Issues، مراجعة الكود، تتبع الـ bugs، كتابة تعليقات على PRs. ربط كلود بـ GitHub عبر MCP يُحوّل كل هذه المهام لمحادثة بسيطة.

ما الذي يستطيع كلود فعله مع GitHub MCP؟

القدرات الأساسية التي تُتيحها GitHub MCP لكلود تشمل: قراءة وإنشاء Issues، قراءة Pull Requests وإضافة تعليقات عليها، تصفح الكود والبحث فيه، قراءة محتوى الملفات، إنشاء commits جديدة، إنشاء branches، عرض قائمة المستودعات، قراءة ملفات الـ workflow.

هذا يعني أن كلود يُصبح مساعداً برمجياً حقيقياً لا يقتصر على الكتابة فقط — بل يُمكنه التفاعل مع مشاريعك البرمجية الفعلية على GitHub.

المتطلبات قبل البدء

تحتاج ثلاثة أشياء فقط قبل البدء: Claude Desktop مثبت على جهازك، حساب GitHub (مجاني أو مدفوع)، وNode.js 18 أو أحدث. هذا كل شيء — لا تحتاج اشتراكاً خاصاً في GitHub ولا إعدادات معقدة.

إنشاء Personal Access Token في GitHub

هذا هو المفتاح الذي يُتيح لكلود التفاعل مع حسابك في GitHub. اتبع الخطوات التالية:

اذهب لـ GitHub.com وافتح Settings من قائمتك الشخصية. ثم Developer settings في أسفل القائمة اليسرى. ثم Personal access tokens، واختر Tokens (classic) أو Fine-grained tokens.

Fine-grained tokens الأحدث وأكثر أماناً — تُتيح تحديد صلاحيات دقيقة لكل مستودع على حدة. Classic tokens أبسط لكن أقل دقة في التحكم.

الصلاحيات المطلوبة للاستخدام الأساسي: repo (وصول كامل للمستودعات)، read:org (قراءة بيانات المنظمة إذا كنت ضمن organization)، read:user (قراءة بيانات المستخدم). إذا أردت كلود يكتب كوداً ويرفعه، أضف write:repo أيضاً.

بعد إنشاء الـ Token، انسخه واحتفظ به — لن تتمكن من رؤيته مرة أخرى بعد مغادرة الصفحة.

إعداد GitHub MCP في Claude Desktop

افتح ملف الإعداد في المسار المناسب لنظامك:

على Mac: ~/Library/Application Support/Claude/claude_desktop_config.json

على Windows: %APPDATA%\Claude\claude_desktop_config.json

أضف خادم GitHub MCP كالتالي:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-github"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_your_token_here"
      }
    }
  }
}

استبدل ghp_your_token_here بالـ Token الذي أنشأته. ثم أغلق Claude Desktop وأعد تشغيله بالكامل.

التحقق من الربط

بعد إعادة التشغيل، افتح محادثة جديدة في Claude Desktop. في منطقة الإدخال ستجد أيقونة الأدوات — انقر عليها ستجد github مُدرجاً.

اختبر الربط بهذا السؤال: "اعرض لي قائمة مستودعاتي في GitHub". إذا أجابك بقائمة مستودعاتك الفعلية، كل شيء يعمل بشكل صحيح.

إنشاء Issues بالعربية والإنجليزية

هذه من أكثر مزايا GitHub MCP استخداماً في فرق العمل العربية. يمكنك وصف المشكلة لكلود بالعربية وهو يُنشئ الـ Issue بالإنجليزية الاحترافية أو بالعربية حسب طلبك.

أمثلة على إنشاء Issues:

"أنشئ Issue في مستودع my-project يصف مشكلة:
زر الدفع في صفحة الـ checkout لا يعمل على
أجهزة iOS عند استخدام Safari. يظهر خطأ في
الـ console: TypeError: undefined is not an object"

"أنشئ Feature Request Issue لإضافة دعم
اللغة العربية في لوحة الإدارة"

"أنشئ Issue بـ label bug وأسنده لمستخدم
GitHub: @developer-name"

كلود سيُنشئ الـ Issue مع عنوان واضح ووصف تفصيلي ووسوم مناسبة — أفضل من كثير من Issues التي يكتبها المطورون بأنفسهم.

مراجعة Pull Requests مع كلود

مراجعة الكود (Code Review) مهمة حيوية تأخذ وقتاً طويلاً. كلود يُساعد في التسريع والتعمق معاً.

أمثلة على مراجعة PRs:

"راجع PR رقم 45 في مستودع my-project وأخبرني:
- هل هناك مشاكل أمنية واضحة؟
- هل الكود يتبع نمط المشروع؟
- ما التحسينات الممكنة؟"

"قارن PR رقم 45 مع PR رقم 44 وأخبرني
أيهما أفضل أداءً"

"أضف تعليقاً على PR 45 يقول: تمت المراجعة،
الكود جيد مع ملاحظة تحسين أداء الاستعلام
في السطر 47"

البحث في الكود عبر كلود

البحث في قاعدة كود كبيرة يستغرق وقتاً. كلود مع GitHub MCP يجعله لحظياً:

أنواع البحث الممكنة:

"ابحث في مستودع my-project عن كل الأماكن
التي تستخدم دالة getUserById"

"أين يتم التحقق من صلاحيات المستخدم في الكود؟"

"ابحث عن ملفات config التي تحتوي على
إعدادات قاعدة البيانات"

"اعرض لي محتوى ملف src/auth/login.js"

"ما الملفات التي تغيّرت في آخر 5 commits؟"

إدارة الفروع (Branches)

إدارة الفروع جزء أساسي من workflow أي فريق تطوير. كلود يُساعد في تنظيمها وفهمها:

إدارة الفروع مع كلود:

"اعرض لي قائمة الفروع النشطة في المستودع"

"أنشئ فرعاً جديداً باسم feature/arabic-support
من فرع main"

"أخبرني بالفرق بين فرع develop وفرع main —
ما الـ commits الموجودة في develop وغير موجودة في main؟"

"أي الفروع لم تُدمج في main منذ أكثر من شهر؟"

التكامل مع CI/CD

GitHub Actions هو نظام CI/CD المدمج في GitHub. كلود يستطيع مساعدتك في إدارة workflows وفهم نتائج التشغيل:

التكامل مع GitHub Actions:

"اعرض لي محتوى ملف .github/workflows/deploy.yml
واشرح لي كل خطوة فيه"

"أنشئ لي workflow جديد للـ testing يشتغل
عند كل Push لـ main branch"

"عدّل الـ workflow الحالي ليُضيف خطوة
للتحقق من جودة الكود باستخدام ESLint"

"ما سبب فشل آخر تشغيل لـ CI في PR 45؟"

عندما تطلب من كلود إنشاء أو تعديل ملف workflow، يُنشئ الملف ويضعه في المسار الصحيح عبر commit — وهذا يُشغّل GitHub Actions تلقائياً.

مراجعة الكود مع كلود — أسلوب احترافي

مراجعة الكود مع كلود تختلف عن مجرد قراءة الكود. إليك كيفية الحصول على أقصى فائدة:

الأسلوب الأول: مراجعة الأمان. اطلب من كلود التركيز على نقاط ضعف الأمان — SQL injection، XSS، مشاكل المصادقة، بيانات حساسة في الكود. كلود يعرف أنماط الثغرات الشائعة ويُنبّه لها.

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

الأسلوب الثالث: مراجعة الأنماط والهيكلية. هل الكود يتبع نمط المشروع؟ هل هناك تكرار يمكن إزالته؟ هل التسمية واضحة ومتسقة؟

الأسلوب الرابع: توليد تقرير المراجعة. اطلب من كلود تلخيص المراجعة في تقرير منظم يمكن مشاركته مع الفريق.

مراجعة متكاملة لـ PR:

"راجع PR 67 مراجعة شاملة وأعطني تقريراً يشمل:
1. ملخص التعديلات (3 جمل)
2. مشاكل الأمان إن وجدت
3. مشاكل الأداء إن وجدت
4. جودة الكود وهل يتبع نمط المشروع
5. توصيتك: موافق / موافق مع تعديلات / رفض"

أتمتة المهام المتكررة

من أكثر فوائد GitHub MCP هي أتمتة المهام التي تُكررها يومياً:

التقرير اليومي: في بداية كل يوم عمل، اسأل كلود عن وضع المشروع — كم Issue مفتوحة، كم PR ينتظر المراجعة، ما آخر commit في كل فرع. تقرير في ثوانٍ بدلاً من تصفح GitHub بنفسك.

تتبع الـ Bugs: كلود يستطيع قراءة كل Issues المُصنّفة bugs وترتيبها حسب الأولوية أو تاريخ الإنشاء أو عدد التعليقات.

متابعة الفريق: في المشاريع الجماعية، اسأل كلود: "ما الـ commits التي أضافها كل عضو في الفريق هذا الأسبوع؟" — نظرة سريعة على مساهمات الفريق.

ربط كلود بـ GitHub Organizations

إذا كنت تعمل ضمن منظمة على GitHub (Organization)، الإعداد نفسه يعمل لكن مع صلاحيات إضافية:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-github"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_your_token_here",
        "GITHUB_ORG": "your-organization-name"
      }
    }
  }
}

تأكد أن الـ Token لديه صلاحية read:org لقراءة بيانات المنظمة، وأن المنظمة سمحت لـ Personal Access Tokens بالوصول (بعض المنظمات تُقيّد هذا).

حالة استخدام حقيقية: فريق تطوير صغير

فريق من 4 مطورين يعملون على تطبيق SaaS. قبل GitHub MCP: مراجعة PRs تأخذ يوماً كاملاً أسبوعياً، كتابة Issues يتم تأجيله، تتبع الـ bugs فوضوي.

بعد GitHub MCP: قائد الفريق يفتح كلود كل صباح ويسأل: "ما وضع المشروع اليوم؟" فيحصل على ملخص كامل. مراجعة PRs أصبحت تستغرق 20 دقيقة بدلاً من ساعتين — كلود يقرأ الكود أولاً ويُقدم المراجعة الأولية. الـ Issues تُنشأ فوراً عند اكتشاف مشكلة بدلاً من التأجيل.

النتيجة: توفير 5-6 ساعات أسبوعياً لكامل الفريق، وتحسين جودة الكود المُدمج بشكل ملحوظ.

الجواهر الخمسة — أفكار استخدام غير تقليدية

الأسئلة الشائعة