في 24 أبريل 2026، سياسة GitHub لتدريب النماذج تغيّرت بالنسبة لخطط Copilot الفردية. يمكن لـ GitHub الآن استخدام التفاعلات من Copilot Free وPro وPro+ وMax، بما في ذلك المدخلات والمخرجات ومقتطفات الشيفرة والسياق المرتبط بها، لتدريب نماذج الذكاء الاصطناعي وتحسينها ما لم ينسحب المستخدم. تبقى بيانات Copilot Business وEnterprise محمية بموجب اتفاقية حماية البيانات لدى GitHub. والأهم: يتعلق الأمر ببيانات التفاعل مع Copilot، لا بالمستودعات الخاصة التي تقبع دون استخدام على GitHub.
وفي الوقت نفسه، عادت حجج الانتقال إلى الظهور لسبب مختلف: كانت خوادم Git العامة ذاتية الاستضافة تستوعب حركة آلية كثيفة. جمعت مناقشة على Hacker News مجموعة مفيدة من تقارير المشغّلين حول تلك المشكلة: نهاية حقبة بالنسبة لي: لا مزيد من git ذاتي الاستضافة.
وهذا يترك سؤالاً أنفع من «GitHub أم الاستضافة الذاتية؟»: ما المشكلة التي تحاول حلها فعلاً؟
النسخة المختصرة
ثلاث إجابات. اختر ما يناسب وضعك.
- A: الانسحاب والبقاء. استخدم هذا الخيار عندما يكون تغيير تدريب Copilot هو شاغلك الوحيد ولا يزال GitHub يلبي احتياجات فريقك التشغيلية. عطّل الإعداد على مستوى الحساب وواصل عملك.
- B: شغّل نموذجاً هجيناً. أبقِ المشاريع مفتوحة المصدر العامة على GitHub من أجل أثر الشبكة. انقل الشيفرة الخاصة إلى خادم Forgejo أو Gitea أو GitLab CE ذاتي الاستضافة خلف VPN أو قائمة عناوين IP مسموح بها. استخدم هذا عندما يهمّك الوصول العام والتحكم الخاص في آن واحد.
- C: الهجرة الكاملة. انقل كل شيء بعيداً عن GitHub. استخدم هذا عندما تستبعد اللوائح أو موطن البيانات أو الحوكمة أو سياسة البرمجيات الحرة حصراً استخدام GitHub، ويستطيع الفريق تحمّل تكلفة التشغيل.
معظم القرّاء في الموقف A أو B. أما الموقف C فتبرّره متطلبات أكثر صرامة في الحوكمة أو السيادة أو القيم، لا إعداد Copilot وحده.
ما الذي تغيّر فعلاً في أبريل 2026
التغيير التقني صغير. في إعدادات Copilot، يمكن للمشتركين الأفراد ضبط «Allow GitHub to use my data for AI model training» على Disabled. يصف GitHub المواد المشمولة بأنها التفاعلات مع ميزاته وخدماته، بما فيها المدخلات والمخرجات ومقتطفات الشيفرة والسياق المرتبط بها، لا محتويات المستودعات الخاصة التي لم تمر يوماً عبر Copilot.
لا يظهر هذا المفتاح في Copilot Business وEnterprise لأن بياناتهما محمية باتفاقية حماية البيانات لدى GitHub. أما في الخطط الفردية، فتعطيل الإعداد يعالج مسألة سياسة التدريب، لكنه لا يحلّ اعتراضاً أوسع على الاعتماد على سياسة يتحكم بها المزوّد.
قد يكون تغيير Copilot هو الشرارة دون أن يكون القضية كلها. فقد يهم الفريق أيضاً الاعتماد على المنصة، والهوية المرتبطة بـ GitHub، وسير العمل المبني حول Actions، وموطن البيانات، أو مدى سهولة الانتقال مجدداً لاحقاً. هذه أسئلة هجرة، أما مفتاح التدريب فليس سوى إعداد واحد.
هذا التمييز مهم: الانسحاب يغيّر إعداداً واحداً لاستخدام البيانات، أما الهجرة فتغيّر من يتحكم بالاستضافة والهوية والتكاملات والسياسة. القرار الثاني يحمل تكلفة تشغيلية أكبر بكثير.
شرح المواقف الثلاثة
القرار مختصراً في ثلاثة صفوف. التفاصيل أدناه.
| ما يشغلك | الإجابة | ما الذي يجب فعله |
|---|---|---|
| بيانات تفاعلي مع Copilot تُستخدم للتدريب | الانسحاب والبقاء (الموقف A) | بدّل الإعداد وعُد إلى عملك |
| شيفرة خاصة لا أريدها لدى مزوّد أمريكي + مشاريع مفتوحة المصدر نشطة لا أريد إخفاءها | هجين (الموقف B) | استضِف المستودعات الخاصة ذاتياً خلف VPN، وأبقِ المشاريع مفتوحة المصدر العامة على GitHub |
| السيادة، أو قطاع خاضع للتنظيم، أو التزام مبدئي بالبرمجيات الحرة حصراً، أو استقلال كامل عن المزوّد | هجرة كاملة (الموقف C) | انقل كل شيء، وخصّص ميزانية لتكلفة التشغيل |
الموقف A: الانسحاب والبقاء
إن كنت مطوراً منفرداً أو فريقاً صغيراً لديه مستودعات خاصة، وشكواك الوحيدة هي الإعداد الافتراضي للتدريب، فهذه هي إجابتك. تبديل إعداد: دقيقة واحدة، مرة واحدة. أما الاستضافة الذاتية: فاتورة VPS صغيرة، واستراتيجية نسخ احتياطي تختبرها فعلاً، وتكاملات عليك إعادة بنائها لأنها افترضت مصادقة GitHub، وترقية أو عملية استرجاع عابرة تقع في أسوأ وقت ممكن.
قد تظل الاستضافة الذاتية تستحق العناء، لكن فقط إذا كان ذلك العمل المتكرر يشتري لك شيئاً تحتاجه فعلاً.
أقوى اعتراض: المفتاح نفسه قرار من المزوّد. فقد انتقل GitHub في 2026 من عدم استخدام بيانات التفاعل هذه في التدريب افتراضياً إلى استخدامها افتراضياً، ويمكنه تغيير السياسة مجدداً.
إن كان همّك الأساسي هو «لا أريد أبداً أن يتخذ مزوّد أمريكي قرارات أحادية بشأن شيفرتي»، فلا يوجد مربع اختيار يحلّ ذلك، والموقف A إجابة خاطئة بالنسبة لك. انتقل مباشرة إلى الموقف C.
أما إن كان همّك تحديداً «لا أريد بيانات تفاعلي الحالية مع Copilot في التدريب»، وستثق بإعداد GitHub إلى أن يتغير شيء آخر، فالموقف A هو أرخص إجابة صحيحة. ولا عيب في أن يكون الحل رخيصاً وصحيحاً.
الموقف B: تشغيل نموذج هجين
الاستضافة الهجينة تفصل الوصول العام عن التحكم الخاص.
التقسيم بسيط. المشاريع مفتوحة المصدر العامة تبقى على GitHub: أثر الشبكة، ورافد المساهمين، وDependabot، ومنظومة Actions قيمة حقيقية. أما الشيفرة الخاصة فتنتقل إلى خادم ذاتي الاستضافة خلف VPN أو قائمة عناوين IP مسموح بها، لا يمكن الوصول إليه أبداً من الإنترنت العام.
سبب نجاح ذلك خاصية في نموذج التهديد. فمسألة تدريب Copilot لا تنطبق إلا على بيانات التفاعل التي ترسلها عبر GitHub. ومشكلة حركة كاشطات الذكاء الاصطناعي (القسم التالي) لا تنطبق إلا على الخوادم التي يمكن الوصول إليها علناً. أما الإعداد الهجين الخاص فيتفادى الأمرين معاً.
لفريق خاص من شخصين إلى عشرة، يمثّل 2 vCPU و4 GB من الذاكرة نقطة انطلاق أكثر أماناً لـ Forgejo أو Gitea، مع هامش أكبر إذا شاركت فهرسة البحث أو الحزم أو التكامل المستمر الخادم نفسه. اعتبر ذلك تحجيماً لـ Forgejo/Gitea لا لـ GitLab CE: دليل GitLab للتثبيت على عقدة واحدة يبدأ من 8 vCPU و7.2 GB من الذاكرة، قبل أي حِمل للتكامل المستمر.
لا تعرض واجهة الويب علناً على المنفذ 80 أو 443. قيّدها عند الجدار الناري أو الوكيل أو VPN أو طبقة الشبكة المتشابكة. ويمكن لمنفذي التكامل المستمر خدمة الجانبين.
اختيار المنصة يغيّر مجموعة الميزات أكثر مما يغيّرها النموذج الهجين نفسه. يناسب Forgejo وGitea منصة تطوير خاصة أخفّ، بينما يصبح GitLab CE أكثر منطقية عندما تحتاج أيضاً إلى حزمة متكاملة لـ CI/CD وسجل الحزم.
النسخ الاحتياطي أمر ممكن التدبير، لكن لا تختزله في git bundle. إرشادات الترقية الرسمية من Forgejo تعتبر النسخة الاحتياطية الموثوقة لقطة متزامنة عند لحظة زمنية واحدة لكل مساحة التخزين التي يستخدمها Forgejo، وحين يتعذر ذلك عملياً، تُقرن نسخة forgejo dump بنسخة منفصلة من PostgreSQL أو MySQL. وسواء استخدمت Forgejo أو Gitea، احتفظ بالمستودعات وقاعدة البيانات والإعدادات والمرفقات وبيانات LFS معاً، واحتفظ بنسخة خارج الخادم، واختبر عملية الاسترجاع.
يمكن لنسخة المطور المحلية أن تستعيد الشيفرة، لكن ليس المسائل ولا المستخدمين ولا بيانات طلبات الدمج الوصفية ولا المرفقات ولا كل كائنات LFS. وإن صار فرع خاص عاماً لاحقاً، فادفعه عندئذ إلى مرآة على GitHub.
الموقف C: الهجرة الكاملة حين يكون التحكم مطلباً
تكون الهجرة الكاملة الخيار الأوضح حين يكون الاستقلال عن المزوّد مطلباً لا تفضيلاً.
تبرز ثلاث فئات: فرق خاضعة للتنظيم لديها قواعد تدقيق أو موطن بيانات أو تحكم بالمزوّد تستبعد GitHub؛ وفرق في القطاع العام أو في الاتحاد الأوروبي تكون متطلبات السيادة لديها سياسة لا تفضيلاً؛ ومؤسسات تلتزم بالبرمجيات الحرة حصراً وترغب في مغادرة بنية تحتية تملكها Microsoft ولديها بالفعل كوادر قادرة على تشغيل خدمات Linux.
التكلفة هي خادم VPS صغير وصيانة مستمرة وفقدان بعض التكاملات. وفقدان التكاملات هو الجزء الذي ينساه الناس. فكل ما يعتمد على «Sign in with GitHub» يبقى على GitHub أو يحتاج مزوّد هوية منفصلاً.
خطّط للهجرة حول التبعيات لا حول المستودعات وحدها. فمعاينات طلبات الدمج، وإجراءات Actions من أطراف ثالثة، والروبوتات، وخطافات الويب، وسجلات الحزم، وتكاملات «Sign in with GitHub» قد تحتاج إلى بيانات اعتماد جديدة أو مسارات عمل جديدة أو خدمات بديلة. كما أن النجوم والمتابعين لا يتحولون إلى سجلات أصلية على المنصة الجديدة، لذا تتخلى المشاريع العامة أيضاً عن جزء من إشارة اكتشافها القائمة.
جرّب تشغيلاً تجريبياً قبل تغيير المستودع البعيد المعتمد: انقل مستودعاً واحداً يمثّل الحالة، وأعد بناء تكاملاته، واختبر سجل المسائل وطلبات الدمج، ووثّق مسار التراجع. أما مقارنة المنصات فتأتي بعد تدقيق التبعيات هذا.
للفرق التي تريد حوكمة غير ربحية دون تشغيل خادم، يستحق Codeberg النظر.
نصيحة بشأن السيادة. إن اخترت الاستضافة الذاتية لأسباب تتعلق بموطن البيانات في الاتحاد الأوروبي، فموقع مركز البيانات مهم. مواقع مثل فرانكفورت أو أمستردام هي الخيار المملّ لكن الصحيح. أما أرخص خادم VPS في فرجينيا فلن يفيد اتفاقية معالجة البيانات لديك.
التكلفة التشغيلية لاستضافة Git العامة
الاستضافة الذاتية العامة تعرّض منصة التطوير لنفس الحركة الآلية التي تصيب أي تطبيق متاح على الإنترنت، غير أن صفحات المستودعات تتضمن مسارات مكلفة مثل عروض blame والأرشيفات وسجل الإيداعات. والتقارير التالية تجارب فردية لمشغّلين، لا قياسات مرجعية.
في نقاش Git ذاتي الاستضافة المذكور آنفاً، أبلغ أحد المشغّلين عن 37,212,377 طلباً على خادم cgit خلال 60 يوماً، صُنّف أكثر من 99% منها على أنه روبوتات.
وفي النقاش نفسه، ذكر kstrauser أنه خفّض خادم Forgejo من نحو 600,000 طلب يومياً إلى نحو 1,000 طلب، لكن فقط بعد إضافة تحدٍّ يعتمد على JavaScript وملفات تعريف الارتباط فوق وسائل التخفيف المعتادة.
وذكر مشغّلون آخرون fail2ban، وحجب GeoIP، وتوجيه حركة أنظمة ذاتية كاملة إلى ثقب أسود، وإعادة المستودعات إلى منصات مستضافة. تُظهر هذه التقارير أنماط إخفاق محتملة، وليست مقاييس مرجعية عامة لحركة المرور.
السبب التقني لصعوبة الأمر: تحديد المعدل البسيط لكل عنوان IP قد يفشل أمام حركة تتنقل عبر وكلاء منزليين. فأسطول الكاشطات يستطيع توزيع الطلبات على عدد كافٍ من عناوين IP بحيث لا يبدو أي عنوان مسيئاً، بينما يظل الخادم غارقاً في المحصلة.
قد تقلّل تحديات JavaScript أو ملفات تعريف الارتباط من الكشط البسيط، لكنها قد تحجب أيضاً المستخدمين الذين لا يشغّلون JavaScript، وتعطّل Git عبر HTTPS إذا طُبّقت على كل المسارات. أما التخزين المؤقت عبر شبكة توصيل المحتوى فيساعد في القراءات المتكررة، ويقلّ نفعه كثيراً مع النقاط الفريدة أو المكلفة مثل الأرشيفات وعروض blame وصفحات كل إيداع.
ما يغيّره التحدي هو اقتصاديات المسألة. Anubis يوضع أمام منصة التطوير ويجبر العميل على اجتياز تحدٍّ، مثل حساب صغير لإثبات العمل، قبل أن يعيد الخادم الصفحة المحمية، وهو ما يرفع كلفة الزحف واسع النطاق. إنه إجراء تخفيف، لا ضمانة.
طبّق تحديات المتصفح بشكل انتقائي. أبقِ SSH متاحاً لعمليات Git، واختبر Git عبر HTTPS قبل حماية ذلك المسار؛ فصفحة تحدٍّ تُعاد إلى عميل Git تتحول إلى استنساخ فاشل، لا إلى خطوة تحقق مفيدة.
يمتص GitHub هذا الصنف من الحركة كجزء من خدمته المستضافة. أما خادم Forgejo أو cgit العام فيترك لك تخطيط السعة وضوابط إساءة الاستخدام والتخزين المؤقت وإجراءات التخفيف. هذا النقل التشغيلي، لا التكلفة الخام للبرمجيات، هو الجزء المهم في قرار الهجرة.
لهذا يكون النموذج الهجين خياراً من الدرجة الأولى لا خطة احتياطية. الشيفرة الخاصة خلف VPN: لا تستطيع الكاشطات الوصول إليها. والمشاريع مفتوحة المصدر العامة على GitHub: بنية GitHub لمكافحة الإساءة هي التي تتولى حركة الروبوتات.
وإن كنت ما زلت تريد منصة تطوير عامة ذاتية الاستضافة، فخصّص ميزانية للسجلات وضوابط المعدل والتخزين المؤقت والتصدي للروبوتات والمراقبة، ومساراً مختبراً لحركة Git لا يعتمد على تحديات المتصفح. وتعامل مع الدفاع ضد الكاشطات كجزء من التشغيل الاعتيادي، لا كحالة استثنائية.
مسألة أثر الشبكة لمشرفي المشاريع مفتوحة المصدر
أخاطب هنا قارئاً بعينه: أنت تشرف على مشروع مفتوح المصدر. عشرون مساهماً، ومئتا نجمة، ومتتبّع مسائل نشط. وأنت تفكر في نقله بعيداً عن GitHub.
كن صريحاً بشأن ما تقايضه: قابلية اكتشافك من المساهمين، وعلامة الثقة الضمنية لـ github.com، وDependabot، وCodeQL، ومنظومة الأطراف الثالثة التي تتمحور حول مصادقة GitHub. لا شيء من ذلك مستحيل في مكان آخر، لكن كل واحد منها يصبح احتكاكاً.
القاعدة العملية التي أقترحها: إذا كانت قيمة مشروعك في الشيفرة أساساً، فتبرير الاستضافة الذاتية أسهل.
الشيفرة تنتقل بسهولة. لكن إن كانت قيمتها تعتمد بقوة على المساهمين والمسائل والظهور في نتائج البحث والثقة المرتبطة بـ github.com، فإن الرحيل يقايض جزءاً مما يجعل المشروع ناجحاً بما يجعل المشرف يشعر بارتياح. مقايضة مشروعة إن كانت أسبابك كبيرة بما يكفي. ومقايضة سيئة إن كنت تفعلها لإثبات وجهة نظر.
نظرة عامة على منصة Codeberg تصف خدمة قائمة على Forgejo تديرها الجمعية غير الربحية Codeberg e.V. وبالنسبة لمشرفي المشاريع مفتوحة المصدر، يعني ذلك حوكمة مجتمعية دون عبء صيانة تشغيل المنصة بنفسك.
أما الفرق المنحازة للمصادر المفتوحة والتي تريد حوكمة مجتمعية دون واجب الترقية، فيمثّل لها ذلك قفزة تشغيلية أصغر من تشغيل منصة عامة. أما SourceHut فيمثّل تغييراً أكثر تعمّداً في سير العمل ويحتاج تقييماً منفصلاً.
اصنع أصغر تغيير يحلّ المشكلة
قبل تغيير المستودعات البعيدة، اكتب المطلب في جملة واحدة: إيقاف التدريب على بيانات التفاعل مع Copilot، أو فصل الاستضافة العامة عن الخاصة، أو إزالة GitHub من البنية. وإن لم تستطع تسمية المطلب، فلا تهاجر بعد.
عند الهجرة، ابدأ بمستودع تجريبي واحد يمثّل الحالة. وأحصِ المصادقة وإجراءات Actions وخطافات الويب ونشر الحزم وبيئات المعاينة وسجل المسائل وبيانات LFS وخطوات التراجع قبل تغيير المستودع البعيد المعتمد.
Cloudzy's نشر Forgejo بنقرة واحدة طريقة سريعة لإعداد الجانب الخاص من نموذج هجين، كما أن التثبيت اليدوي على أي Linux VPS يعمل أيضاً. وأياً كان المسار الذي تختاره، أبقِ واجهة الويب خاصة، وخذ نسخة احتياطية من حالة التطبيق كاملة، واختبر الاسترجاع قبل نقل مستودع حسّاس.
ابنِ على خادم Linux VPS بوصول root وتخزين NVMe وقوة AMD EPYC.
عرض باقات Linuxالتحكم لا يكون مفيداً إلا حين يحلّ المطلب بتكلفة تشغيلية يستطيع فريقك تحمّلها على المدى الطويل.
الأسئلة الشائعة
هل ينبغي أن أنتقل من GitHub بسبب تغيير التدريب في Copilot؟
ليس تلقائياً. إن كان شاغلك الوحيد هو استخدام بيانات التفاعل مع Copilot لتدريب النماذج، فتعطيل الإعداد على مستوى الحساب هو أصغر إصلاح صحيح. أما الهجرة فتصبح منطقية عندما تحتاج أيضاً إلى ضوابط أقوى لموطن البيانات أو الحوكمة أو الاستقلال عن المزوّد أو سياسة البرمجيات الحرة حصراً.
هل يدرّب GitHub نماذجه على كل مستودعاتي الخاصة؟
لا. تغيير السياسة الذي نناقشه هنا يشمل بيانات التفاعل المؤهلة مع Copilot، بما فيها المدخلات والمخرجات ومقتطفات الشيفرة والسياق المرتبط بها المُرسلة عبر Copilot. وهذا لا يعني أن كل مستودع خاص مخزّن على GitHub يُستخدم تلقائياً لتدريب النماذج.
هل استضافة Git ذاتياً أكثر خصوصية دائماً؟
فقط إن شغّلته بهذه الطريقة. فمنصة خاصة خلف VPN أو قائمة عناوين IP مسموح بها قد تقلّل التعرّض، لكن خادماً يمكن الوصول إليه علناً يضيف مسؤوليات الترقيع والمراقبة والتصدي للروبوتات والتحكم بالوصول والنسخ الاحتياطي، وهي أمور يتحملها GitHub عادة.
أي منصة Git ذاتية الاستضافة ينبغي أن أختار؟
اختر Forgejo أو Gitea إن أردت منصة خاصة أخفّ. واختر GitLab CE حين يكون CI/CD المدمج وسجل الحزم أو الحاويات مهماً بما يكفي لتبرير متطلباته الأعلى من الموارد والصيانة.
ما حجم خادم VPS الذي يحتاجه Forgejo أو Gitea لفريق صغير؟
لفريق خاص من شخصين إلى عشرة، يمثّل 2 vCPU و4 GB من الذاكرة نقطة انطلاق أكثر أماناً. وزِد السعة عندما تتشارك فهرسة البحث أو الحزم أو المستودعات الكبيرة أو منفذو التكامل المستمر الخادم نفسه. أما GitLab CE فاحسب حجمه على حدة لأنه يحتاج موارد أكثر.
ما الذي ينبغي أن أختبره قبل تغيير المستودع البعيد المعتمد؟
جرّب على مستودع تجريبي يمثّل الحالة. وتحقق من سجل المسائل وطلبات الدمج، والمصادقة، وإجراءات Actions أو مسارات التكامل المستمر البديلة، وخطافات الويب، ونشر الحزم، وبيانات LFS، وبيئات المعاينة، والنسخ الاحتياطي، والاسترجاع، ومسار التراجع، قبل نقل كل شيء.
