كيفية الترحيل من Gitea إلى Forgejo دون كسر مستودعاتك

توقف Gitea، وتثبّت Forgejo، وتنسخ app.ini ومجلد البيانات، وتشغّل الخدمة بالطريقة التي يصفها كل دليل ترحيل. تظهر واجهة الويب. ثم يفشل ترحيل قاعدة البيانات، أو الأسوأ، يرفض Forgejo البدء لأن إصدار مخططك أحدث من أن يفهمه. أنت على Gitea 1.23 أو أحدث، والترقية البسيطة في المكان نفسه التي يوثقها الجميع لم تعد تنطبق عليك.

أصبح Forgejo تفرعًا صلبًا عن Gitea في أوائل 2024، ومنذ ذلك الحين تباعد المشروعان على مستوى مخطط قاعدة البيانات. كيفية ترحيل Gitea إلى Forgejo الآن تعتمد كليًا على إصدار Gitea لديك. يقدم هذا الدليل المسار الدقيق لإصدارك، والأوامر الكاملة لكلا التثبيتين الأصلي وDocker، والحلول البديلة لـ Gitea 1.23+، وقائمة تحقق، حتى تُرحّل دون فقدان المستودعات أو المشكلات أو المستخدمين.

الخلاصة السريعة

• حاجز الإصدار حقيقي. كان Forgejo v10.0 آخر إصدار يدعم ترقية مباشرة وشفافة من Gitea. Gitea v1.22 هو أعلى إصدار يمكنه سلوك المسار المباشر المدعوم.
• على Gitea v1.22 أو أقدم: رحّل أولًا إلى Forgejo v10.0.x، ثم رقّ Forgejo v10 إلى الإصدار الحالي (v15). خطوتان، كلتاهما مدعومتان.
• على Gitea v1.23 أو أحدث: لا يوجد مسار مباشر مدعوم رسميًا. تختار بين تخفيض SQL/المخطط، أو نصوص ترحيل مجتمعية، أو ترحيل عبر المستودع/API، أو ترحيل عبر إعداد خادم جديد باستخدام إحدى هذه الطرق. كل خيار يحمل مقايضة مختلفة في فقدان البيانات.
• خذ نسخة احتياطية من دليل بياناتك وقاعدة بياناتك قبل أن تلمس أي شيء. كل مسار أدناه يفترض أن لديك نسخة احتياطية قابلة للاستعادة. المسارات غير المدعومة تفترض ذلك مرتين.
• بعض الأمور تحتاج دائمًا إلى اهتمام بعد الترحيل: خطط لإعادة إنشاء أو مراجعة رموز الوصول الشخصية، وإعادة تسجيل عدّاءي Actions، وحذف فهرس بحث Bleve وإعادة بنائه. خطط لهذه الأمور بغض النظر عن المسار.
• الترحيل ليس إلزاميًا. يتم صيانة Gitea بنشاط. قرار "البقاء على Gitea" يظل صائبًا إذا كانت مخاطر الترحيل تفوق الفائدة بالنسبة لوضعك.

خارج نطاق هذا الدليل: الترحيل من Gogs أو GitHub أو GitLab إلى Forgejo، وإعداد Forgejo Actions من الصفر.

المتطلبات الأساسية / ما ستحتاجه

قبل تشغيل أي أمر، تأكد من أن لديك نسخة احتياطية كاملة وقابلة للاستعادة لأمرين: دليل بيانات Gitea (/var/lib/gitea في التثبيت الأصلي الافتراضي) وقاعدة بياناتك. إذا كانت قاعدة بياناتك SQLite، فإن هذا الملف يعيش داخل دليل البيانات؛ وإذا كانت PostgreSQL أو MySQL، فقم بتفريغها بشكل منفصل باستخدام pg_dump أو mysqldump. الترحيل بدون نسخة احتياطية موثّقة ليس ترحيلًا، بل مقامرة.

ستحتاج أيضًا إلى:

• إصدار Gitea الحالي لديك. شغّل gitea --version (أو docker exec <container> gitea --version). هذا الرقم يحدد مسارك بالكامل.
• نوع قاعدة بياناتك: SQLite أو PostgreSQL أو MySQL. بعض الحلول البديلة خاصة بنوع معين من قواعد البيانات.
• صلاحيات الجذر (root) أو sudo على الخادم.
• إدراك أن المسار المدعوم يثبّت Forgejo v10.0 كمحطة وسيطة. أصبح Forgejo v10.0 منتهي الصلاحية (EOL) منذ 16 أبريل 2025. تثبّته فقط طوال مدة الترحيل ثم ترقي بعيدًا عنه فورًا.

لماذا تعطّل مسار الترقية المباشر

في ديسمبر 2024 نشر مشروع Forgejo بيان التوافق الذي رسم خطًا فاصلًا صارمًا: "لن تدعم إصدارات Forgejo المستقبلية الترقية من نسخ Gitea التي تعمل بالإصدار v1.23 أو أحدث." هذه الجملة تلخص المشكلة بأكملها في سطر واحد.

عندما انفصل Forgejo عن Gitea في أوائل 2024، استمرت قواعد الشيفرة في الابتعاد عن بعضها، وابتعدت مخططات قواعد البيانات تدريجيًا. حافظ Forgejo على نافذة توافق حتى يتمكن مشغلو Gitea الحاليون من الانتقال، لكن هذه النافذة كان لها نهاية. كان Forgejo v10.0، الذي صدر في 16 يناير 2025، "the last version to allow a transparent upgrade from Gitea v1.22 or lower." أي إصدار أحدث من v10.0 لن يقرأ قاعدة بيانات Gitea مباشرة.

التوقيت هو ما يفاجئ الناس. صدر Gitea v1.23 في أواخر 2024، و أحدث إصدار من Gitea حتى يونيو 2026 هو v1.26.4. إذا حافظت على تحديث نسخة Gitea الخاصة بك بشكل معقول، فأنت بالفعل تجاوزت الحاجز ولم تعد الدروس التعليمية القياسية تصف وضعك.

خلاصة القسم: المسار المباشر المدعوم يتوقف عند Gitea v1.22. كل ما هو أحدث يحتاج خطوة إضافية.

اعثر على مسار الترحيل الخاص بك حسب إصدار Gitea

شغّل gitea --version، ابحث عن صفك، واتبع المسار الموجود في العمود الثالث. كل ما تبقى في هذا الدليل هو التفاصيل الكامنة خلف هذه الصفوف.

بيانات توافق الإصدارات مأخوذة مباشرة من إعلان توافق Forgejo الرسمي: يمكن لـ Gitea حتى v1.21 الانتقال إلى Forgejo من v7.0 حتى v10.0، ويمكن لـ Gitea v1.22 الانتقال إلى Forgejo من v8.0 حتى v10.0. كلاهما يتوقف عند v10.0 كآخر هدف مباشر مدعوم.

تحت سؤال الإصدار تكمن ثلاث استراتيجيات ترحيل، ومن المفيد الاطلاع عليها قبل الخطوات التفصيلية:

• في المكان نفسه، على نفس الخادم. استبدل الملف التنفيذي أو صورة الحاوية على الخادم الحالي. أقل جهد عندما يدعمه إصدارك؛ يتطلب المرور بمحطة وسيطة v10.0.
• التجهيز على خادم جديد. جهّز خادمًا جديدًا واستخدمه كهدف آمن لطريقة الترحيل التي تناسب إصدار Gitea لديك. هذا يحمي خادم Gitea الأصلي ويسهّل التراجع، لكنه لا يتجاوز مشكلة مخطط قاعدة البيانات في Gitea 1.23+.
• الترحيل عبر المستودع/API. استخدم أدوات ترحيل Forgejo لسحب المستودعات من نسخة Gitea القديمة. سجل Git هو الجزء الموثوق؛ أما البيانات الوصفية مثل التذاكر وطلبات السحب والوسوم والإصدارات وبيانات الويكي والتعليقات، فيجب التعامل معها على أنها بذل قصارى الجهد والتحقق منها مستودعًا تلو الآخر.

المسار المدعوم: Gitea v1.22 أو أقدم

إذا كنت تستخدم Gitea v1.22 أو أقدم، فإن وثائق الترحيل الرسمية تصف مسارًا من خطوتين: الترحيل إلى Forgejo v10.0.x، ثم ترقية Forgejo v10 إلى الإصدار الحالي. الخطوة الأولى هي استبدال مباشر لأن Forgejo v10.x يقرأ قاعدة بيانات Gitea v1.22؛ والخطوة الثانية هي ترقية Forgejo عادية.

هناك طريقتان للقيام بذلك حسب كيفية تشغيل Gitea على خادمك. اختر الطريقة التي تناسب إعدادك الحالي. إذا كان Gitea يعمل كخدمة نظام، استخدم المسار الأصلي. إذا كان Gitea يعمل داخل حاوية، استخدم مسار Docker. يعمل Forgejo v10.x كبديل مباشر لـGitea v1.22.x.

المسار الأصلي (systemd)

خذ نسخة احتياطية أولًا. ثم ثبّت Forgejo v10.0.x باستخدام حزمة توزيعتك أو الملف الثنائي للإصدار المثبّت على v10.0. أوقف Gitea قبل نسخ أي شيء. الخدمة قيد التشغيل التي تكتب في دليل بياناتها أثناء النسخ ستُفسد النسخة.

# Stop the running Gitea service before touching its data
systemctl stop gitea

انسخ ملف الإعدادات ودليل البيانات إلى مواقع Forgejo، ثم أصلح الملكية. يجب أن يكون ملف الإعدادات قابلًا للقراءة من قبل مجموعة forgejo؛ ويجب أن تكون البيانات مملوكة لمستخدم forgejo.

# Copy the existing Gitea config to Forgejo's config path
cp /etc/gitea/app.ini /etc/forgejo/app.ini

# Back up the copied config before rewriting paths
cp /etc/forgejo/app.ini /etc/forgejo/app.ini.bak

# Update old Gitea data paths to Forgejo data paths
sed -i 's#/var/lib/gitea#/var/lib/forgejo#g' /etc/forgejo/app.ini

# Forgejo reads its config as the forgejo group; grant group write
chown root:forgejo /etc/forgejo/app.ini && chmod g+w /etc/forgejo/app.ini

# Copy the data directory and hand ownership to the forgejo user
rsync -aHAX --numeric-ids /var/lib/gitea/ /var/lib/forgejo/
chown -R forgejo:forgejo /var/lib/forgejo

شغّل Forgejo وفعّله عند الإقلاع.

# Start Forgejo and enable it at boot
systemctl start forgejo && systemctl enable forgejo

قبل الترقية من v10.0، أفرغ قوائم الانتظار حتى لا تُفقد أي مهام قيد التنفيذ أثناء قفزة الإصدار.

# Flush pending queue items before the version upgrade
forgejo manager flush-queues

الآن رقّ Forgejo v10.0.x إلى الإصدار الحالي عن طريق استبدال الملف الثنائي بـ v15 وإعادة تشغيل الخدمة، باتباع دليل ترقية Forgejo. بعد كلتا القفزتين، شغّل أداة doctor لفحص قاعدة البيانات وإصلاح ما يمكن إصلاحه.

# Check everything; write a log you can read if something is wrong
forgejo doctor check --all --log-file /tmp/doctor.log

اقرأ /tmp/doctor.log قبل تطبيق أي إصلاح تلقائي. استخدم --fix فقط عندما يحدد ناتج أداة doctor إصلاحًا محددًا تفهمه أو عندما تتبع مسار استكشاف أخطاء رسمي.

إذا لم تُبلّغ أداة doctor عن أخطاء حرجة وأدرجت واجهة الويب مستودعاتك، فقد اكتملت عملية الترحيل الأولى.

مسار Docker / الحاويات

إذا كان Gitea يعمل كحاوية، شغّل Forgejo بنفس الطريقة. استخدم صورة Forgejo v10.x كبديل جاهز لصورة Gitea v1.22.x الخاصة بك، مع توجيهها إلى نفس وحدة تخزين البيانات وقاعدة البيانات. تأكد أولًا من أن إصدار Docker لديك 20.10.6 على الأقل. الإصدارات الأقدم تُنتج سلوكًا غير محدد مع حاويات Forgejo.

التفصيلة الوحيدة الخاصة بالحاويات التي تربك الناس: متغيرات البيئة. يحتفظ Forgejo بالبادئة GITEA_ لأغراض التوافق، لكن الوثائق توصي بتمرير كلا البادئتين حتى يصمد إعدادك أمام إصدار مستقبلي من Forgejo يتخلى عن الأسماء القديمة.

# docker-compose.yml (excerpt): pass both prefixes for forward compatibility
environment:
  - GITEA__database__DB_TYPE=postgres
  - FORGEJO__database__DB_TYPE=postgres
  # ...repeat the dual-prefix pattern for every config override you pass

بالنسبة للحاويات rootless، يجب أن تكون البيانات مملوكة للمستخدم 1000 والمجموعة 1000، بما يطابق مستخدم وقت التشغيل الخاص بصورة rootless. بعد بدء تشغيل الحاوية على v10.x، شغّل نفس forgejo doctor check --all من داخل الحاوية، ثم رقّ وسم الصورة إلى إصدار v15 الحالي وأعد التشغيل.

إذا كنت تستخدم Gitea v1.23 أو أحدث

هنا تتوقف الأدلة القياسية، وهنا أيضًا يقف معظم التثبيتات الحالية فعليًا. لا يوجد مسار مباشر مدعوم رسميًا من Gitea v1.23+، لذا فإن كل خيار أدناه إما من مصادر مجتمعية أو يفقد بعض البيانات. قبل تشغيل أي منها، خذ نسخة احتياطية كاملة من مجلد البيانات وقاعدة البيانات، وتأكد من قدرتك على استعادتها. هذه الطرق تعدّل بيانات الإنتاج؛ والنسخة الاحتياطية هي وسيلتك الوحيدة للتراجع.

تختلف الخيارات الثلاثة في المخاطرة وفي مقدار ما تحافظ عليه. اختر الخيار الذي تستطيع قبول مقايضته.

الخيار أ: تخفيض إصدار مخطط SQL / ترقيع الإصدار

أضيق حل بديل يخفّض إصدار مخطط قاعدة البيانات بحيث يعامله Forgejo v10 كقاعدة بيانات من إصدار v1.22.

ملاحظة: لا تعامل تحديث الإصدار كتخفيض كامل بحد ذاته. يجب أن يتطابق إصدار الترحيل المسجّل مع المخطط الفعلي. على Gitea 1.23.x، اختبر التخفيض الكامل على نسخة أولًا وقارن المخطط قبل توجيه Forgejo إليه.

وصف أحد القائمين على صيانة Forgejo كود SQL في Codeberg issue #7638:

-- Downgrade the recorded schema version to the v1.22 baseline (PostgreSQL/MySQL)
UPDATE version SET version=305 WHERE id=1;

بعد هذا، تتبع المسار المدعوم كما لو كنت على v1.22. التحذير المهم: أكد القائم على الصيانة هذا فقط لإصدار Gitea v1.23.1 تحديدًا، وليس كل إصدارات v1.23.x. رقم إصدار المخطط دقيق تمامًا؛ تطبيق قيمة هدف خاطئة على إصدار Gitea خاطئ قد يترك قاعدة البيانات في حالة لا يمكن لأي ترحيل استعادتها منها. هذا خاص بـ PostgreSQL/MySQL، وهو غير مدعوم رسميًا، ولم يُختبر كإجراء عام.

نصيحة: تعيين version=305 مباشرة يتخطى ترحيل 304→305 الذي غيّر طريقة ترميز أسرار TOTP. Codeberg issue #8210 يوثّق أن هذا يفسد المصادقة الثنائية للمستخدمين المتأثرين. الإصلاح هو تعيين الإصدار على 304 والسماح للترحيل بالتشغيل، أو مسح صفوف جدول two_factor حتى يعيد المستخدمون التسجيل. لا تتجاوز هذه الخطوة إذا كان أي حساب يستخدم TOTP.

الخيار ب: نصوص تخفيض SQL المتسلسلة (Gitea 1.24–1.25.2)

بالنسبة للإصدارات بين 1.24 و1.25.2، لا تكفي رقعة إصدار واحدة: انتقل المخطط عبر عدة حالات وسيطة. السكربتات المجتمعية على xlrl/prepare-gitea-migration-to-forgejo تُرجع المخطط عبر الإصدارات الوسيطة إلى v1.22، وبعد ذلك تسلك المسار المدعوم. هذه النصوص هي عمل مجتمعي وليست إجراءً معتمدًا رسميًا، وتستهدف SQLite كحالة أساسية. شغّلها فقط على قاعدة بيانات سبق لك أخذ نسخة احتياطية منها.

الخيار ج: الترحيل عبر API مستودعًا تلو الآخر (Gitea 1.26+ أو أي إصدار)

مسار المستودع/API يحافظ على بيانات Git بأكبر قدر من الموثوقية. اعتمادًا على المصدر والصلاحيات وطريقة الترحيل، قد تتوفر أيضًا بيانات وصفية اختيارية مثل التذاكر وطلبات السحب والوسوم والمعالم والإصدارات وبيانات الويكي والتعليقات، لكن تعامل معها على أنها بذل قصارى الجهد وتحقق منها مستودعًا تلو الآخر. بالنسبة لأرشيف يحتوي على الشيفرة فقط، هذا عادة ما يكون كافيًا؛ أما لخادم يمثل فيه متتبع التذاكر ذاكرة الفريق، فاختبر نقل البيانات الوصفية قبل الالتزام بهذا المسار.

هناك أداتان تجريبيتان تحاولان توفير ترحيل أكثر اكتمالًا لإصدار 1.23+ لكن لكل منهما ثغراتها الخاصة. pacnpal/gitea2forgejo (GitHub) يقوم بعملية تفريغ كامل مع مزامنة عبر API ويتطلب تطابق SECRET_KEY لنقل الحقول المشفرة، لكنه لا ينقل Personal Access Tokens، ولا عدائي Actions، ولا عناوين webhook callback، ولا 2FA. nicoverbruggen/gitea-to-forgejo (GitHub) هي أداة تجريبية قائمة على Podman تنقل المستخدمين والمفاتيح والمؤسسات والمستودعات والمشكلات وطلبات السحب والإصدارات والمرايا، لكنها لا تنقل رموز 2FA، ولا بيانات تشغيل Actions، ولا بيانات وصف حزم OCI المعلّقة. تعامل مع كلتا الأداتين كأدوات تجريبية وتحقق من النتيجة مقابل مصفوفة النقل أدناه.

خلاصة القسم: لا يوجد مسار مباشر مدعوم رسميًا من Gitea 1.23+. اختر الخيار الذي يمكنك تحمل مقايضة فقدان البيانات فيه، وخذ نسخة احتياطية قبل البدء.

الترحيل على خادم جديد أكثر أمانًا، لكنه لا يتجاوز حاجز الإصدار

الخادم الجديد هو المكان الأكثر أمانًا لتجهيز الترحيل والتحقق منه، لكنه ليس مسارًا منفصلًا لتوافق المخطط. إذا كان مصدرك Gitea v1.22 أو أقدم، ثبّت Forgejo v10.0.x على الهدف أولًا، ثم استعد أو انسخ بيانات Gitea إليه، ودع Forgejo يشغل ترحيلات قاعدة البيانات المدعومة، ثم رقّ نسخة Forgejo v10 هذه إلى الإصدار الحالي من Forgejo.

إذا كان مصدرك Gitea v1.23 أو أحدث، فلا تستعد قاعدة بيانات Gitea مباشرة في Forgejo الحالي وتتوقع أن يعمل. لا تزال بحاجة إلى إحدى الطرق غير المدعومة لـ 1.23+ المذكورة أعلاه: تخفيض أو تراجع SQL على مراحل، أو أداة ترحيل مجتمعية، أو ترحيل عبر المستودعات/API. يقلل الخادم الجديد من مخاطر التراجع لأن جهاز Gitea الأصلي يبقى دون تغيير؛ لكنه لا يُلغي الحاجة إلى معالجة عدم تطابق إصدار قاعدة البيانات.

هنا يكمن Forgejo بنقرة واحدة من Cloudzy تطبيق يمكن أن يساعد: استخدمه كنسخة هدف نظيفة، ثم شغّل طريقة الترحيل التي تناسب إصدار Gitea لديك. توفر لك صورة سوق Cloudzy هدف Forgejo جاهزًا على خادم VPS عالي الأداء، حتى تتمكن من التركيز على خطوات الاستعادة والتحقق والتحويل بدلًا من التثبيت الأولي. تبقى خطة الترحيل معتمدة على ما إذا كنت قبل أو بعد حاجز Gitea 1.22.

ما الذي ينتقل وما الذي يجب عليك إعادة فعله

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

أربعة عناصر تتأثر بشدة لأنها تتعطل بصمت أو تؤثر على كل مستخدم، لذا تعامل معها بعناية: يجب على المستخدمين إعادة إنشاء أو تدقيق رموز Personal Access Tokens الخاصة بهم، ويجب عليك إعادة تسجيل عدائي Actions مقابل اسم المضيف الجديد، ويجب عليك حذف فهرس بحث Bleve حتى يُعيد Forgejo بناءه بشكل نظيف، ويجب عليك إعادة كتابة أي uses: المراجع القصيرة في سير عمل Actions لديك إلى عناوين GitHub الكاملة، لأن Forgejo وGitea يسحبان الإجراءات من مرايا منفصلة والمرجع النسبي يشير إلى مكان خاطئ.

نصيحة: إذا كنت تشغّل Gitea وForgejo بالتوازي أثناء الترحيل وكلاهما يشير إلى نفس نسخة Redis، فغيّر Forgejo إلى Redis db=1 قبل البدء. كلاهما يستخدم db=0 افتراضيًا، وإذا تشاركا فيه، فإن Gitea سيستهلك أحداث ترحيل Forgejo ويدمّر قائمة انتظار الترحيل. (blog.mei-home.net documents this exact failure.)

خلاصة القسم: رموز الوصول الشخصية، وعدّاءو Actions، ومفاتيح النشر الخاصة بكل مستودع، وفهرس بحث Bleve، جميعها دائمًا يدوية. جدولها كمهام ترحيل، لا كأفكار لاحقة.

تحقق من نجاح الترحيل

ابدأ بأداة doctor، ثم تحقق من الأرقام، ثم اختبر الأشياء التي يقوم بها المستخدمون فعليًا. تكتشف أداة doctor مشاكل مستوى قاعدة البيانات؛ بينما تكتشف الفحوصات اليدوية مشاكل فقدان البيانات والوصول التي لا تراها الأداة.

1. شغّل forgejo doctor check --all --log-file /tmp/doctor.log، ثم اقرأ السجل قبل إجراء أي تغييرات. استخدم --fix فقط لإصلاح محدد تفهمه.
2. تأكد من أن عدد المستودعات، وأعداد المشكلات وطلبات السحب، وعدد كائنات LFS وحجمها الإجمالي، كلها تطابق أرقامك قبل الترحيل. أي اختلاف هنا يعني أن شيئًا ما لم ينتقل بنجاح.
3. اختبر عملية push وpull عبر SSH. إذا حصل العملاء على عدم تطابق في مفتاح المضيف، فأنت لم تنسخ /etc/ssh/ssh_host_* إلى الخادم الجديد.
4. سجّل الدخول وتأكد من أن 2FA يعمل لحساب يستخدمه. إذا كان TOTP معطلًا، راجع تحذير الخيار A أعلاه.
5. أعد إنشاء رموز الوصول الشخصية، وأعد تسجيل عدّائي Actions، وشغّل سير عمل تجريبيًا.

هناك بعض الأعراض بعد الترحيل لها أسباب معروفة. غياب أيقونة favicon أو الشعار يعني أن أصول العلامة التجارية لا تزال في public/assets/img/ بدلًا من custom/، حيث يتوقعها Forgejo الآن. أخطاء 404 على مسارات الحزم تشير إلى مسارات تخزين مهيأة بشكل خاطئ. فشل Actions برسالة "repository not found" هو uses: مشكلة المرآة (mirror). انتقل إلى استخدام العناوين الكاملة. صفحة فارغة أو خطأ 500 بعد تسجيل الدخول على قاعدة بيانات SQLite تعني أنك دون الحد الأدنى، وهو ما وثائق الترقية وضع عند Forgejo v1.19.3-0.

متى يكون البقاء على Gitea منطقيًا

الترحيل خيار، وليس التزامًا. إذا كنت قد تجاوزت الحاجز بالفعل وكان تعقيد الترحيل يفوق فائدة الحوكمة أو الميزات بالنسبة لوضعك، فإن البقاء على Gitea خيار مشروع. يتم صيانة Gitea بنشاط (عدة إصدارات شهريًا، حاليًا عند v1.26.4)، وتقدم CommitGo خيارات تجارية تشمل Gitea Enterprise وGitea Cloud وشهادة SOC 2 Type 2 للفرق التي تحتاجها.

هناك أيضًا مخاوف بشأن المحطة الوسيطة المنتهية الدعم (EOL) يجب موازنتها بصدق. يتطلب المسار المباشر المدعوم تثبيت Forgejo v10.0 مؤقتًا، وهو إصدار منتهي الدعم منذ أبريل 2025. هذا مقبول كخطوة ترحيل عابرة تترقى منها فورًا، لكن بعض المشغّلين سيعترضون لأسباب تتعلق بالسياسات. بالنسبة لهم، يمكن للترحيل عبر المستودع/API إلى نسخة Forgejo جديدة تجنب هذه المحطة المنتهية الدعم تمامًا، بينما لا يزال إعداد خادم جديد يعتمد على طريقة الترحيل التي تختارها.

إذا كان سبب انتقالك هو نشاط التطوير، فإن البيانات تدعم Forgejo كمشروع أكثر نشاطًا: تحليل أجراه honeypot.net أحصى 3,039 التزامًا (commits) لـForgejo مقابل 1,228 التزامًا لـGitea خلال الفترة من يوليو 2024 إلى مايو 2025، و232 مساهمًا في Forgejo مقابل 153 في Gitea خلال العام المنتهي في مايو 2025. هذه إشارة واحدة من بين عدة إشارات؛ وازنها مقابل مخاطر ترحيلك بدلًا من اعتبارها حاسمة.

خلاصة القسم: الترحيل ليس إلزاميًا. القرار هو تفضيل يتعلق بالحوكمة والنشاط موازَنًا بمخاطر الترحيل، وكلا الخيارين مبرر منطقيًا.

اختر مسارك وخذ نسخة احتياطية أولاً

يتلخص مسار ترحيلك في رقم واحد: إصدار Gitea لديك. على v1.22 أو أقدم، تسلك المسار المدعوم من خطوتين عبر Forgejo v10. على v1.23 أو أحدث، تختار حلًا بديلًا حسب مقدار فقدان البيانات الذي يمكنك قبوله: تخفيض SQL/المخطط، أو نصوص مجتمعية، أو ترحيل عبر المستودع/API، أو ترحيل عبر إعداد خادم جديد. أيًا كان المسار الذي تسلكه، خذ نسخة احتياطية من مجلد البيانات وقاعدة البيانات أولًا، وشغّل forgejo doctor بعد ذلك، وتأكد من أن أعداد المستودعات والتذاكر وLFS تطابق ما بدأت به.

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

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

هل يمكنني الترقية مباشرة من Gitea إلى Forgejo؟

نعم، إذا كنت تشغّل Gitea v1.22 أو أقدم: رقّ مباشرة إلى Forgejo v10.0، ثم رقّ Forgejo v10 إلى الإصدار الحالي. لا، إذا كنت تشغّل Gitea v1.23 أو أحدث. كان Forgejo v10.0 آخر إصدار يدعم ترقية مباشرة شفافة، لذا تحتاج إصدارات Gitea الأحدث إلى حل بديل بدلًا من ذلك.

ما إصدار Gitea المتوافق مع Forgejo؟

لدى Gitea v1.22 وما قبله مسار ترقية مباشر مدعوم إلى Forgejo (حتى Forgejo v10.0، ثم إلى الإصدار الحالي). أما Gitea v1.23 وما بعده فلا يملك مسارًا مباشرًا مدعومًا رسميًا، لأن Forgejo توقف عن دعم الترقيات الشفافة من Gitea v1.23+ اعتبارًا من الإصدارات التي تلت v10.0.

هل يمكنني الترحيل من Gitea 1.26 إلى Forgejo؟

نعم، لكن ليس عبر ترقية مباشرة مدعومة. خياراتك هي الترحيل عبر المستودع/API، حيث يكون سجل Git هو الجزء الموثوق ويجب اختبار البيانات الوصفية مستودعًا تلو الآخر، أو نص ترحيل تجريبي، أو ترحيل عبر إعداد خادم جديد باستخدام إحدى الطرق غير المدعومة لإصدار 1.23+ المذكورة أعلاه. لا يوجد مسار مباشر في المكان نفسه مدعوم رسميًا من Gitea 1.26.

هل تنتقل رموز Personal Access Tokens الخاصة بي؟

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

هل تعمل أعباء عمل Gitea Actions في Forgejo؟

في الغالب نعم، مع إصلاحين مطلوبين. عبء العمل uses: تتعطل المراجع القصيرة لأن Forgejo وGitea يسحبان الإجراءات (actions) من مرايا منفصلة. غيّرها إلى عناوين GitHub الكاملة (على سبيل المثال، uses: https://github.com/sammcj/dotenv-output-action@main). يجب عليك أيضًا إعادة تسجيل عدائي Actions، لأن رموز تسجيلها مرتبطة باسم المضيف القديم.

ماذا عن الترحيل من Gogs إلى Forgejo؟

هذا ترحيل مختلف بمسار مختلف وهو خارج نطاق هذا الدليل. يغطي هذا الدليل الترحيل من Gitea إلى Forgejo تحديدًا؛ أما بالنسبة لمصدر Gogs، فارجع إلى وثائق الترحيل الرسمية لـForgejo للاطلاع على الإجراء الخاص بـGogs.