دليل النشر

الانتقال من ‎GitLab إلى ‎Gitea على ‎VPS في 2026

انشر على VPS Cloud ←

دليل عملي

الانتقال من ‎GitLab إلى ‎Gitea على ‎VPS في 2026

التطوير10 دقائق للقراءةعدد الخطوات: 13

منذ 15 أغسطس 2026، طبّقت ‎GitLab.com وضع القراءة فقط على المساحات التي تضم أكثر من خمسة أعضاء في الخطط المجانية. بالنسبة للكثير من الفرق، هذا يعني الهجرة القسرية — وفرصة لاستعادة السيطرة. يوفر ‎Gitea بإصداره ‎1.27.3 المتاح كقالب ‎VPS على ‎ServOrbit بديلاً خفيف الوزن ومستضافاً ذاتياً يغطي معظم احتياجات فرق التطوير متوسطة الحجم. يشرح هذا الدليل تصدير ‎GitLab واستيراد ‎Gitea وإعداد ‎CI/CD وإدارة الأذونات مع أوامر حقيقية في كل خطوة.

المحتويات· لماذا أصبحت ‎GitLab.com لا تُحتمل للفرق التي تضم 5 أشخاص أو أكثر1/11
  1. 01لماذا أصبحت ‎GitLab.com لا تُحتمل للفرق التي تضم 5 أشخاص أو أكثر
  2. 02ما يوفره ‎Gitea بشكل أصلي
  3. 03المتطلبات الأساسية قبل البدء
  4. 04‎GitLab مقابل ‎Gitea — المعايير الرئيسية
  5. 05إعداد تصدير ‎GitLab
  6. 06الاستيراد إلى ‎Gitea على ‎VPS
  7. 07إعداد ‎CI/CD في ‎Gitea
  8. 08ترحيل أعضاء الفريق والأذونات
  9. 09استكشاف الأخطاء — الأخطاء الأربعة الأكثر شيوعاً
  10. 10نصيحة أمنية بعد الترحيل
  11. 11استعادة السيطرة على منصة ‎Git الخاصة بك

لماذا أصبحت ‎GitLab.com لا تُحتمل للفرق التي تضم 5 أشخاص أو أكثر

في 15 أغسطس 2026، طبّقت ‎GitLab سياسة جديدة على خطتها المجانية: تُوضع أي مساحة تضم أكثر من خمسة أعضاء تلقائياً في وضع القراءة فقط (المصدر: ‎support.gitlab.com/hc/en-us/articles/28301407860508). من الناحية العملية، لم يعد بإمكان المطورين الإضافيين دفع الكود، أو فتح طلبات الدمج، أو تشغيل خطوط ‎CI/CD. الحل الوحيد الذي تقترحه ‎GitLab هو الاشتراك المدفوع، الذي يصبح تكلفته الكبيرة لكل مقعد مرهقة سريعاً للشركات الناشئة أو الوكالات.

يأتي هذا القرار في سياق تسريع أشمل لتحقيق الإيرادات من المنصة. يؤثر بشكل خاص على فرق المصادر المفتوحة ذات الميزانية المحدودة والوكالات متعددة المشاريع والمطورين المستقلين الذين يشتركون في مساحة واحدة. وليس هذا القيد الأول من نوعه: أزالت ‎GitLab بالفعل دقائق ‎CI/CD المجانية للمستخدمين الجدد عام 2021. الاتجاه هيكلي.

أمام هذا القيد، يستعيد استضافة منصة ‎Git الذاتية على ‎VPS كل منطقه. أنت تتحكم في الوصول، تبقى البيانات على بنيتك التحتية، والتكلفة ثابتة — تكلفة الخادم وليس تكلفة المقاعد.

ما يوفره ‎Gitea بشكل أصلي

  • منصة ‎Git متكاملة — مستودعات وفروع وعلامات وطلبات سحب ومراجعة الكود المضمّنة وإدارة التعارضات عبر واجهة الويب.
  • إدارة المؤسسات والفرق — أذونات دقيقة لكل مستودع (قراءة وكتابة وإدارة) دون حدود للأعضاء.
  • ‎Gitea Actions — محرك ‎CI/CD متوافق مع صياغة ‎YAML لـ‎GitHub Actions، مما يسهّل نقل سير العمل الحالية.
  • سجل حزم مدمج — ‎npm وPyPI وMaven وDocker وHelm: انشر الحزم واستهلكها دون اعتماد خارجي.
  • ‎Webhooks وواجهة برمجية ‎REST — سطح واجهة برمجية واسع لدمج أدوات النشر وإشعارات ‎Slack ولوحات التحكم الداخلية.
  • مصادقة ‎SSO — دعم ‎LDAP وOAuth2 وSAML وOpenID Connect بشكل أصلي لمركزة إدارة الهوية.
  • استهلاك ذاكرة منخفض — تكفي ذاكرة 512 ميغابايت لفريق مكوّن من عشرة أشخاص؛ يُوصى بـ 1 جيجابايت لتشغيل عدة ‎runners متزامنة.
  • تحديثات بسيطة — ملف تنفيذي واحد أو صورة ‎Docker رسمية، وترحيل قاعدة البيانات تلقائياً عند كل تحديث للإصدار.

المتطلبات الأساسية قبل البدء

على جانب الخادم، يعمل ‎Gitea v1.27.3 بشكل مريح مع ذاكرة 512 ميغابايت للاستخدام الأدنى؛ خطط لـ 1 جيجابايت إذا قمت بتفعيل ‎Gitea Actions مع ‎runners متزامنة. ينطلق قالب ‎VPS من ‎ServOrbit من صورة ‎Debian 12 مع تثبيت ‎Docker مسبقاً — هذا هو وضع النشر الموصى به لأنه يعزل عملية ‎Gitea ويبسّط التحديثات.

على جانب الشبكة، أشر نطاقاً فرعياً إلى عنوان ‎IP الخاص بـ‎VPS قبل بدء التثبيت: يُنشئ ‎Gitea عناوين ‎URL للاستنساخ عبر ‎SSH وHTTPS عند أول تشغيل، ومن الصعب تصحيحها لاحقاً. يكفي سجل ‎A واحد ‎git.your-domain.com. ستحتاج أيضاً إلى شهادة ‎TLS — يمكن لـ‎Caddy أو ‎Traefik توليدها تلقائياً عبر ‎Let's Encrypt كـ‎proxy أمامي لـ‎Gitea.

على ‎GitLab.com، تأكد من امتلاكك صلاحيات ‎Owner على المجموعات أو المشاريع المراد ترحيلها: يتطلب التصدير هذا المستوى من الوصول. أنشئ ‎token API شخصياً مع نطاقات ‎api و‎read_repository — سيُستخدم خلال التصدير عبر ‎API.

‎GitLab مقابل ‎Gitea — المعايير الرئيسية

مرّر الجدول أفقيًا

‏المعيار‏GitLab.com Free‏Gitea VPS
حد الأعضاء (مجاني ‎SaaS)5 أعضاء (قراءة فقط ما يزيد منذ أغسطس 2026)غير محدود عند الاستضافة الذاتية
الحد الأدنى من الذاكرة4 جيجابايت (‎GitLab CE ذاتي الاستضافة)512 ميغابايت
‎CI/CD مدمج‎GitLab CI (‎YAML)‎Gitea Actions (صياغة ‎GitHub Actions)
سجل الحاوياتنعم (‎GitLab Container Registry)نعم (‎Gitea Packages — ‎Docker مضمّن)
إدارة طلبات الدمج/السحب‎Merge Requests متقدمة‎Pull Requests مع مراجعة كود مضمّنة
مصادقة ‎SSO‎SAML وLDAP وOAuth2‎LDAP وOAuth2 وSAML وOIDC
الاستيراد من ‎GitLabغير متاحاستيراد أصلي عبر ‎API أو أرشيف ‎.tar.gz
تكلفة التشغيل29 دولاراً/مستخدم/شهر (‎Premium)تكلفة ‎VPS فقط (99 درهم/شهر/شهر)

إعداد تصدير ‎GitLab

  1. سجّل الدخول إلى ‎GitLab.com وانتقل إلى المشروع الم

    سجّل الدخول إلى ‎GitLab.com وانتقل إلى المشروع المراد تصديره: ‎Settings > General > Advanced > Export project. انقر على '‎Export project' وانتظر بريد التأكيد (بضع دقائق للمستودعات الصغيرة، وحتى ساعة للكبيرة منها).

  2. للتصدير عبر ‎API دون استخدام الواجهة، شغّل التصدير بـ:

    للتصدير عبر ‎API دون استخدام الواجهة، شغّل التصدير بـ: curl --request POST --header "PRIVATE-TOKEN: <your-token>" "https://gitlab.com/api/v4/projects/<project-id>/export"

  3. تحقق من حالة التصدير بـ:

    تحقق من حالة التصدير بـ: curl --header "PRIVATE-TOKEN: <your-token>" "https://gitlab.com/api/v4/projects/<project-id>/export" — انتظر حتى الحالة finished.

  4. حمّل أرشيف التصدير:

    حمّل أرشيف التصدير: curl --location --header "PRIVATE-TOKEN: <your-token>" "https://gitlab.com/api/v4/projects/<project-id>/export/download" --output gitlab-export.tar.gz

  5. لنقل سجل ‎Git الكامل، استنسخ المستودع بجميع المراجع:

    لنقل سجل ‎Git الكامل، استنسخ المستودع بجميع المراجع: git clone --mirror [email protected]:your-group/your-project.git your-project.git

  6. تحقق من سلامة النسخة المرآة قبل النقل:

    تحقق من سلامة النسخة المرآة قبل النقل: git -C your-project.git fsck --no-progress — لا ينبغي أن تظهر أي أخطاء.

  7. انقل الأرشيف والمستودع المرآة إلى ‎VPS الخاص بك:

    انقل الأرشيف والمستودع المرآة إلى ‎VPS الخاص بك: rsync -avz gitlab-export.tar.gz your-project.git user@your-vps:/tmp/migration/

الاستيراد إلى ‎Gitea على ‎VPS

  1. على ‎VPS الخاص بك، أنشئ المؤسسة المستهدفة في ‎Gitea عبر واجه

    على ‎VPS الخاص بك، أنشئ المؤسسة المستهدفة في ‎Gitea عبر واجهة الويب أو عبر ‎API: curl -X POST "https://git.your-domain.com/api/v1/orgs" -H "Authorization: token <gitea-token>" -H "Content-Type: application/json" -d '{"username":"my-organisation","visibility":"private"}'

  2. أنشئ المستودع الفارغ في ‎Gitea قبل الاستيراد:

    أنشئ المستودع الفارغ في ‎Gitea قبل الاستيراد: curl -X POST "https://git.your-domain.com/api/v1/orgs/my-organisation/repos" -H "Authorization: token <gitea-token>" -H "Content-Type: application/json" -d '{"name":"my-project","private":true}'

  3. ادفع سجل ‎Git من النسخة المرآة:

    ادفع سجل ‎Git من النسخة المرآة: git -C your-project.git remote set-url origin https://git.your-domain.com/my-organisation/my-project.git ثم git -C your-project.git push --mirror

  4. لاستيراد ‎issues وطلبات الدمج من أرشيف ‎GitLab، استخدم أداة

    لاستيراد ‎issues وطلبات الدمج من أرشيف ‎GitLab، استخدم أداة ‎gitea-migrator أو الاستيراد الأصلي في ‎Gitea: في الواجهة، ‎+ New Migration > GitLab وأدخل عنوان ‎URL المشروع المصدر مع ‎token الخاص بـ‎GitLab.

  5. تحقق من وجود جميع الفروع والعلامات:

    تحقق من وجود جميع الفروع والعلامات: git ls-remote https://git.your-domain.com/my-organisation/my-project.git ينبغي أن يُظهر نفس المراجع الموجودة في المصدر.

  6. حدّث عناوين ‎URL للاستنساخ في إعدادات كل مطور محلياً:

    حدّث عناوين ‎URL للاستنساخ في إعدادات كل مطور محلياً: git remote set-url origin https://git.your-domain.com/my-organisation/my-project.git

إعداد ‎CI/CD في ‎Gitea

يتضمن ‎Gitea v1.27.3 ميزة ‎Gitea Actions، وهو محرك ‎CI/CD صياغة ‎YAML الخاصة به متوافقة عمداً مع ‎GitHub Actions. إذا كانت خطوط الأنابيب موجودة على ‎GitLab CI، يلزم بعض التكيّف — تترجم مراحل stages وأوامر script في ‎GitLab إلى jobs وsteps في ‎Gitea Actions — لكن المنطق يبقى نفسه.

لتفعيل الـ‎runners، ثبّت ‎act_runner على ‎VPS الخاص بك أو على جهاز مخصص: act_runner register --no-interactive --instance https://git.your-domain.com --token <runner-token> --name my-runner --labels ubuntu-latest:docker://node:20-bullseye. يوجد ‎token التسجيل في ‎Site Administration > Runners.

إذا كنت تفضل نهج ‎CI/CD أكثر انفصالاً، فإن ‎Woodpecker CI هو بديل ناضج يتكامل أصلياً مع ‎Gitea عبر ‎OAuth2 ويوفر واجهة لمراقبة ‎builds. ملف ‎pipeline الخاص به ‎.woodpecker.yml قريب أيضاً من صياغة ‎Drone CI، مما يبسّط الهجرة من ‎stacks أقدم.

ترحيل أعضاء الفريق والأذونات

ينظّم ‎Gitea الوصول على ثلاثة مستويات: المؤسسات (مكافئة لمجموعات ‎GitLab)، والفرق داخل المؤسسة، والأذونات لكل مستودع. ابدأ بإنشاء جميع حسابات المستخدمين — إما يدوياً أو بتفعيل التسجيل التلقائي مؤقتاً أو عبر ‎LDAP/SSO إذا كان متاحاً بالفعل.

أنشئ بعد ذلك الفرق في مؤسستك: تتوافق Owners وDevelopers وReporters مع أدوار ‎Owner وDeveloper وReporter في ‎GitLab. يتيح ‎Gitea تحسين الأذونات لكل مستودع داخل نفس الفريق — يمكن لمجموعة فرعية من الأعضاء الحصول على صلاحية الكتابة لمستودعات محددة فقط.

لترحيل العضويات دفعةً واحدة، تقبل ‎API لـ‎Gitea طلبات من هذا النوع: curl -X PUT "https://git.your-domain.com/api/v1/orgs/my-organisation/teams/<team-id>/members/<username>" -H "Authorization: token <gitea-token>". يكفي سكريبت ‎shell يمر عبر قائمة المستخدمين المُصدَّرة من ‎GitLab لأتمتة هذه الخطوة للفرق التي تقل عن خمسين شخصاً.

استكشاف الأخطاء — الأخطاء الأربعة الأكثر شيوعاً

remote: repository not found أثناء دفع المرآة. المستودع المستهدف غير موجود بعد في ‎Gitea، أو أن ‎token المستخدم لا يملك صلاحيات الكتابة. تحقق من إنشاء المستودع (الخطوة 2 من الاستيراد) ومن أن ‎token الخاص بك يملك نطاق write:repository.

error: src refspec refs/merge-requests/... does not match any أثناء push --mirror. المراجع الداخلية لـ‎GitLab (‎refs/merge-requests/) غير مقبولة في ‎Gitea. قم بتصفيتها صراحةً قبل الدفع: احذف المراجع الطفيلية محلياً بـ git -C your-project.git for-each-ref --format='%(refname)' refs/merge-requests | xargs -I{} git update-ref -d {}.

Error 413: Request Entity Too Large عند استيراد أرشيف كبير. الحد الأقصى لحجم الرفع مُهيَّأ في app.ini الخاص بـ‎Gitea تحت المفتاح MAX_UPLOAD_SIZE. قم بزيادته (MAX_UPLOAD_SIZE = 2048 لـ 2 جيجابايت) وأعد تشغيل الخدمة: docker compose restart gitea.

الـ‎issues المستوردة لا تُظهر المؤلفين الصحيحين. يربط ‎Gitea الـ‎issues بالحسابات المحلية من خلال اسم المستخدم. إذا اختلف اسم مستخدم ‎GitLab عن اسم مستخدم ‎Gitea، تُنسب الـ‎issues إلى المستخدم الذي شغّل الاستيراد. أنشئ جميع الحسابات بنفس أسماء المستخدمين الموجودة على ‎GitLab قبل تشغيل ترحيل الـ‎issues.

نصيحة أمنية بعد الترحيل

بمجرد اكتمال الترحيل، قم بتعطيل التسجيل التلقائي (DISABLE_REGISTRATION = true في app.ini) إذا لم تكن تستخدم ‎SSO، وفعّل المصادقة الثنائية الإلزامية لجميع أعضاء ‎Owner. كوّن أيضاً نسخاً احتياطية تلقائية لـ‎volume الـ‎Docker الذي يحتوي على data/gitea/: يحميك تفريغ يومي إلى تخزين بعيد (‎S3 أو ‎Backblaze B2) من فقدان القرص. أخيراً، تحقق من أن منفذ ‎SSH لـ‎Gitea (2222 افتراضياً في ‎Docker) غير مكشوف مباشرة على ‎IP العام إذا كنت تُصفّي بمفتاح ‎SSH — تقلّل قاعدة ‎fail2ban أو قاعدة ‎UFW التي تحد اتصالات ‎SSH في الدقيقة بشكل كبير من سطح الهجوم.

استعادة السيطرة على منصة ‎Git الخاصة بك

قيد ‎GitLab.com في 15 أغسطس 2026 سرّع اتجاهاً كان قائماً بالفعل: الفرق التي قبلت الاعتماد على منصة ‎SaaS مجانية تجد نفسها أمام قرار تسعيري غير متوقع. يلبّي ‎Gitea v1.27.3 الاحتياجات الأساسية لمنصة ‎Git للفريق — مستودعات وطلبات سحب و‎CI/CD وسجل حزم و‎SSO — بحجم يناسب ‎VPS اقتصادي.

الترحيل ليس فورياً، لكنه تسلسلي وقابل للعكس في كل خطوة: يكتمل سجل ‎Git بعد push --mirror، وتتبعه الـ‎issues وطلبات السحب عبر الاستيراد الأصلي، وتُعاد تهيئة ‎CI/CD في بضع ساعات إذا كانت سير عملك مكتوبة بـ‎YAML بالفعل. قالب ‎VPS Gitea من ‎ServOrbit يجنّبك مرحلة التثبيت والتهيئة الأولية — ‎Gitea جاهز، ‎Docker مثبّت، ولا يبقى سوى ربط نطاقك واتباع الخطوات الموضحة هنا.

‏نشر مستودع ‏Git ‏الخاص بك على ‏VPS ‏من ‏ServOrbit

‏قالب ‏Gitea v1.27.3 ‏جاهز للاستخدام، وصول كامل، نسخ احتياطية يومية. مستودعك الخاص في أقل من عشر دقائق.

بحاجة إلى مساعدة؟

تصفّح مركز المساعدة والأسئلة الشائعة، أو تواصل مع فريقنا — معاودة اتصال أو WhatsApp أو بريد إلكتروني. الدعم بـالعربية والفرنسية والإنجليزية.

راسلنا على WhatsAppيُفتح في علامة تبويب جديدة