DevOps on kenji.blog

【أوامر Git】الفرق بين rebase و merge، والاستخدام الصحيح في العمل الفعلي

Sun, 13 Sep 2026 09:00:00 +0900

1. مقدمة: لماذا يمثل الاختيار بين “merge و rebase” تحدياً مستمراً؟

Git هو نظام تحكم في الإصدارات لا غنى عنه في تطوير البرمجيات الحديثة. عندما يقوم العديد من المطورين بتعديل قاعدة الكود في وقت واحد، فإن نموذج الفروع القوي في Git يظهر فاعليته. ومع ذلك، في تطوير الفرق، يمثل النقاش حول “أيهما يجب استخدامه: merge أو rebase” موضوعاً يؤرق دائماً المطورين، من المبتدئين إلى الخبراء.

في هذا المقال، سنتعمق في الفروق بين آليات git merge و git rebase، من خلال استكشاف البنية الداخلية لـ Git، مثل الرسم البياني الموجه غير الدوري (DAG) والخصائص الرياضية لتجزئة الالتزام (Commit Hash). وبعد ذلك، سنشرح بالتفصيل كيفية التمييز بينهما في العمل الفعلي، مع تقديم أمثلة على سير العمل (Workflows). بدلاً من مجرد سرد الأوامر، فإن فهم العمليات الحسابية التي يقوم بها Git في الخلفية سيزيل الخوف من التعارضات (Conflicts)، مما يتيح لك بناء سجل تاريخي نظيف وقابل للتتبع.

2. البنية الداخلية لـ Git: تجزئة الالتزام ونموذج الكائنات

لفهم كيف يقوم Git بدمج السجل التاريخي، يجب أن نعرف أولاً كيف يخزن Git البيانات. لا يقوم Git فقط بحفظ اختلافات (Patches) تغييرات الملفات، بل يحتفظ بلقطة (Snapshot) لنظام الملفات بأكمله في نقطة زمنية معينة.

2.1 الخصائص التشفيرية لتجزئة الالتزام (Commit Hash)

يتم تعريف كل التزام (Commit) في Git بشكل فريد بواسطة سلسلة من 40 حرفاً سداسياً عشرياً (Hexadecimal)، يتم حسابها بناءً على محتواه باستخدام دالة التجزئة SHA-1 (Secure Hash Algorithm 1). يتكون كائن الالتزام من العناصر التالية:

مؤشر لكائن Tree: لقطة من هيكل الدليل والملفات (Blob) في تلك النقطة.
مؤشر للالتزام الأب (Parent Commit): قيمة تجزئة واحدة أو أكثر للالتزامات الآباء (الالتزام الأول لا يحتوي على أب، والتزام الدمج يحتوي على أبوين أو أكثر).
معلومات المؤلف (Author): الشخص الذي كتب الكود والوقت.
معلومات الملتزم (Committer): الشخص الذي أنشأ أو طبق الالتزام والوقت.
رسالة الالتزام (Commit Message): نص يوضح القصد من التغيير.

رياضياً، تُعرّف قيمة التجزئة $H(C)$ لكائن الالتزام $C$ على النحو التالي:

$$ H(C) = \text{SHA-1}( \text{tree} \parallel \text{parent} \parallel \text{author} \parallel \text{committer} \parallel \text{message} ) $$

هنا، تمثل $\parallel$ دمج (Concatenation) البيانات. نظراً لخصائص دالة التجزئة، فإن تغيير حرف واحد فقط في رسالة الالتزام، أو حتى وجود التزام أب مختلف، سيؤدي إلى إنشاء قيمة تجزئة مختلفة تماماً. وهذا يعني أن الالتزام غير قابل للتغيير (Immutable). عندما يقال إن rebase “يعيد كتابة السجل التاريخي”، فهذا يعني فعلياً أنه “ينشئ التزامات جديدة بمحتوى مشابه ولكن بقيم تجزئة مختلفة”.

حجم مساحة التجزئة هو $2^{160}$، ويمكن تقريب احتمال $P$ لحدوث تصادم (Collision) (أي أن يكون لالتزامين مختلفين نفس قيمة التجزئة) باستخدام نظرية مفارقة عيد الميلاد (Birthday Paradox) على النحو التالي (حيث $n$ هو عدد الالتزامات):

$$ P(\text{collision}) \approx 1 - \exp\left(-\frac{n^2}{2 \times 2^{160}}\right) $$

هذا الاحتمال منخفض للغاية، وعملياً من شبه المستحيل أن تتصادم تجزئة التزامات Git.

3. نظرية الرسومات البيانية و DAG: النموذج الرياضي لسجل Git

يُنمذج السجل التاريخي لالتزامات Git على أنه “رسم بياني موجه غير دوري” (Directed Acyclic Graph, DAG) في نظرية الرسومات البيانية.

3.1 ما هو DAG (الرسم البياني الموجه غير الدوري)؟

في الرسم البياني $G = (V, E)$، تمثل $V$ مجموعة الالتزامات (العُقد - Vertices)، وتمثل $E$ مجموعة الحواف الموجهة (Directed Edges) التي تشير إلى علاقات الآباء والأبناء بين الالتزامات. في Git، يتجه اتجاه الحافة من “الالتزام الابن إلى الالتزام الأب”. هذا لأن الالتزام الجديد يحتفظ بمؤشر إلى الالتزام السابق.

graph BT
A["الالتزام A (الأولي)"]
B["الالتزام B"]
C["الالتزام C (الرئيسي)"]
D["الالتزام D (ميزة)"]
E["الالتزام E (دمج)"]
B --> A
C --> B
D --> B
E --> C
E --> D

أهم ميزة لـ DAG هي “عدم وجود دورات (Cycles)”. بفضل هذا، فإن الخوارزمية التي تتتبع السجل التاريخي للوراء لا تقع في حلقة مفرغة، وتصل بالتأكيد إلى النهاية (الالتزام الأولي).

3.2 الفرز الطوبولوجي وترتيب السجل

عند عرض السجل التاريخي باستخدام أوامر مثل git log، يتم ترتيب DAG كقائمة أحادية البعد بواسطة خوارزمية الفرز الطوبولوجي (Topological Sort). لأي حافة موجهة $u \to v$ في DAG (حيث $u$ هو ابن $v$)، يتم ترتيبها بحيث يظهر $u$ قبل $v$ في القائمة.

4. آليات git merge وأنواعها

الأمر الأساسي لدمج التغييرات من الفروع هو git merge. ومع ذلك، بناءً على الحالة الحالية، يختار Git تلقائياً استراتيجية دمج مختلفة.

4.1 دمج التقديم السريع (Fast-Forward) (–ff)

إذا كان الفرع الوجهة (مثال: main) هو السلف المباشر للفرع المصدر (مثال: feature)، يقوم Git بتنفيذ دمج “التقديم السريع (Fast-Forward)”. هذه العملية لا تُنشئ التزاماً جديداً، بل مجرد تحريك مؤشر الفرع للأمام.

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
merge feature

يحافظ دمج Fast-Forward على السجل التاريخي في خط مستقيم، ولكن من عيوبه فقدان السياق حول “أي مجموعة من الالتزامات تمثل تطوير ميزة (feature) واحدة”.

4.2 الدمج بدون التقديم السريع (Non-Fast-Forward) (–no-ff)

عند تحديد git merge --no-ff صراحةً، حتى وإن كان الموقف يسمح بـ Fast-Forward، يتم دائماً إنشاء “التزام دمج (Merge Commit)” جديد. التزام الدمج هو التزام خاص يمتلك أبوين.

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
commit id: "العمل الرئيسي 1"
merge feature type: NORMAL

ميزة هذه الطريقة هي أن وجود وتاريخ فرع الميزة يبقى بوضوح على DAG. عند حدوث مشكلة، يمكن التراجع بأمان عن الميزة بأكملها دفعة واحدة عن طريق تنفيذ git revert -m 1 <تجزئة التزام الدمج>.

4.3 خوارزمية الدمج ثلاثي الاتجاهات (3-Way Merge)

إذا كان لدى كل من الفرع الوجهة والفرع المصدر التزامات خاصة بهما، ينفذ Git دمجاً ثلاثي الاتجاهات. في هذه الحالة، يبحث Git في DAG للعثور على “أدنى سلف مشترك (Lowest Common Ancestor, LCA)” للفرعين.

التعقيد الزمني $T_{\text{LCA}}$ لخوارزمية العثور على LCA يمكن تنفيذه في وقت خطي بالنسبة لعدد العُقد $|V|$ وعدد الحواف $|E|$:

$$ T_{\text{LCA}} = \mathcal{O}(|V| + |E|) $$

يقارن Git بين ثلاثة أشياء: “حالة LCA”، “حالة الفرع الحالي”، و"حالة الفرع الآخر"، وإذا لم تتعارض التغييرات، يقوم تلقائياً بإنشاء التزام دمج.

5. آلية git rebase وإعادة بناء السجل التاريخي

بينما يقوم git merge بـ “دمج” السجل، يقوم git rebase بـ “إعادة بناء (إعادة ربط)” السجل.

5.1 ما يحدث خلف كواليس Rebase

عندما تقوم بإعادة ربط (Rebase) فرع feature بفرع main (باستخدام git rebase main)، تكون العمليات الداخلية كما يلي:

إيجاد السلف المشترك (LCA) لفرعي feature و main.
حفظ الفروقات (Diffs) من LCA إلى طرف فرع feature في منطقة مؤقتة.
نقل مؤشر فرع feature إلى طرف فرع main.
تطبيق الفروقات المحفوظة تباعاً واحداً تلو الآخر (Cherry-Pick) فوق الأساس الجديد (طرف main)، وإنشاء التزامات جديدة.

graph TD
A["الالتزام A"] --> B["الالتزام B"]
B --> C["الالتزام C (الرئيسي)"]
B --> D["الالتزام D (الميزة القديمة)"]
D -.-> E["الالتزام 'D (الميزة الجديدة)"]
C --> E
style D stroke-dasharray: 5 5, fill: #f9f9f9, color: #999

النقطة المهمة هنا هي أن الالتزام $'D$ الناتج عن إعادة الربط له تجزئة مختلفة تماماً عن الالتزام الأصلي $D$، لأنه يمتلك التزاماً أباً مختلفاً (راجع تعريف دالة التجزئة $H(C)$ المذكور سابقاً).

5.2 إعادة الربط التفاعلية (Interactive Rebase)

يتيح لك استخدام git rebase -i (أو --interactive) التلاعب بالسجل التاريخي للالتزامات كما تشاء. إنها الأداة الأقوى لترتيب السجل المحلي.

pick: احتفاظ بالالتزام كما هو.
reword: تعديل رسالة الالتزام فقط.
edit: الإيقاف المؤقت لتعديل محتوى الالتزام.
squash: دمج هذا الالتزام مع الالتزام السابق ودمج الرسائل معاً.
fixup: مثل squash ولكن مع تجاهل رسالة هذا الالتزام.
drop: حذف الالتزام تماماً.

من الناحية الرياضية، إذا كان هناك $N$ من الالتزامات في فرع ما، فإن المتغيرات (التباديل) الممكنة $P$ للسجل الخطي التي يمكن إنشاؤها عن طريق تغيير ترتيب إعادة الربط هي كما يلي:

$$ P = N! $$

يمنح Git المطورين حرية اختيار من بين $N!$ طريقة، مما يتيح إبقاء السجل التاريخي منطقياً وجميلاً.

6. القاعدة الذهبية لإعادة الربط (The Golden Rule of Rebase)

بالرغم من قوة rebase الهائلة، إلا أن هناك قاعدة واحدة مطلقة.

“يجب ألا تقوم أبداً بإعادة ربط (Rebase) السجل التاريخي العام (Public History).” (Never rebase public history)

6.1 لماذا لا يجب إعادة ربط السجل العام؟

Git هو نظام لا مركزي. التزاماتك التي تم دفعها إلى origin/main تم استنساخها (Cloned) بالفعل في المستودعات المحلية للمطورين الآخرين. ماذا يحدث إذا قمت بإعادة ربط التزامات تم دفعها بالفعل، وأعدت كتابة السجل التاريخي، ثم قمت بالكتابة فوقه بالقوة باستخدام git push --force؟

سوف يتفرع DAG الموجود في أجهزة المطورين الآخرين بشكل جذري عن DAG الموجود في المستودع البعيد (Remote). عندما يقوم المطورون الآخرون بتشغيل git pull، سيحاول Git دمج مجموعات من الالتزامات ذات تواريخ مختلفة بالقوة، مما يؤدي إلى حدوث عدد هائل من التعارضات والتزامات مكررة (التزامات لها نفس التغييرات ولكن بقيم تجزئة مختلفة)، وستسود الفوضى في المستودع.

القاعدة الذهبية هي إجراء إعادة الربط (Rebase) “فقط على الفروع المحلية التي لم تشاركها بعد مع أي شخص”.

7. حل التعارضات (Conflicts) و git rebase –continue

عندما يقوم عدة أشخاص بتعديل نفس الجزء من نفس الملف، يحدث تعارض (Conflict). تختلف عملية حل التعارضات بين merge و rebase.

7.1 حل التعارضات في Merge

في حالة git merge، يحدث حل التعارضات مرة واحدة فقط. قبل إنشاء التزام الدمج النهائي مباشرة، تقوم بتصحيح جميع أجزاء التعارض دفعة واحدة.

7.2 حل التعارضات في Rebase

في حالة git rebase، نظراً لطبيعته في إعادة تطبيق الالتزامات واحداً تلو الآخر، من الممكن حدوث تعارض في كل التزام.

عندما يحدث تعارض أثناء إعادة الربط، يقوم Git بإيقاف العملية مؤقتاً. تسلسل الحل هو كما يلي:

افتح محرر نصوص أو بيئة تطوير متكاملة (IDE مثل VS Code)، وقم بتصحيح علامات التعارض (<<<<<<< و ====== و >>>>>>>) يدوياً.
أضف الملفات المصححة إلى الفهرس (Index):
1

git add <الملف المعدل>
لا تقم بإنشاء التزام، بل استأنف عملية إعادة الربط:
1

git rebase --continue

إذا كنت ترغب في إلغاء عملية إعادة الربط نفسها والعودة إلى الحالة الأصلية، فقم بتنفيذ الأمر التالي:

1

git rebase --abort

(※ إذا لم تكن هناك حاجة لحل التعارض وأردت تخطي هذا الالتزام بالكامل، استخدم git rebase --skip)

8. الاستخدام الصحيح في العمل الفعلي (تطبيق سير العمل)

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

8.1 [السيناريو 1] ترتيب سجل العمل المحلي (استخدام Rebase)

لنفترض أنك تعمل على فرع ميزة (feature)، وتراكمت لديك الكثير من الالتزامات الصغيرة (مثل “تصحيح خطأ مطبعي” أو “حفظ مؤقت”). قبل فتح طلب سحب (Pull Request - PR)، استخدم إعادة الربط التفاعلية لترتيب هذه الالتزامات في وحدات ذات معنى.

1
2
3


# نفذ هذا أثناء تواجدك في فرع feature
git rebase -i HEAD~5
# (سيتم فتح المحرر، استخدم squash و fixup لتنظيف السجل)

بذلك، يمكنك إنشاء سجل التزامات جميل ومفهوم يسهل على المراجعين (Reviewers) فهم نواياك.

8.2 [السيناريو 2] مواكبة أحدث فرع main (استخدام Rebase)

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

1
2
3
4
5


# الحصول على أحدث المعلومات لـ main
git fetch origin

# نقل فرع feature فوق أحدث main
git rebase origin/main

هذا يجعل السجل التاريخي مستقيماً، مما يمنع التعارضات عند الدمج لاحقاً. كما يمنع إنشاء التزامات دمج غير ضرورية (“Merge branch ‘main’ into feature”).

8.3 [السيناريو 3] دمج ميزة مكتملة (استخدام Merge)

اكتمل التطوير في فرع feature، وحان وقت دمجها في فرع main. هنا نستخدم git merge --no-ff (وهذا يعادل اختيار “Create a merge commit” في Pull Request على منصات مثل GitHub).

1
2
3


git checkout main
git merge --no-ff feature -m "دمج ميزة: تنفيذ ميزة تسجيل دخول المستخدم"
git push origin main

هذا يترك نقطة التقاء تاريخية (التزام دمج) على DAG لفرع main تفيد بأنه “هنا تم دمج ميزة واحدة”. عند مراجعة السجل لاحقاً، سيكون من الأسهل تتبع الكود حسب الميزة (Feature).

9. الخلاصة (ملخص)

في استخدام Git، إن الأساليب المتطرفة مثل “إنجاز كل شيء باستخدام Merge” أو “جعل كل شيء مستقيماً باستخدام Rebase” لها مزاياها وعيوبها.

أفضل ممارسة في العمل الفعلي هي النهج الهجين (Hybrid): “ترتيب السجل الخاص المحلي بشكل جميل باستخدام rebase، والاحتفاظ بسياق السجل العام المتكامل باستخدام merge –no-ff”.

محلياً (مساحة العمل الشخصية): استخدم rebase لإزالة الالتزامات غير الضرورية، ومواكبة أحدث خط رئيسي، والحفاظ على سجل خطي.
عالمياً (مساحة العمل المشتركة): استخدم merge --no-ff لتسجيل وجود فرع الميزة كالتزام دمج على DAG، مما يسهل عمليات التراجع (Revert) والتتبع.

من خلال فهم الخلفية المعمارية والرياضية مثل هيكل DAG وآليات دوال التجزئة، ترتقي أوامر Git من مجرد حفظ عن ظهر قلب إلى “تصميم مقصود للسجل التاريخي”. بالالتزام بالقاعدة الذهبية لإعادة الربط واختيار الأوامر المثلى وفقاً للموقف، يمكنك بناء سجل التزامات نظيف سهل القراءة والصيانة للفريق بأكمله.

إعداد مسار CI/CD لمشاريع C++ باستخدام GitHub Actions

Sat, 12 Sep 2026 18:00:00 +0900

إعداد مسار CI/CD لمشاريع C++ باستخدام GitHub Actions: الدليل الشامل

في نموذج تطوير البرمجيات الحديث، يعتبر التكامل المستمر (Continuous Integration: CI) والتسليم/النشر المستمر (Continuous Delivery/Deployment: CD) عنصرين أساسيين للحفاظ على عملية تطوير رشيقة وبرمجيات عالية الجودة. مع وجود العديد من لغات البرمجة، فإن إعداد مسار CI/CD في C++ يأتي مع صعوبات وتعقيدات فريدة مقارنة باللغات الأخرى (مثل Python، JavaScript، Go، إلخ).

في هذه المقالة، سنشرح بتفصيل شديد كيفية بناء مسار CI/CD قوي وعملي لمشاريع C++ من الصفر باستخدام GitHub Actions. سنغطي جميع التقنيات العملية، بدءًا من البناء المصفوفي (Matrix Build) عبر المنصات المتعددة (Windows، Linux، macOS)، دمج نظام البناء باستخدام CMake، الاختبار الآلي باستخدام CTest، أتمتة التحليل الثابت والديناميكي، قياس تغطية الكود، وحتى التسليم التلقائي للثنائيات المجمّعة عبر إصدارات جيتهاب (GitHub Releases).

1. أهمية CI/CD في مشاريع C++ والتحديات الخاصة بها

في تطوير تطبيقات الويب أو باستخدام لغات السكربت، غالباً ما يكون الاختبار والبناء على حاوية Docker واحدة كافياً. ومع ذلك، فإن C++ هي لغة تُترجم محليًا (natively compiled) وتعتمد بشكل كبير على معمارية الأجهزة ونظام التشغيل في بيئة التنفيذ.

عند تقديم CI/CD إلى مشاريع C++، فإن التحديات الرئيسية التي نواجهها هي كالتالي:

تنوع المنصات: تختلف واجهات برمجة التطبيقات (مثل Windows API، POSIX، إلخ) باختلاف أنظمة التشغيل مثل Windows وLinux وmacOS. من الشائع جدًا أن يعمل الكود في بيئة التطوير المحلية للمطور (مثل macOS) ولكنه يواجه أخطاء ترجمة (Compile Errors) على Linux أو Windows.
اختلافات المترجمات (Compilers): المترجمات الرئيسية مثل Microsoft Visual C++ (MSVC) وGNU Compiler Collection (GCC) وClang تختلف في درجة تنفيذها وتفسيرها لمعايير C++ (C++17، C++20، C++23) وصرامة تحذيراتها.
وقت البناء: في مشاريع C++ الكبيرة، ليس من النادر أن يستغرق البناء من عشرات الدقائق إلى عدة ساعات. تتطلب بيئة CI استراتيجيات تخزين مؤقت (Caching) وتوازي (Parallelization) للبناء بكفاءة باستخدام موارد حوسبة محدودة.
إدارة التبعيات: لا تمتلك C++ مدير حزم قياسي مطلق مثل npm أو pip. من الضروري حل المكتبات بشكل صحيح في كل مرة على بيئة CI باستخدام أدوات مثل vcpkg، Conan، أو FetchContent في CMake.
إدارة الذاكرة والسلوك غير المحدد: نظرًا لوجود عمليات المؤشرات وإدارة الذاكرة اليدوية، فمن الضروري أتمتة الكشف عن تسرب الذاكرة والسلوك غير المحدد (Undefined Behavior) بالإضافة إلى اختبار المنطق العادي.

لحل هذه التحديات، تُعد GitHub Actions الحل الأمثل حيث يمكنها توفير أجهزة افتراضية لأنظمة تشغيل مختلفة عند الطلب، وتحديد مسارات العمل المعقدة من خلال الكود (Configuration as Code).

2. نظرة عامة على بنية مسار CI/CD

دعونا نتصور الصورة الكاملة لمسار CI/CD الذي سنقوم ببنائه. يوضح مخطط تسلسل Mermaid أدناه سير العمل من دفع الكود (Push) إلى الإصدار (Release).

sequenceDiagram
participant Dev as "المطور"
participant Repo as "مستودع GitHub"
participant Action as "GitHub Actions CI/CD"
participant Rel as "إصدارات GitHub"
Dev->>Repo: "دفع الفرع / فتح PR"
Repo->>Action: "بدء تشغيل مسار CI"
activate Action
Action->>Action: "فحص الكود والتحليل الثابت (Clang-Tidy)"
rect rgb(200, 220, 240)
note right of Action: "بناء مصفوفي متعدد المنصات"
Action->>Action: "البناء على Ubuntu (GCC/Clang)"
Action->>Action: "البناء على Windows (MSVC)"
Action->>Action: "البناء على macOS (Apple Clang)"
end
Action->>Action: "تشغيل CTest (مع ASAN/UBSAN)"
Action->>Action: "إنشاء تقرير التغطية"
alt "إذا تم دفع علامة (مثال، v1.0.0)"
Action->>Action: "تغليف الثنائيات مع CPack"
Action->>Rel: "رفع ZIP/Tarball إلى الإصدار"
end
deactivate Action
Repo-->>Dev: "الإبلاغ عن حالة CI (نجاح/فشل)"

في هذه البنية، نوفر ملاحظات سريعة (التحليل الثابت والبناء والاختبار) في مرحلة طلب السحب (Pull Request)، ونقوم بتغليف وتوزيع المخرجات عند إضافة علامة الإصدار (Version Tag).

3. إعداد المشروع باستخدام Modern CMake

أساس أي مسار CI ممتاز هو نظام بناء قوي. سنستخدم CMake، والذي يعد المعيار الفعلي (De facto standard) في C++. هنا، نعتمد نهجًا موجهًا نحو الأهداف (Target-oriented) يُعرف باسم “Modern CMake”.

نفترض أن هيكل دليل المشروع هو كالتالي:

1
2
3
4
5
6
7
8
9


my_cpp_project/
├── CMakeLists.txt
├── src/
│ ├── main.cpp
│ ├── calculator.cpp
│ └── calculator.h
└── tests/
 ├── CMakeLists.txt
 └── test_calculator.cpp

مثال على إعدادات CMakeLists.txt في الجذر:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


cmake_minimum_required(VERSION 3.20)
project(MyCppProject VERSION 1.0.0 LANGUAGES CXX)

# إعداد معيار C++
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF) # تعطيل الامتدادات الخاصة بالمترجم لزيادة قابلية النقل

# صرامة تحذيرات المترجم
function(set_project_warnings target_name)
 if(MSVC)
 target_compile_options(${target_name} PRIVATE /W4 /WX)
 else()
 target_compile_options(${target_name} PRIVATE -Wall -Wextra -Wpedantic -Werror)
 endif()
endfunction()

# إنشاء هدف المكتبة
add_library(CalculatorLib src/calculator.cpp)
target_include_directories(CalculatorLib PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/src)
set_project_warnings(CalculatorLib)

# إنشاء هدف الملف التنفيذي
add_executable(MyApplication src/main.cpp)
target_link_libraries(MyApplication PRIVATE CalculatorLib)
set_project_warnings(MyApplication)

# تفعيل الاختبارات
enable_testing()
add_subdirectory(tests)

# تعريف قواعد التثبيت (لـ CPack)
include(GNUInstallDirs)
install(TARGETS MyApplication CalculatorLib
 RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
 LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
 ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
)

# إعدادات التغليف باستخدام CPack
set(CPACK_PROJECT_NAME ${PROJECT_NAME})
set(CPACK_PROJECT_VERSION ${PROJECT_VERSION})
set(CPACK_GENERATOR "ZIP;TGZ")
if(WIN32)
 set(CPACK_GENERATOR "ZIP")
endif()
include(CPack)

النقاط المهمة:

CMAKE_CXX_EXTENSIONS OFF: يمنع الاعتماد على ميزات غير قياسية مثل امتدادات GNU، مما يضمن التوافق عبر المنصات.
صرامة التحذيرات (-Werror / /WX): من خلال التعامل مع تحذيرات المترجم كأخطاء في بيئة CI، فإننا نفرض جودة كود عالية بشكل صارم.
GNUInstallDirs: يحل مسارات التثبيت القياسية لكل نظام تشغيل (مثل /usr/local/bin أو C:\Program Files) تلقائيًا.

4. أساسيات GitHub Actions واستراتيجية المصفوفة

تتكون GitHub Actions من ملفات YAML موجودة في دليل .github/workflows/. أقوى ميزة لمشاريع C++ هي “استراتيجية المصفوفة” (Matrix Strategy). تتيح لك هذه الميزة إنشاء مجموعات ديناميكية من أنظمة التشغيل والمترجمات وتشغيلها بالتوازي.

graph TD
A["بدء مسار العمل"] --> B["تقييم مهمة المصفوفة"]
B --> C["Ubuntu 22.04 (GCC 12)"]
B --> D["Ubuntu 22.04 (Clang 15)"]
B --> E["Windows Server 2022 (MSVC)"]
B --> F["macOS 14 (Apple Clang)"]

فيما يلي تعريف وظيفة YAML الأساسي لبناء مصفوفة.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


jobs:
 build:
 name: "Build & Test [${{ matrix.os }} - ${{ matrix.compiler }}]"
 runs-on: ${{ matrix.os }}
 strategy:
 fail-fast: false # الاستمرار في بناء أنظمة التشغيل الأخرى حتى في حالة فشل إحدى الوظائف
 matrix:
 include:
 - os: ubuntu-latest
 compiler: gcc
 c_compiler: gcc
 cpp_compiler: g++
 - os: ubuntu-latest
 compiler: clang
 c_compiler: clang
 cpp_compiler: clang++
 - os: windows-latest
 compiler: msvc
 c_compiler: cl
 cpp_compiler: cl
 - os: macos-latest
 compiler: apple-clang
 c_compiler: clang
 cpp_compiler: clang++

الخيار fail-fast: false مهم جداً. على سبيل المثال، إذا تم استخدام واجهة برمجة تطبيقات (API) خاصة بنظام Linux بالخطأ، فسيفشل البناء على Ubuntu، ولكننا نريد أيضًا معرفة ما إذا كان البناء على Windows سينجح في نفس الوقت.

5. تكاليف البناء وتحسين المعالجة المتوازية باستخدام قانون أمدال

يعد CI/CD في البيئات السحابية معركة مع الوقت، حيث يرتبط وقت البناء مباشرة بوقت انتظار المطورين وتكاليف التشغيل. هنا، دعونا نتناول التحسين في أوقات البناء رياضيًا باستخدام “قانون أمدال” (Amdahl’s Law) في علوم الكمبيوتر.

قانون أمدال يُعرّف الحد الأقصى النظري لنسبة تحسين السرعة $S(N)$ عند استخدام $N$ معالجات، حيث $P$ هي نسبة الجزء القابل للتوازي من البرنامج، على النحو التالي:

$$ S(N) = \frac{1}{(1 - P) + \frac{P}{N}} $$

في عملية بناء C++، تكون ترجمة كل وحدة ترجمة (Translation Unit: ملف .cpp) في الكود المصدري مستقلة تمامًا، مما يجعل التوازي ممكنًا. من ناحية أخرى، فإن تكوين CMake ومرحلة ربط الثنائيات النهائية (Linking Phase) تكون بشكل أساسي تسلسلية (لا يمكن موازنتها).

بافتراض أن 80٪ من وقت البناء الإجمالي للمشروع هو مرحلة الترجمة ($P = 0.8$) و 20٪ هو المرحلة التسلسلية ($1 - P = 0.2$). يوفر المشغل الافتراضي (Runner) لـ GitHub Actions (Linux) نواتين (2 مسارات/threads). لذا عندما تكون $N = 2$:

$$ S(2) = \frac{1}{0.2 + \frac{0.8}{2}} = \frac{1}{0.2 + 0.4} = \frac{1}{0.6} \approx 1.67 $$

باستخدام نواتين فقط، نحصل على تحسين في السرعة بنحو 1.67 مرة. لتحقيق ذلك، من الضروري تحديد خيار --parallel في أمر بناء CMake.

1
2


 - name: "Build Project"
 run: cmake --build build --config Release --parallel 2

علاوة على ذلك، نأخذ في الاعتبار حساب التكلفة. تكلفة الاستخدام الإجمالية $C_{total}$ لـ GitHub Actions هي مجموع حاصل ضرب وقت تنفيذ الوظيفة $T_i$ في سعر الوحدة للمشغل $R_i$.

$$ C_{total} = \sum_{i=1}^{M} \left( T_i \times R_i \right) $$

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

6. الاختبار الآلي ودمج المطهرات (Sanitizers)

لمنع الأخطاء بشكل استباقي في C++، يوصى بشدة بتقديم “المطهرات” (Sanitizers) التي تكتشف تسرب الذاكرة والسلوكيات غير المحددة أثناء وقت التشغيل (Runtime)، بالإضافة إلى اختبار الوحدة (Unit Testing). سنستخدم AddressSanitizer (ASAN) و UndefinedBehaviorSanitizer (UBSAN) التي طورتها جوجل.

نضيف خيارًا في CMake لتفعيل المطهرات.

1
2
3
4
5


option(ENABLE_SANITIZERS "Enable ASAN and UBSAN" OFF)
if(ENABLE_SANITIZERS AND CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang")
 add_compile_options(-fsanitize=address,undefined -fno-omit-frame-pointer)
 add_link_options(-fsanitize=address,undefined)
endif()

نقوم بتفعيل هذا الخيار في وظيفة Ubuntu الخاصة بمسار CI ونقوم بتشغيل الاختبارات.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


 - name: "Configure CMake"
 env:
 CC: ${{ matrix.c_compiler }}
 CXX: ${{ matrix.cpp_compiler }}
 run: >
 cmake -B build
 -DCMAKE_BUILD_TYPE=Release
 -DENABLE_SANITIZERS=${{ matrix.os == 'ubuntu-latest' && 'ON' || 'OFF' }}

 - name: "Run CTest"
 working-directory: build
 env:
 ASAN_OPTIONS: "detect_leaks=1:symbolize=1"
 UBSAN_OPTIONS: "print_stacktrace=1"
 run: ctest --build-config Release --output-on-failure --parallel 2

نستخدم أمر ctest لتشغيل الاختبارات. من خلال تحديد --output-on-failure، سيتم عرض السجلات التفصيلية للاختبارات الفاشلة فقط في مخرجات CI، مما يمنع تضخم السجلات.

7. قياس التغطية (Code Coverage)

يعد تصور مقدار الكود الذي تغطيه الاختبارات أمرًا مهمًا لضمان الجودة. باستخدام بيئة Linux (GCC)، نقيس التغطية بواسطة gcov و lcov.

أولاً، نقوم بتعيين أعلام الترجمة (Compile Flags) في CMake لقياس التغطية.

1
2
3
4
5


option(ENABLE_COVERAGE "Enable coverage reporting" OFF)
if(ENABLE_COVERAGE AND CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
 add_compile_options(--coverage -O0 -g)
 add_link_options(--coverage)
endif()

نحدد وظيفة مستقلة لقياس التغطية في GitHub Actions.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


 coverage:
 name: "Test Coverage Analysis"
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4

 - name: "Install lcov"
 run: sudo apt-get update && sudo apt-get install -y lcov

 - name: "Configure CMake for Coverage"
 run: cmake -B build -DCMAKE_BUILD_TYPE=Debug -DENABLE_COVERAGE=ON

 - name: "Build & Test"
 run: |
 cmake --build build --parallel 2
 cd build && ctest --output-on-failure

 - name: "Generate lcov Report"
 working-directory: build
 run: |
 lcov --capture --directory . --output-file coverage.info
 lcov --remove coverage.info '/usr/*' '*_deps/*' '*tests/*' --output-file coverage.info
 
 - name: "Upload Coverage to Codecov"
 uses: codecov/codecov-action@v3
 with:
 files: build/coverage.info

باستخدام أمر lcov --remove، يتم استبعاد رؤوس النظام (System Headers) والمكتبات الخارجية (Third-party Libraries) ورمز الاختبار نفسه من قياس التغطية. يتيح لنا هذا الحصول على التغطية الخالصة للكود المصدري الخاص بالمشروع.

8. التسليم التلقائي للثنائيات عبر GitHub Releases (CD)

الآن سنبني جزء “CD” من CI/CD. عندما يقوم المطور بإضافة علامة إصدار في Git (مثل: v1.2.0) ويدفعها (Push)، سيتم تلقائيًا تجميع الثنائيات القابلة للتنفيذ لكل نظام تشغيل، وتغليفها في ملفات ZIP أو Tarball، ثم رفعها إلى GitHub Releases.

في هذه الخطوة، نستخدم أداة التغليف CPack المرفقة مع CMake.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


 - name: "Package Application (CPack)"
 if: startsWith(github.ref, 'refs/tags/v')
 working-directory: build
 run: cpack -C Release -V

 - name: "Upload Release Assets"
 if: startsWith(github.ref, 'refs/tags/v')
 uses: softprops/action-gh-release@v1
 with:
 files: |
 build/*.tar.gz
 build/*.zip
 build/*.sh
 build/*.exe
 env:
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

باستخدام هذا الإعداد، بمجرد تنفيذ الأوامر git tag v1.0.0 و git push origin v1.0.0، سيتم نشر ملف ZIP لمستخدمي Windows وملف Tarball لمستخدمي Linux/macOS تلقائيًا على صفحة الإصدار (Release Page) دون أي تدخل يدوي. إنها ميزة قوية للغاية في إيصال البرمجيات للمستخدمين.

9. ملف Workflow YAML الكامل

يظهر أدناه الكود الكامل والقوي والعملي لملف .github/workflows/main.yml الذي يجمع كل العناصر التي شرحناها حتى الآن.

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107


name: "C++ CI/CD Pipeline"

on:
 push:
 branches: [ "main", "develop" ]
 tags: [ "v*.*.*" ]
 pull_request:
 branches: [ "main" ]

env:
 BUILD_TYPE: Release

jobs:
 build-and-test:
 name: "Build [${{ matrix.os }} | ${{ matrix.compiler }}]"
 runs-on: ${{ matrix.os }}
 strategy:
 fail-fast: false
 matrix:
 include:
 - os: ubuntu-latest
 compiler: gcc
 c_compiler: gcc
 cpp_compiler: g++
 - os: ubuntu-latest
 compiler: clang
 c_compiler: clang
 cpp_compiler: clang++
 - os: windows-latest
 compiler: msvc
 c_compiler: cl
 cpp_compiler: cl
 - os: macos-latest
 compiler: apple-clang
 c_compiler: clang
 cpp_compiler: clang++

 steps:
 - name: "Checkout Repository"
 uses: actions/checkout@v4

 - name: "Configure CMake"
 env:
 CC: ${{ matrix.c_compiler }}
 CXX: ${{ matrix.cpp_compiler }}
 run: >
 cmake -B build
 -DCMAKE_BUILD_TYPE=${{ env.BUILD_TYPE }}
 -DENABLE_SANITIZERS=${{ matrix.os == 'ubuntu-latest' && 'ON' || 'OFF' }}

 - name: "Build Project"
 run: cmake --build build --config ${{ env.BUILD_TYPE }} --parallel 2

 - name: "Run Unit Tests (CTest)"
 working-directory: build
 env:
 ASAN_OPTIONS: "detect_leaks=1:symbolize=1"
 UBSAN_OPTIONS: "print_stacktrace=1"
 run: ctest --build-config ${{ env.BUILD_TYPE }} --output-on-failure --parallel 2

 - name: "Package with CPack"
 if: startsWith(github.ref, 'refs/tags/v')
 working-directory: build
 run: cpack -C ${{ env.BUILD_TYPE }}

 - name: "Create GitHub Release and Upload Assets"
 if: startsWith(github.ref, 'refs/tags/v')
 uses: softprops/action-gh-release@v1
 with:
 files: |
 build/*.tar.gz
 build/*.zip
 env:
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

 coverage:
 name: "Code Coverage Analysis"
 runs-on: ubuntu-latest
 if: github.event_name == 'pull_request' || github.ref == 'refs/heads/main'
 steps:
 - name: "Checkout Repository"
 uses: actions/checkout@v4

 - name: "Install lcov"
 run: sudo apt-get update && sudo apt-get install -y lcov

 - name: "Configure CMake for Coverage"
 run: cmake -B build -DCMAKE_BUILD_TYPE=Debug -DENABLE_COVERAGE=ON

 - name: "Build Project"
 run: cmake --build build --parallel 2

 - name: "Run Tests"
 working-directory: build
 run: ctest --output-on-failure

 - name: "Generate lcov Report"
 working-directory: build
 run: |
 lcov --capture --directory . --output-file coverage.info
 lcov --remove coverage.info '/usr/*' '*_deps/*' '*tests/*' --output-file coverage.info
 
 - name: "Upload Coverage to Codecov"
 uses: codecov/codecov-action@v3
 with:
 files: build/coverage.info
 fail_ci_if_error: false

10. نحو CI/CD أكثر تقدمًا (التحليل الثابت والتنسيق)

على الرغم من حذف الشرح التفصيلي هنا، يوصى بدمج أدوات إضافية لضمان الجودة في مسار العمل أثناء التشغيل الفعلي.

فرض Clang-Format: لتقليل عبء مراجعات الكود (Code Review)، قم بدمج فحص نمط الكود (Code Style) باستخدام clang-format في CI، واجعل مسار العمل يفشل إذا كان ينتهك قواعد التنسيق.
التحليل الثابت (Clang-Tidy): لاكتشاف الأخطاء الكامنة التي لا يمكن منعها بتحذيرات المترجم وحدها، أو الكود غير الفعال (مثل النسخ غير الضروري)، قم بدمج clang-tidy في CMake وتشغيله على CI.
استخدام التخزين المؤقت لـ vcpkg / Conan: في حال استخدام العديد من مكتبات الطرف الثالث، يستغرق بناء التبعيات وقتًا طويلاً. يمكنك تقليل وقت البناء بشكل كبير عن طريق استخدام actions/cache من GitHub Actions للاحتفاظ بالدليل المثبت لـ vcpkg أو التخزين المؤقت لـ Conan.

الخاتمة

قد يبدو إعداد مسار CI/CD في مشاريع C++ للوهلة الأولى كعقبة كبيرة بسبب الاعتماد على المنصة وتعقيد أدوات البناء. ولكن، من خلال الدمج الصحيح لبيئة GitHub Actions، و Modern CMake، ونظام CTest/CPack، يمكنك الحصول على تدفق تطوير مؤتمت وقوي للغاية.

إن التحقق متعدد المنصات (Cross-platform Verification) باستخدام استراتيجية المصفوفة، واكتشاف الأخطاء أثناء وقت التشغيل عبر المطهرات (Sanitizers)، وقياس التغطية، والنشر التلقائي في GitHub Releases الذي تم شرحه في هذه المقالة هي أفضل الممارسات المعتمدة على نطاق واسع حتى في مشاريع مفتوحة المصدر على المستوى التجاري.

يقلل مسار CI/CD المؤتمت من الوقت الذي يقضيه المطورون في “البحث عن الأخطاء” و"عمليات البناء والإصدار اليدوية" إلى الحد الأدنى، ويصبح أقوى سلاح للتركيز على نشاط البرمجة الإبداعي الأصلي. تأكد من إضافته إلى مشروع C++ الخاص بك لتستمتع بحياة تطوير رشيقة ومريحة.

كيفية استضافة مدونة Hugo مجانًا وبسرعة فائقة على Cloudflare Pages و GitHub Pages

Sat, 12 Sep 2026 12:00:00 +0900

عند إدارة موقع ويب أو مدونة، تعتبر سرعة العرض (الأداء)، تكاليف التشغيل، والأمان عوامل في غاية الأهمية. في الماضي، كان المزيج بين أنظمة إدارة المحتوى الديناميكية (CMS) مثل WordPress وخوادم الاستضافة المشتركة هو السائد، أما اليوم فإن المعمارية المعروفة باسم “Jamstack” تحظى باهتمام كبير. من بين هذه التقنيات، بدمج “Hugo” وهو مولد مواقع ثابتة (SSG) فائق السرعة مبني بلغة Go، مع خدمات استضافة حديثة مثل Cloudflare Pages و GitHub Pages، يمكنك بناء بيئة تدوين مجانية بالكامل وفائقة السرعة.

في هذا المقال، سنشرح بتعمق من منظور تقني الخطوات العملية لنشر موقع ثابت مبني بـ Hugo على Cloudflare Pages و GitHub Pages، والفرق في المعمارية بين كل منصة، وبناء CI/CD (التكامل المستمر/التسليم المستمر) باستخدام GitHub Actions، وتحسين DNS، واستراتيجيات التخزين المؤقت (Cache)، ووصولاً إلى دمج أدوات تحليل الزيارات التي تراعي الخصوصية.

1. أساسيات مولدات المواقع الثابتة (SSG) ومعمارية Jamstack

1.1 لماذا المواقع الثابتة؟

أنظمة إدارة المحتوى الديناميكية التقليدية (مثل: WordPress) تقوم بإرسال استعلام إلى قاعدة البيانات (مثل MySQL) عند كل طلب من المستخدم، وتقوم بإنشاء HTML ديناميكيًا على جانب الخادم (مثل PHP) ثم إعادته. على الرغم من أن هذا الأسلوب يتميز بمرونة عالية، إلا أن مقاومته للزيادات المفاجئة في حركة المرور (ما يسمى بالانتشار الواسع أو هجمات DDoS) ضعيفة، وغالبًا ما تصبح بنية النظام معقدة بسبب الحاجة إلى وضع خوادم تخزين مؤقت (مثل Redis أو Varnish) في المقدمة.

من ناحية أخرى، في مولدات المواقع الثابتة (SSG) التي تعتمد معمارية Jamstack (وهي اختصار لـ JavaScript و APIs و Markup)، يتم إنشاء جميع ملفات HTML و CSS و JavaScript مسبقًا (أثناء عملية البناء). عند استلام طلب المستخدم، يقوم خادم الويب (أو CDN) ببساطة بإرجاع الملفات الثابتة التي تم إنشاؤها مسبقًا كما هي، مما يوفر سرعة فائقة وأمانًا قويًا.

1.2 أفضلية Hugo

هناك العديد من الخيارات المتاحة لـ SSG مثل Next.js و Gatsby و Jekyll و Astro، ولكن الميزة الأكبر لـ Hugo هي سرعة البناء. بفضل المعالجة المتزامنة في لغة Go، تكتمل عملية البناء في بضع ثوانٍ فقط حتى لموقع يحتوي على آلاف أو عشرات الآلاف من الصفحات. هذا يقلل بشكل كبير من أوقات الانتظار في مسار CI/CD، مما يؤدي بشكل مباشر إلى تحسين تجربة المطور (DX: Developer Experience).

2. مقارنة معمارية خدمات الاستضافة

التحدي التالي هو تحديد المكان الذي سيتم فيه استضافة الملفات الثابتة التي تم إنشاؤها بواسطة Hugo. تشمل الخيارات البارزة Cloudflare Pages و GitHub Pages و Netlify، ولكن بنية الشبكة التي تعمل خلف الكواليس تختلف في كل منها.

2.1 شبكات توصيل المحتوى (CDN) والحوسبة الطرفية (Edge Computing)

تستخدم جميع هذه المنصات شبكة توصيل محتوى (CDN) موزعة عالميًا لتوصيل المحتوى. ومع ذلك، لا يقتصر الأمر على مجرد التخزين المؤقت للملفات الثابتة، بل إن العامل الفارق هو القدرة على استخدام “الحوسبة الطرفية” لتوجيه الطلبات وإعادة كتابة الترويسات (Headers) في أقرب نقطة تواجد (PoP) للمستخدم.

graph TD
A["المستخدم (طوكيو)"] -->|Low Latency| B["عقدة طرفية (NRT)"]
C["المستخدم (نيويورك)"] -->|Low Latency| D["عقدة طرفية (EWR)"]
E["المستخدم (لندن)"] -->|Low Latency| F["عقدة طرفية (LHR)"]
B --> G["تخزين الأصل / مخزن الكائنات"]
D --> G
F --> G

2.2 GitHub Pages

GitHub Pages هي خدمة تتيح لك نشر ملفات HTML و CSS و JavaScript مباشرة من مستودع GitHub. يتم استخدام شبكات CDN مثل Fastly في الخلفية، مما يوفر أداءً ممتازًا. ومع ذلك، هناك قيود على تخصيص الترويسات (مثل إعدادات Cache-Control وترويسات الأمان)، وتعتمد إعدادات إعادة التوجيه على meta refresh في HTML أو إضافات Jekyll، مما يجعل وظائفها كبنية تحتية بحتة متواضعة إلى حد ما.

2.3 Cloudflare Pages

Cloudflare Pages هي خدمة استضافة مواقع ثابتة مبنية على أكبر شبكة Anycast في العالم تفخر بها Cloudflare (منتشرة في أكثر من 275 مدينة). توفر دعمًا قياسيًا لـ HTTP/3 (QUIC)، وتحسين الصور، وتكامل الوظائف الطرفية (Cloudflare Workers)، مما يتيح ضبط أداء استثنائي. بالإضافة إلى ذلك، لا توجد رسوم على عرض النطاق الترددي (Bandwidth)، وهي ميزة كبيرة حيث يمكنك تشغيلها مجانًا مهما زادت حركة المرور بشكل مفاجئ.

2.4 Netlify

تعتبر Netlify رائدة في معمارية Jamstack، حيث توفر تجربة مطور (DX) متكاملة تجمع بين النماذج، المصادقة (Identity)، والوظائف بدون خادم (Serverless Functions). ولكن إذا تجاوزت حد عرض النطاق الترددي المجاني (100 جيجابايت شهريًا)، ستتحمل رسوم استهلاك باهظة، لذلك يجب الانتباه إلى إدارة التكاليف في المدونات التي تستخدم الصور ومقاطع الفيديو بكثرة.

3. الحساب النظري للأداء وزمن الانتقال (النموذج الرياضي باستخدام LaTeX)

عند تقييم أداء الويب، يعد تقليل زمن الانتقال (Latency) أهم مؤشر. دعونا نضع نموذجًا لمدى تقليل زمن الانتقال عند استخدام شبكة توصيل المحتوى CDN (الطرفية) مقارنة بالوصول المباشر إلى خادم الأصل (Origin Server).

نفترض أن احتمالية نجاح طلب المستخدم في العثور على ما يطلبه في التخزين المؤقت هي “نسبة إصابة التخزين المؤقت (Cache Hit Ratio)” ونرمز لها بـ $C$. حيث $0 \le C \le 1$. ونرمز لزمن الانتقال إلى خادم الأصل بـ $L_{origin}$، وزمن الانتقال إلى أقرب عقدة طرفية بـ $L_{edge}$.

يتم حساب متوسط زمن الانتقال الجديد $L_{new}$ كقيمة متوقعة على النحو التالي:

$$ L_{new} = C \times L_{edge} + (1 - C) \times (L_{edge} + L_{origin}) $$

عند تبسيط هذه المعادلة تصبح كالتالي:

$$ L_{new} = L_{edge} + (1 - C) \times L_{origin} $$

على سبيل المثال، عندما يصل مستخدم في طوكيو إلى خادم أصل يقع على الساحل الشرقي للولايات المتحدة (نيويورك)، فإن $L_{origin}$ سيكون حوالي 200 مللي ثانية، مع الأخذ في الاعتبار المسافة المادية للألياف الضوئية وتأخير المعالجة في الموجهات (Routers). من ناحية أخرى، عند استخدام شبكة CDN مثل Cloudflare، يمكن الاتصال بالعقدة الطرفية في طوكيو، مما يقلل $L_{edge}$ إلى حوالي 10 مللي ثانية.

بافتراض أن نسبة إصابة التخزين المؤقت $C = 0.95$ (95%)،

$$ L_{new} = 10 + (1 - 0.95) \times 200 = 10 + 0.05 \times 200 = 10 + 10 = 20 \text{ ms} $$

بهذه الطريقة، من خلال اعتماد CDN، يصبح من الممكن تقليل متوسط زمن الانتقال بشكل كبير (حوالي 90٪) من 210 مللي ثانية إلى 20 مللي ثانية.

4. بناء مسار CI/CD باستخدام GitHub Actions

من أجل أتمتة عملية تحديث مدونة Hugo، سنقوم ببناء مسار CI/CD باستخدام GitHub Actions. بفضل هذا، بمجرد كتابة مقالات بصيغة Markdown محليًا وتنفيذ أمر git push، ستبدأ عملية البناء تلقائيًا وسيتم نشر الموقع على Cloudflare Pages أو GitHub Pages.

يوضح المخطط التسلسلي (Sequence Diagram) التالي التدفق الكامل منذ عملية الدفع (Push) للمقال وحتى تسليمه للمستخدم.

sequenceDiagram
participant U as "المستخدم (المؤلف)"
participant G as "مستودع GitHub"
participant A as "GitHub Actions"
participant C as "Cloudflare Pages"
participant V as "الزائر"
U->>G: "git push origin main"
G->>A: "إطلاق حدث الدفع (Push Event)"
A->>A: "سحب الكود وإعداد Hugo"
A->>A: "hugo --minify (بناء)"
A->>C: "النشر على Cloudflare Pages (رفع مباشر)"
C-->>A: "رابط النشر (نجاح)"
V->>C: "طلب صفحة الويب"
C-->>V: "إرجاع HTML المخزن مؤقتا (عبر العقدة الطرفية)"

4.1 إعدادات النشر على Cloudflare Pages (الرفع المباشر - Direct Upload)

في Cloudflare Pages، توجد طريقتان: ربط مستودع GitHub وبناء الموقع على بنية Cloudflare التحتية، أو طريقة “الرفع المباشر (Direct Upload)” للملفات الثابتة التي تم بناؤها بواسطة GitHub Actions. إذا كنت ترغب في إدارة إصدارات Hugo بشكل أكثر صرامة وربطه بمهام أخرى (مثل الاختبار وتحسين الصور)، يُوصى بالبناء على GitHub Actions واستخدام الرفع المباشر.

فيما يلي مثال عملي لملف .github/workflows/deploy.yml للنشر على Cloudflare Pages.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


name: "Deploy Hugo site to Cloudflare Pages"

on:
 push:
 branches:
 - "main"
 workflow_dispatch:

jobs:
 build-and-deploy:
 runs-on: "ubuntu-latest"
 steps:
 - name: "Checkout repository"
 uses: "actions/checkout@v4"
 with:
 submodules: "recursive"
 fetch-depth: 0

 - name: "Setup Hugo"
 uses: "peaceiris/actions-hugo@v3"
 with:
 hugo-version: "0.125.0"
 extended: true

 - name: "Build Hugo Site"
 run: "hugo --minify --gc"
 env:
 HUGO_ENVIRONMENT: "production"

 - name: "Deploy to Cloudflare Pages"
 uses: "cloudflare/pages-action@v1"
 with:
 apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
 accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
 projectName: "your-project-name"
 directory: "public"
 gitHubToken: ${{ secrets.GITHUB_TOKEN }}
 branch: "main"

في مسار العمل هذا، يقوم خيار --minify بتصغير ملفات HTML/CSS/JS، ويقوم --gc بحذف الملفات غير الضرورية. وتعتبر هذه أساسيات تحسين الأداء.

5. التعمق في إعدادات DNS: النطاق المخصص وسجلات CNAME / ALIAS

عند استخدام نطاق خاص (مثل: kenji.blog)، يكون الإعداد الصحيح لـ DNS (نظام أسماء النطاقات) أمرًا حيويًا.

5.1 قيود سجل CNAME ونطاق الجذر (Zone Apex)

عادةً، عند توجيه نطاق فرعي (مثل: www.kenji.blog) إلى خدمة خارجية، يتم استخدام سجل CNAME. ومع ذلك، وبسبب مواصفات DNS (حسب RFC 1034)، لا يمكن إعداد سجل CNAME للنطاق الجذر (المعروف أيضًا باسم Zone Apex أو النطاق المجرد، مثل: kenji.blog). والسبب في ذلك هو أن النطاق الجذر يجب أن يحتوي دائمًا على سجلات SOA (Start of Authority) وسجلات NS (Name Server) وسجلات MX (Mail Exchange)، وتوجد قاعدة تنص على أن سجل CNAME لا يمكن أن يتواجد مع سجلات الموارد الأخرى.

5.2 الحلول: ALIAS / ANAME / CNAME Flattening

لحل هذه المشكلة، توفر شركات تقديم خدمات DNS الحديثة إضافات خاصة بها.

سجلات ALIAS / ANAME: تقوم بتحليل الاسم ديناميكيًا على جانب خادم DNS وإرجاع سجل A النهائي (عنوان IP) إلى العميل. تدعم خدمات مثل Amazon Route 53 هذه الميزة.
CNAME Flattening: هي ميزة تقدمها Cloudflare. فهي تتصرف كما لو تم إعداد سجل CNAME على النطاق الجذر (Zone Apex)، بينما يقوم خادم DNS المعتمد من Cloudflare بإرجاع عناوين IP التي تم حلها تلقائيًا (سجلات A وسجلات AAAA) إلى العميل بشفافية.

عند استخدام Cloudflare Pages، فإن تفويض خوادم الأسماء (Name Servers) الخاصة بالنطاق إلى Cloudflare واستغلال تقنية “CNAME Flattening” يوفر البنية الأكثر سلاسة وعالية الأداء.

6. استراتيجيات التخزين المؤقت والتحكم في ترويسات HTTP

في عملية تسريع المواقع الثابتة، هناك عنصر أساسي آخر وهو “استراتيجية التخزين المؤقت”. في Cloudflare Pages، يمكنك استخدام ملف يتم إنشاؤه (ملف _headers) للتحكم الدقيق في ترويسات الاستجابة HTTP (HTTP Response Headers).

6.1 التخزين المؤقت الطرفي (Edge Cache) مقابل التخزين المؤقت للمتصفح (Browser Cache)

ينقسم التخزين المؤقت بشكل عام إلى نوعين: “التخزين المؤقت الطرفي (Edge Cache)” الذي يتم الاحتفاظ به على جانب شبكة CDN، و “التخزين المؤقت للمتصفح (Browser Cache)” الذي يتم تخزينه في متصفح المستخدم.

من المثالي جعل الملفات الثابتة (مثل الصور، CSS، JS، والتي تحتوي أسماؤها على دوال تجزئة “Hashes”) تُخزن مؤقتًا في المتصفح لفترات طويلة. من ناحية أخرى، بالنسبة لملفات HTML، ولعكس التحديثات فورًا، من الشائع تقصير مدة التخزين المؤقت في المتصفح (أو تعطيله بالكامل) والاعتماد على التخزين المؤقت الطرفي للتعامل معها.

مثال على إعداد _headers في Cloudflare Pages:

1
2
3
4
5
6
7
8
9


# عدم تخزين ملفات HTML في المتصفح والتحقق منها في كل مرة
/*.html
 Cache-Control: public, max-age=0, must-revalidate

# تخزين ملفات الأصول (CSS/JS/الصور) في المتصفح لمدة عام واحد
/assets/*
 Cache-Control: public, max-age=31536000, immutable
/img/*
 Cache-Control: public, max-age=31536000, immutable

6.2 معادلة حساب خفض تكاليف عرض النطاق الترددي

من خلال إعداد ترويسات التخزين المؤقت المناسبة، يمكنك تقليل كمية نقل البيانات من الخادم (الطرفية) بشكل كبير. يمكن التعبير عن التكلفة الشهرية لعرض النطاق الترددي $Cost$ بالنموذج التالي بناءً على كمية النقل $B_i$ لكل مورد، نسبة إصابة التخزين المؤقت $C_i$، وسعر الوحدة لعرض النطاق الترددي $R$:

$$ Cost = \sum_{i=1}^{n} \left( B_i \times (1 - C_i) \times R \right) $$

نظرًا لأن Cloudflare يوفر حركة نقل البيانات الصادرة مجانًا ($R = 0$)، فإن التكلفة المالية المباشرة ستكون $0$. ومع ذلك، عند استخدام بنية تحتية أخرى بالاقتران مثل GitHub Pages، أو استخدام خوادم خلفية مثل AWS S3، فإن تعظيم نسبة إصابة التخزين المؤقت $C_i$ يعد عاملاً رئيسيًا في تقليل تكاليف البنية التحتية.

7. تحليلات الزيارات التي تجمع بين الخصوصية والأداء

أثناء إدارة مدونة، تُعتبر تحليلات الزيارات (Web Analytics) لمعرفة عدد المستخدمين الزائرين أمرًا لا غنى عنه. لفترة طويلة كانت أداة Google Analytics (GA4) هي المعيار الفعلي السائد، ولكن مع توجهات حماية الخصوصية الحديثة (مثل GDPR و CCPA)، والتخلص التدريجي من ملفات تعريف الارتباط للجهات الخارجية (Third-party Cookies)، بدأت الأوضاع في التغير.

7.1 التأثير على أداء الويب

عند دمج Google Analytics (وتحديدًا gtag.js أو Google Tag Manager)، يتم تحميل وتنفيذ العديد من السكربتات الخارجية، مما يؤثر سلبًا على الأداء (خاصة وقت الاستجابة الأولي TTFB ووقت حظر مؤشر الترابط الرئيسي Main-thread Blocking Time).

دعونا نقسم ونفكر في أوقات تحميل الموقع كما يلي:

pie title "توزيع أوقات تحميل الموقع النموذجي"
"TTFB (الوقت حتى البايت الأول)" : 15
"تنزيل المحتوى (HTML/CSS)" : 20
"تحليل DOM والعرض" : 45
"التحليلات وجافا سكريبت للجهات الخارجية" : 20

ليس من النادر أن تستهلك أدوات التحليل التي تعتمد على جافا سكريبت من جهات خارجية حوالي 20٪ إلى 30٪ من إجمالي وقت التحميل.

7.2 دمج Cloudflare Web Analytics

لذلك، تتجه الأنظار نحو أدوات تحليل الزيارات التي تعطي الأولوية للخصوصية ولا تستخدم ملفات تعريف الارتباط (Cookieless)، مثل Cloudflare Web Analytics و Plausible Analytics.

تعمل أداة Cloudflare Web Analytics بمجرد تضمين مقطع JavaScript خفيف الوزن للغاية، ولأنها لا تصدر ملفات تعريف الارتباط، فلن تكون هناك حاجة لإعداد لافتات الموافقة على ملفات تعريف الارتباط المزعجة (Cookie Consent Banner).

التنفيذ في Hugo سهل جدًا أيضًا. كل ما عليك فعله هو إضافة المقطع المقدم إلى ملفات مثل layouts/partials/head.html أو layouts/partials/analytics.html.

1
2
3
4
5


{{ if eq hugo.Environment "production" }}
<!-- Cloudflare Web Analytics -->
<script defer src='https://static.cloudflareinsights.com/beacon.min.js' data-cf-beacon='{"token": "YOUR_CLOUDFLARE_BEACON_TOKEN"}'></script>
<!-- End Cloudflare Web Analytics -->
{{ end }}

من خلال إضافة سمة defer، سيتم تحميل السكربت بشكل غير متزامن دون حظر عملية تحليل HTML، ليتم تنفيذه بعد اكتمال بناء DOM. هذا يقلل من التأثير على سرعة العرض الأولي (مثل LCP: عرض أكبر محتوى مرئي، و FCP: سرعة عرض أول محتوى) إلى الحد الأدنى.

8. الخلاصة وأفضل الممارسات

عند تشغيل موقع ثابت باستخدام Hugo، فإن اعتماد منصات الاستضافة الحديثة مثل Cloudflare Pages أو GitHub Pages يوفر فوائد هائلة من حيث الأداء مقابل التكلفة، سرعة العرض، والأمان.

بناء فائق السرعة: الاستفادة من سرعة Hugo لتقليل وقت تنفيذ مسار CI/CD (GitHub Actions) إلى أدنى حد ممكن.
التسليم عبر الطرفيات (Edge): استخدام شبكة طرفيات Cloudflare لتوصيل المحتوى للمستخدمين حول العالم بزمن انتقال يقاس بالمللي ثانية.
التكوين المناسب لـ DNS: الاستفادة من تقنية CNAME Flattening لتشغيل النطاق الجذر (النطاق الخاص) بأمان وسرعة.
تحسين استراتيجية التخزين المؤقت: استخدام _headers لفصل التخزين المؤقت للمتصفح والتخزين المؤقت الطرفي بشكل مناسب لكل نوع من أنواع الموارد.
تحليلات خفيفة الوزن: دمج أدوات مثل Cloudflare Web Analytics التي تحافظ على الأداء وتراعي الخصوصية.

من خلال الجمع بين هذه العناصر، يمكنك مجانًا بناء نظام تدوين قابل للتوسع وقوي، قادر على تحمل حركة مرور ضخمة تصل إلى الملايين من مشاهدات الصفحات (PV) شهريًا. إذا كنت تفكر في إطلاق مدونة تقنية، موقع شركة، أو موقع محفظة أعمال (Portfolio)، فننصحك بشدة بتجربة بنية Jamstack + Hugo + Cloudflare Pages.