انقلوا مستودعاتكم. احتفظوا بتاريخها.
تستورد PearlGit من أي مستودع Git بعيد — GitHub أو GitLab أو Bitbucket أو Git خام عبر SSH/HTTPS. تكتمل معظم ترحيلات الفريق الواحد في فترة ما بعد الظهر. وللأكبر منها نُجري الاستيراد بالنيابة عنكم.
مصفوفة المصادر.
ما يُنقل بحسب المصدر. ✓ = مُرحَّل تلقائياً؛ ◐ = مُرحَّل مع التحفّظات المذكورة أدناه؛ ✗ = يدوي.
| المصدر | المستودعات وتاريخها | المسائل | طلبات السحب | الإصدارات | الويكي | LFS |
|---|---|---|---|---|---|---|
| GitHub | ✓ | ✓ | ◐ | ✓ | ✓ | ✓ |
| GitLab | ✓ | ✓ | ◐ | ✓ | ✓ | ✓ |
| Bitbucket Cloud | ✓ | ✓ | ◐ | ✓ | ◐ | ✓ |
| Bitbucket Server | ✓ | ✓ | ◐ | ✓ | ◐ | ✓ |
| Git خام (أي مستودع بعيد) | ✓ | — | — | — | — | ✓ |
تحفّظ طلب السحب (◐): تنتقل خيوط التعليقات، وتاريخ المراجعة، وبيانات الدمج؛ وقد لا تتمركز بعض مواقع تعليقات المراجعة داخل الفروق المعاد كتابتها منذ أمد طويل بدقّة. تحفّظ ويكي Bitbucket: صياغة الويكي لديهم تختلف بما يكفي لجعل بعض الصفحات بحاجة إلى إصلاح يدوي بعد الاستيراد.
المسار في أربع خطوات.
جهّز بيانات اعتماد المصدر
رمز قراءة من المضيف المصدر مع صلاحية الوصول إلى المستودعات التي تودّون ترحيلها. تستخدمه PearlGit مرّة واحدة وتتخلّص منه بعد اكتمال الاستيراد.
وجّه PearlGit إلى المصدر
من مستودع جديد ← ترحيل، الصِق رابط المصدر، والصِق الرمز، واختر الإنتاجات المراد تضمينها (المسائل، وطلبات السحب، والإصدارات، والويكي، وLFS). للترحيلات على نطاق المنظّمة، استخدم أداة الاستيراد الإدارية.
تحقّق
افحص عيّنة من المستودعات: تطابق SHA الإيداعات، وانتظام الفروع والوسوم، وبقاء الإيداعات الموقَّعة مُتحقَّقاً منها، وإمكانية الوصول إلى كائنات LFS. تُصدر مهمّة الاستيراد في PearlGit بياناً (manifest) لمقارنته بالمصدر.
التحويل النهائي
حوّل إعدادات CI وروابط ويب النشر إلى الأصل الجديد، وحدّث DNS أو الروابط المخصَّصة إن وُجدت، وألزِم فريقكم بإعادة الاستنساخ. يبقى المضيف القديم نسخةً احتياطية حتى تحذفوه.
ما يُنقل تلقائياً
- جميع SHA الإيداعات (الهاش نفسه؛ لا إعادة كتابة)
- جميع الفروع والوسوم، بما فيها الوسوم المُعلَّقة
- تبقى الإيداعات الموقَّعة مُتحقَّقاً منها (تُحفظ توقيعات GPG)
- كائنات Git-LFS مع مؤشّراتها سليمة
- المسائل والتسميات (حيث يدعمها المصدر)
- فروق طلبات السحب وتعليقاتها وحالة الدمج
- الإصدارات بما فيها ملاحظات الإصدار والثنائيات المرفقة
- صفحات الويكي (Markdown / reStructuredText / AsciiDoc)
ما يتطلّب عملاً يدوياً
- روابط ربط الويب — وجّهوها إلى الأصل الجديد
- ملفّات إعداد CI (ما لم تكن YAML متوافقة مع Actions)
- مفاتيح النشر — أعيدوا توليدها على PearlGit وبدّلوها لدى هدف النشر
- رموز الوصول الشخصية — أعيدوا إصدارها على PearlGit
- الخدمات الخارجية (إشعارات Slack، وشارات الحالة) — أعيدوا إعدادها
- هيكل الفِرق/الصلاحيات — يعيد المديرون إنشاءه عبر واجهة الفِرق في PearlGit
- قواعد حماية الفروع — إعادة إنشاء صريحة (نموذج كلّ مضيف مختلف قليلاً)
للترحيلات الأكبر.
إن كنتم تنقلون أكثر من 100 مستودع، أو ضوابط وصول تخصّ عدّة فرق، أو بيانات ذات أهمّية امتثالية، فسنُجري الترحيل معكم بدلاً من ترككم تقودون واجهة الاستيراد.
كيف يبدو ذلك:
- مكالمة ترحيل لتخطيط هيكل مصدركم على PearlGit (منظّمة ← منظّمة، فريق ← فريق، مستودع ← مستودع).
- استيراد تجريبي إلى منظّمة اختبار للتحقّق قبل التحويل النهائي.
- نافذة تحويل ننسّقها حول جدول إصداركم، مع إبقاء المضيف المصدر للقراءة فقط للرجوع إليه.
- نافذة دعم لـ 30 يوماً بعد الترحيل لاكتشاف الأمور الصغيرة التي تظهر دائماً لاحقاً.
يُعدّ ذلك جزءاً قياسياً من تهيئة Team وEnterprise — دون بند خدمات احترافية منفصل.
الترحيل خارجها لاحقاً.
الحاشية الصريحة: إن لم تعد PearlGit مناسبة لكم يوماً، فبإمكانكم المغادرة بتكلفة زهيدة. لأنّنا Git خام في الأساس — لا بروتوكول خاصّ، ولا صياغة بيانات وصفية غامضة — تنسخ مستودعاتكم إلى أي مستضيف Git آخر دون ترجمة. تكلفة الخروج تقريباً هي تكلفة تنسيق فريقكم، لا مشروع إعادة بناء منصّة.
هذا هو خيار التصميم الذي يستحقّ الثقة التي نطلبها. نُفضّل عملاء قادرين على المغادرة ولا يفعلون، على عملاء غير قادرين.
مستعدّون للنقل؟
أرسلوا إلينا وصفاً تقريبياً لإعدادكم الحالي (المضيف، وعدد المستودعات، وأي شيء غير معتاد) ونعود إليكم بخطّة ترحيل وعرض سعر.