نشر المقالات إلى GitLab

اربط GitLab مرة واحدة ويمكنك نشر أي مقال من Clevera إلى مشروع GitLab كملف Markdown، جاهز لموقع المستندات، أو docs/ مجلد، أو دليل المشروع. يغطي هذا المقال عملية الربط، واختيار المشروع والمجلد، وشكل الملف، وكيفية عمل التحديثات.

قبل البدء#

• الخطة: النشر إلى GitLab جزء من خطط Pro و Custom. في الخطط المجانية (Free) و Starter، تظهر علامة التبويب نشر عبارة "النشر إلى أدواتك مشمول في خطة Pro". راجع اختيار خطة.
• الدور في Clevera: يمكن لمالك مساحة العمل أو المسؤول فقط ربط أو قطع الاتصال بـ GitLab. بمجرد اتصاله، يمكن لأي شخص لديه صلاحية تعديل مقال أن ينشره.
• GitLab.com فقط: تربط Clevera بـ GitLab.com. خوادم GitLab ذاتية الاستضافة غير مدعومة.
• الدور في GitLab: تعرض Clevera المشاريع التي يمتلك فيها الحساب المرتبط دور مطور (Developer) أو أعلى. للالتزام بفرع افتراضي محمي، يحتاج الحساب عادةً إلى دور مسؤول (Maintainer) (راجع الفروع المحمية).
• مقال: أنت تنشر المقال الذي ينتمي إلى فيديو أو تسجيل. قم بإنشائه أولاً؛ راجع تحويل تسجيل إلى مقال.

لا يستهلك النشر أي أرصدة.

ربط GitLab#

1. افتح عمليات التكامل#

   في الشريط الجانبي، افتح قائمة مساحة العمل واختر عمليات التكامل. ابحث عن GitLab ضمن عمليات التكامل المتاحة (أو علامة التبويب التطوير) وانقر على ربط.

2. سجل الدخول إلى GitLab وامنح الإذن#

   سجل الدخول إلى GitLab.com إذا لم تكن قد فعلت ذلك بالفعل. سيطلب منك GitLab منح Clevera الإذن بالنطاقات التالية:

   نطاق GitLab	السبب
   api	تحتاج واجهة برمجة التطبيقات (API) للملفات في GitLab إلى ذلك لإنشاء وتحديث الملفات
   read_user	لعرض اسم مستخدم GitLab الخاص بك في Clevera
   read_repository	للتحقق مما إذا كان الملف موجوداً بالفعل
   write_repository	لرفع ملف Markdown وصوره

   انقر على منح الإذن.

3. تحقق من الاتصال#

   ستعود إلى عمليات التكامل مع ظهور عبارة "تم ربط GitLab بنجاح بـ" متبوعة باسم مستخدم GitLab الخاص بك. ينتقل GitLab إلى قائمة متصل مع شارة متصل. قبل أن تنشر أي شيء، ستظهر عبارة "لم يتم نشر أي شيء بعد".

نشر مقال#

1. افتح علامة التبويب نشر#

   في المحرر، انقر على مشاركة وافتح علامة التبويب نشر. ضمن انشر المقال، انقر على مربع GitLab تحت جاهز للنشر.

   يتم نشر المقال باللغة التي فتحتها في المحرر. قم بتبديل اللغة في الشريط العلوي أولاً لنشر ترجمة.

2. اختر المشروع والمجلد#

   ضمن أين يذهب، اختر:

   الحقل	ما الذي يجب اختياره	ملاحظات
   مستودع	مشروع GitLab للملف	المشاريع التي تكون فيها مطوراً أو أعلى، مرتبة حسب الأحدث. يتم اختيار الأول لك تلقائياً
   مجلد	مسار مثل docs أو articles/guides	"يتم إنشاء ملف Markdown هنا. اتركه فارغاً لجذر المستودع." يبدأ كـ docs. يتم إنشاء المجلدات غير الموجودة بعد

   تتذكر Clevera ما اخترته للمرة القادمة.

   

3. نشر#

   انقر على نشر إلى GitLab. سترى "جاري البحث عن نسخة موجودة في GitLab"، ثم جاري كتابة الصفحة. عند الانتهاء، سترى "تم النشر إلى GitLab". انقر على فتح في GitLab لرؤية الملف.

   يمكنك إغلاق نافذة المشاركة أثناء العملية؛ سيخبرك إشعار عند اكتمالها.

أين يذهب الملف#

• الفرع: الفرع الافتراضي للمشروع (عادةً main). تلتزم Clevera مباشرة به؛ لا تفتح طلب دمج ولا يمكنك اختيار فرع آخر.
• اسم الملف: العنوان بأحرف صغيرة، مع تحويل المسافات إلى واصلات، وينتهي بـ .md. "Create your first invoice" تصبح create-your-first-invoice.md. العناوين بلغات أخرى أو التي تحتوي على علامات تشكيل تُكتب بحروف لاتينية أولاً ("Créer une facture" تصبح creer-une-facture.md). العنوان الذي لا يمكن تهجئته، مثل المكون من رموز تعبيرية فقط، يحصل على رمز ثابت قصير بدلاً من ذلك (article- زائد 8 أحرف). يتم قص الأسماء عند 80 حرفاً.
• الصور: تذهب لقطات شاشة المقال إلى assets/<file name>/ داخل نفس المجلد، في نفس الالتزام.
• رسالة الالتزام: Add article: <title>، أو Update article: <title> عند تحديث ملف موجود.
• مؤلف الالتزام: حساب GitLab الذي ربط التكامل.

الفروع المحمية#

يحمي GitLab الفرع الافتراضي افتراضياً، وعادةً ما يمكن للمسؤولين فقط الدفع إليه. إذا كان الحساب المرتبط مطوراً، يتم رفض الالتزام بعبارة "GitLab رفض الالتزام: تحتاج إلى صلاحية مطور أو أعلى، ويجب ألا يكون الفرع محمياً." إما امنح ذلك الحساب دور مسؤول، أو اسمح للمطورين بالدفع ضمن الإعدادات ← مستودع ← الفروع المحمية في المشروع.

كيف يبدو الملف#

تكتب Clevera ملف Markdown الذي يعرضه GitLab، مع كتلة بيانات وصفية قصيرة في الأعلى:

---
title: "Create your first invoice"
created_at: "2026-10-12T09:30:00+00:00"
updated_at: "2026-10-12T10:05:00+00:00"
source: "Clevera"
---

الفيديو الذي جاء منه المقال لا يُضاف إلى الملف. فيديو Clevera الموضوع داخل المقال يصبح رابطاً لمشغله، فقط عندما يكون رابط مشاركة ذلك الفيديو مفعلاً. راجع عرض فيديو في مقال.

الصور#

يتم الالتزام بلقطات الشاشة في مشروعك بجوار الملف، وترتبط بها Markdown عبر مسار نسبي (assets/<file name>/…). تستمر في العمل بدون Clevera، وفي مشروع خاص تظل خاصة مثل بقية المشروع.

ملف الفيديو الذي حملته إلى المقال لا يتم الالتزام به. يظل رابطاً لـ Clevera تنتهي صلاحيته بعد فترة؛ انشر مرة أخرى لتجديده.

استخدامه مع موقع مستندات#

إذا كان GitLab Pages أو مولد مواقع ثابتة آخر (مثل MkDocs أو Docusaurus أو Hugo) يبني مستنداتك من المشروع، وجه مجلد إلى المجلد الذي يقرأ منه. كل عملية نشر هي التزام عادي، لذا يعمل خط الأنابيب الخاص بك كالمعتاد. تقرأ معظم المولدات title من البيانات الوصفية وتتجاهل الحقول التي لا تعرفها.

تحديث مقال نشرته بالفعل#

النشر يسير في اتجاه واحد فقط. التعديلات التي تجريها في Clevera تظل في Clevera حتى تنشر مرة أخرى، والتغييرات التي تتم على الملف في GitLab لا تعود أبداً إلى Clevera.

عندما تنشر إلى نفس المشروع والمجلد، تجد Clevera الملف بنفس الاسم وتظهر "هذا المقال موجود بالفعل في GitLab." انقر على عرضه لفتح الملف الموجود، ثم اختر:

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

قطع الاتصال بـ GitLab#

1. افتح عمليات التكامل، انقر على قائمة ⋯ في صف GitLab واختر قطع الاتصال (أو انقر على GitLab ثم قطع الاتصال).
2. أكد ذلك. "لا يمكنك النشر إليه من المحرر بعد الآن. المحتوى الذي نشرته بالفعل يبقى في GitLab."

قطع الاتصال يحذف رموز Clevera. لإلغاء وصول Clevera على GitLab أيضاً، افتح قائمة الصورة الرمزية في GitLab ← تعديل الملف الشخصي ← التطبيقات، ابحث عن Clevera ضمن التطبيقات المصرح لها وانقر على إلغاء.

استكشاف الأخطاء وإصلاحها#

ذات صلة#