محمد قتيبة شيخانيأبني. أستكشف. أشارك

15من 22

تطوير الويب

انشر موقعك الأوّل: من مستودع GitHub إلى رابطٍ يفتحه أيّ أحد

لقطة شاشة لطرفيّة داكنة فيها الأمر curl -sI على عنوان kutaibashi.github.io/my-first-site وتحته ردّ الخادم: HTTP/2 200، وserver: GitHub.com، ونوع المحتوى text/html، وتاريخ آخر تعديل 30 أيلول 2026، ثمّ الأمر dig +short kutaibashi.github.io وتحته أربعة عناوين IP تبدأ بـ185.199. وتحتها عنوان المقالة «انشر موقعك الأوّل» وسطرٌ تحته: من مستودع GitHub إلى رابطٍ يفتحه أيّ أحد.

صفحتك موجودةٌ الآن على GitHub، بتاريخها كلّه ورسائل التزاماتها. لكنّ من يفتح المستودع يرى ملفّات: index.html وstyle.css وscript.js في قائمة، كأنّها مجلّدٌ على حاسوب غيره. والزائر الذي تريده لا يريد أن يقرأ شيفرتك، يريد أن يفتح رابطًا فيرى الصفحة نفسها بألوانها وزرّها الداكن. والمسافة بين الحالتين أقصر ممّا تظنّ: إعدادٌ واحد في صفحة المستودع، ثمّ دقيقةٌ تقريبًا من الانتظار.

في هذا المقال تنشر الصفحة التي بنيتها في السلسلة، على عنوانٍ حقيقيّ يفتحه أيّ أحد، من غير أن تدفع شيئًا ومن غير أن تستأجر خادمًا أو تتعلّم لوحة تحكّم. ثمّ تتعلّم ما تتركه الشروح السريعة: كيف تتأكّد من أنّ الموقع حيٌّ فعلًا، ولماذا ينكسر التنسيق عند أغلب المبتدئين في أوّل نشر، وكيف تربط نطاقًا باسمك، وما حدود الخدمة المجّانيّة. وكلّ لقطةٍ من الطرفية والمتصفّح هنا من نشرٍ جرى فعلًا في 30 أيلول 2026، والموقع ما زال منشورًا لتفتحه بنفسك.

ما هو الموقع الثابت؟

الموقع الثابت مجموعة ملفّاتٍ جاهزة يرسلها الخادم كما هي. يطلب المتصفّح index.html فيأخذه، ثمّ يطلب style.css وscript.js فيأخذهما، ولا يحسب الخادم شيئًا ولا يسأل قاعدة بيانات. وهذا بالضبط ما صنعته في السلسلة حتّى الآن: صفحةٌ من ثلاثة ملفّات، وكلّ ما فيها من حركة يجري في متصفّح الزائر بلغة JavaScript.

أمّا الموقع الديناميكيّ فيبني الصفحة لحظة طلبها. فمتجرٌ يعرض سلّة مشترياتك، أو منتدى يعرض آخر الردود، يحتاج إلى برنامجٍ يعمل على الخادم بلغةٍ مثل PHP أو Python، وإلى قاعدة بيانات يقرأ منها ويكتب فيها. ولهذا يحتاج إلى استضافةٍ من نوعٍ آخر، شرحها دليل استضافة المواقع بأنواعها كلّها.

والموقع الثابت أرخص المواقع استضافةً وأسرعها وأقلّها عرضةً للاختراق، لأنّ الخادم لا يشغّل شيئًا من شيفرتك. ويكفي هذا النوع لأشياء أكثر ممّا يتوقّع المبتدئ: صفحةٌ شخصيّة تعرّف بك، أو ملفّ أعمال يعرض مشاريعك لصاحب عمل، أو سيرةٌ ذاتيّة. وقد يكون توثيقًا لمشروعٍ برمجيّ، أو مدوّنةً صغيرة تكتب صفحاتها بيدك.

ما هو GitHub Pages؟

خدمة GitHub Pages استضافةٌ للمواقع الثابتة تأخذ ملفّات HTML وCSS وJavaScript من مستودعٍ على GitHub مباشرةً، وتنشرها موقعًا على الويب.[1] ولها نوعان من المواقع. الأوّل موقع الحساب، ومستودعه يجب أن يحمل اسمًا محدّدًا هو username.github.io، ولكلّ حسابٍ موقعٌ واحد منه فقط، وعنوانه اسم الحساب نفسه. والثاني موقع المشروع، ويمكن أن يكون لكلّ مستودعٍ موقعٌ واحد، وعنوانه اسم الحساب ثمّ اسم المستودع بعد شرطةٍ مائلة.

ومستودع هذا المقال اسمه my-first-site على حساب kutaibashi، فعنوانه kutaibashi.github.io/my-first-site/. تذكّر هذه الشرطة الأخيرة واسم المستودع قبلها، لأنّ أوّل خطأٍ في النشر كلّه يأتي منهما، كما سترى بعد قليل.

والخدمة مجّانيّة للمستودعات العامّة في خطّة GitHub Free، ولا تحتاج إلى بطاقة دفع. أمّا نشر موقعٍ من مستودعٍ خاصّ فيحتاج إلى خطّةٍ مدفوعة مثل GitHub Pro. وينبّه توثيق GitHub إلى أنّ الموقع المنشور متاحٌ للجميع على الإنترنت حتّى لو كان مستودعه خاصًّا، فأزل أيّ بياناتٍ حسّاسة من المستودع قبل النشر، مثل كلمات المرور ومفاتيح الخدمات.[2] ولا يشغّل GitHub Pages لغات الخوادم، فلا PHP ولا Ruby ولا Python، وهذا يوافق تعريف الموقع الثابت الذي بدأت به.

وإن كنت في سوريا فقد تغيّر الوضع قبل سنة. ففي 4 أيلول 2025 أعلنت GitHub، بعد تخفيف العقوبات وقيود التصدير الأمريكيّة، أنّ الميزات الخاصّة والمدفوعة صارت متاحةً من جديد للمطوّرين في حلب وحمص ودمشق وسائر البلاد. وذكّرت بأنّ التعاون على المستودعات العامّة كان متاحًا طوال الوقت.[3] فالطريق الذي يشرحه هذا المقال هو نفسه من دمشق والرياض وبرلين.

شكل 1 من جهازك إلى زائرك أربعة صناديق من اليمين إلى اليسار بأسهم: جهازك وعليه الفرع main، ثمّ بالأمر push مستودعك على GitHub، ثمّ الصندوق المميّز «البناء والنشر» الذي يستغرق نحو 40 ثانية، ثمّ عبر https الزائر الذي يفتح الصفحة من github.io. جهازك main مستودع GitHub البناء والنشر نحو 40 ثانية الزائر github.io push https من جهازك إلى زائرك أربعة صناديق من الأعلى إلى الأسفل: جهازك وعليه الفرع main، ثمّ بالأمر push مستودعك على GitHub، ثمّ الصندوق المميّز «البناء والنشر» في نحو 40 ثانية، ثمّ عبر https الزائر الذي يفتح الصفحة من github.io. جهازك main push مستودع GitHub البناء والنشر نحو 40 ثانية https الزائر github.io
رحلة الصفحة من جهازك إلى الزائر: تدفع الفرع main إلى مستودعك على GitHub، فيبنيه GitHub وينشره في نحو 40 ثانية، ثمّ يفتحه الزائر عبر https من عنوان github.io.

انشر الصفحة في خمس دقائق

ابدأ بمستودعٍ عامّ على GitHub فيه ملفّات الصفحة، وملفّ index.html في جذره، أي في المستوى الأعلى من المستودع خارج أيّ مجلّد. فالخدمة تبحث عن index.html أو index.md أو README.md لتجعله الصفحة الأولى، وإن لم تجد واحدًا منها في المكان الصحيح لم يظهر شيء.[2] وإن كنت قد تابعت مقال Git وGitHub فعندك هذا كلّه جاهزًا. وإن لم يكن عندك، فأنشئ مستودعًا جديدًا فارغًا من زرّ + في أعلى GitHub، ثمّ اربطه بمجلّد مشروعك وادفع إليه:

git remote add origin [email protected]:kutaibashi/my-first-site.git
git push -u origin main

ضع اسم حسابك مكان kutaibashi. والرابط هنا بصيغة SSH، لأنّ GitHub لا يقبل كلمة مرور الحساب في عمليّات Git، كما شرح مقال Git. فإن كنت تستعمل رمز وصولٍ شخصيًّا، فانسخ رابط HTTPS من صفحة المستودع بدلًا منه. وفي اللقطة التالية الأمران كما جريا على المستودع الذي ترى صفحته في هذا المقال:

طرفيّة داكنة فيها الأمر git remote add origin برابط المستودع my-first-site على حساب kutaibashi، ثمّ الأمر git push -u origin main وتحته أسطر عدّ عشرة كائنات وضغطها وكتابتها، ثمّ سطرٌ يقول إنّ فرعًا جديدًا اسمه main صار على GitHub، وإنّ الفرع المحلّيّ main صار يتتبّع origin/main.
أوّل دفعٍ إلى المستودع الجديد: ربط المستودع البعيد باسم origin، ثمّ دفع الفرع main وربطه بنسخته على GitHub. لقطة شاشة من جهازي.

ثمّ افتح المستودع على GitHub، واضغط تبويب Settings، واختر Pages من القائمة الجانبيّة في قسم Code, planning, and automation. وإن لم تجد تبويب Settings في شريط المستودع، فافتح القائمة المنسدلة في آخر الشريط تجده فيها. وتحت عنوان Build and deployment، في خانة Source، اختر Deploy from a branch. ثمّ اختر من القائمة الأولى الفرع main، ومن الثانية المجلّد، واترك فيها ‎/ (root) أي جذر المستودع، واضغط Save.[4] وهذه الخانات يغيّرها من له صلاحيّة الإدارة أو الصيانة في المستودع، وهو أنت في مستودعك.

جزءٌ من صفحة إعدادات GitHub Pages بالإنجليزيّة تحت عنوان Branch: جملةٌ تقول إنّ الموقع يُبنى من الفرع main، وتحتها ثلاثة أزرار متجاورة: قائمة الفرع main، وقائمة المجلّد وعليها / (root) محاطةٌ بإطارٍ برتقاليّ، وزرّ Save.
خانة الفرع في إعدادات GitHub Pages: الفرع main، والمجلّد جذر المستودع، ثمّ زرّ الحفظ.توثيق GitHub، برخصة CC BY 4.0

والخيار الثاني في القائمة، المجلّد ‎/docs، يفيدك إن أردت أن يبقى في جذر المستودع ملفّاتٌ لا تخصّ الموقع، فتضع الموقع كلّه في مجلّد docs، وتبقى الشيفرة الأخرى حوله. وفي الحالتين، كلّما دفعت تغييرًا إلى الفرع الذي اخترته، نُشر ما في المجلّد من جديد تلقائيًّا.[4]

بعد الحفظ يبدأ GitHub البناء والنشر في الخلفيّة. ويقول توثيقه إنّ ظهور التغييرات قد يستغرق حتّى 10 دقائق.[2] وفي النشر الذي تراه هنا استغرق كلّ بناءٍ من البناءات الأربعة بين 40 و42 ثانية، فالعشر دقائق حدٌّ أقصى لا موعد. ثمّ يظهر أعلى صفحة الإعدادات نفسها سطرٌ فيه عنوان موقعك وزرّ Visit site، فتضغطه وترى صفحتك:

صفحة «مدوّنتي التقنيّة» كما يعرضها متصفّحٌ على شاشةٍ عريضة من عنوانها على github.io: العنوان الكبير في اليمين، وتحته روابط الرئيسة وعن المدوّنة وتواصل معي باللون الأحمر، وزرّ الوضع الداكن، وخطٌّ أحمر، ثمّ مقالٌ عنوانه «ما هي لغة HTML؟»، وفي الأسفل ثلاث بطاقات بيضاء متجاورة لـHTML وCSS وJavaScript.
صفحة المشروع منشورةً على عنوانها في github.io كما يعرضها متصفّحٌ على شاشةٍ عريضة، بالتنسيق نفسه الذي بُني في مقالات السلسلة. لقطة من المتصفّح.

تأكّد من أنّ الموقع حيّ

قد يعرض لك المتصفّح نسخةً قديمة من ذاكرته المؤقّتة، أو تفتح الملفّ من حاسوبك وأنت تظنّه الموقع. والطرفية التي تعرّفت إليها في مقال الطرفية تعطيك جوابًا لا يحتمل الشكّ. فالأمر curl -sI يطلب الصفحة من الخادم ويعرض ترويسات الردّ وحدها، والأمر dig +short يسأل نظام أسماء النطاقات عن عنوان الخادم. والحرف I يطلب الترويسات وحدها بلا جسم الصفحة، والحرف s يُسكت شريط التقدّم، فيبقى على الشاشة ما يهمّك فقط. والأمر dig موجودٌ في لينكس وmacOS، أمّا في Windows فيقابله الأمر Resolve-DnsName في PowerShell، كما يذكر توثيق GitHub:[5]

curl -sI https://kutaibashi.github.io/my-first-site/
dig +short kutaibashi.github.io
طرفيّة داكنة فيها الأمر curl -sI على عنوان الموقع، وتحته أربعة أسطر: HTTP/2 200، وserver: GitHub.com، وcontent-type: text/html، وlast-modified بتاريخ 30 أيلول 2026. ثمّ الأمر dig +short kutaibashi.github.io وتحته أربعة عناوين IP تبدأ كلّها بـ185.199 وتنتهي بـ153.
الموقع المنشور تحت الفحص: ردٌّ برمز 200 من خادمٍ اسمه GitHub.com، بنوع محتوى text/html وتاريخ آخر تعديلٍ يطابق وقت النشر، ثمّ أربعة عناوين IP يعيدها dig لنطاق github.io. لقطة شاشة من جهازي.

اقرأ الأسطر من الأعلى. فالرمز 200 يعني أنّ الخادم وجد الصفحة وأرسلها، والسطر server يقول إنّ من ردّ هو GitHub، والسطر last-modified يطابق دقيقة النشر، فهي النسخة الجديدة التي دفعتها للتوّ. والعنوان بدأ بـhttps من غير أن تفعل شيئًا، لأنّ كلّ موقعٍ على github.io أُنشئ بعد 15 حزيران 2016 يُقدَّم عبر HTTPS تلقائيًّا.[6]

أمّا الأسطر الأربعة الأخيرة فاحفظها في ذهنك: هي عناوين خوادم GitHub Pages، وستكتبها بيدك بعد قليل حين تربط نطاقًا باسمك، لأنّ التوثيق يطلب العناوين الأربعة نفسها بالترتيب نفسه تقريبًا.

كلّ تعديلٍ بعد اليوم دفعةٌ واحدة

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

وفي الجلسة التالية تعديلان من هذا النوع. الأوّل تصحيحٌ في index.html لعنوان السؤال، والثاني ملفٌّ جديد اسمه 404.html. ولأنّهما تغييران مختلفان، صار لكلٍّ منهما التزامه ورسالته، ثمّ دفعهما أمرٌ واحد:

طرفيّة داكنة: git status --short يُظهر index.html معدّلًا و404.html جديدًا، ثمّ git commit -am برسالة «صحّح عنوان السؤال في الصفحة»، ثمّ git add 404.html وgit commit برسالة «أضف صفحة 404 خاصّة»، ثمّ git push وأسطره حتّى السطر الذي ينقل main من a625a56 إلى f47c583.
تعديلان في التزامين منفصلين ثمّ دفعٌ واحد: تصحيح عنوان السؤال في index.html، ثمّ إضافة صفحة 404، ثمّ git push ينقل main على GitHub إلى الالتزام الجديد. لقطة شاشة من جهازي.

وهذه عادةٌ تحميك لاحقًا. فلو تبيّن أنّ صفحة 404 فيها خطأ، تعود عن التزامها وحده، ويبقى تصحيح العنوان في مكانه. وهذا بالضبط ما ستراه بعد قليل، حين يقع خطأٌ حقيقيّ على الموقع المنشور ويُصلَح بأمرٍ واحد.

صفحة 404 باسم موقعك

حين يكتب زائرٌ رابطًا خاطئًا في موقعك، يعرض له GitHub صفحة خطأٍ عامّة باسمه هو. لكنّك تستطيع أن تضع مكانها صفحتك: ملفٌّ اسمه 404.html في جذر مصدر النشر، يعرضه GitHub Pages كلّما طُلبت صفحةٌ غير موجودة.[7] والخادم يبقى صادقًا مع المتصفّح ومحرّكات البحث، فيرسل الرمز 404 مع صفحتك، ويعرف الإنسان من الصفحة أين هو، وتعرف الآلة من الرمز أنّ الرابط خاطئ فلا تفهرسه.

شاشة هاتف بخلفيّةٍ كريميّة، في وسطها الرقم 404 كبيرًا بالأحمر، وتحته عنوان «هذه الصفحة غير موجودة»، ثمّ جملة «ربّما تغيّر الرابط، أو فيه حرفٌ زائد»، ثمّ رابطٌ أحمر «عُد إلى الصفحة الرئيسة».
صفحة 404 الخاصّة على الموقع المنشور كما تظهر على الهاتف: الرقم بلون الموقع، وجملةٌ تشرح ما حدث، ورابطٌ يعيد الزائر إلى الصفحة الرئيسة. لقطة من المتصفّح.

وفي هذا الملفّ تفصيلٌ صغير. فالتنسيق مكتوبٌ داخله في وسم style، ورابط العودة يبدأ باسم المستودع: /my-first-site/. والسبب أنّ الصفحة نفسها تُعرض لأيّ عنوانٍ خاطئ، مهما كان عمقه، فأيّ رابطٍ نسبيّ فيها قد يشير إلى مكانٍ مختلف في كلّ مرّة. وهذا يقودك مباشرةً إلى الخطأ الأشهر في النشر كلّه.

الخطأ الذي يكسر التنسيق: المسار المطلق

كثيرٌ من المبتدئين يرى صفحته على حاسوبه كاملة، ثمّ ينشرها فتظهر بيضاء بلا ألوان، والروابط زرقاء كأنّها من التسعينيّات. والسبب غالبًا حرفٌ واحد: شرطةٌ مائلة في أوّل رابط ملفّ التنسيق. وتشرح MDN القاعدة بجملةٍ واحدة: إن بدأ مسار الرابط بالشرطة المائلة، جلب المتصفّح الملفّ من جذر الخادم، من غير اعتبارٍ لمكان الصفحة التي فيها الرابط.[8]

شكل 2 أين يبحث المتصفّح عن style.css؟ صندوقٌ في الأعلى هو عنوان الصفحة /my-first-site/، ومنه سهمان. السهم الأيمن إلى الصندوق المميّز «رابطٌ نسبيّ»: الرابط style.css يصير /my-first-site/style.css ويجده الخادم برمز 200. والسهم الأيسر إلى «رابطٌ يبدأ بشرطة»: الرابط /style.css يصير /style.css في جذر النطاق، فلا يجد الخادم شيئًا ويردّ برمز 404. عنوان الصفحة /my-first-site/ رابطٌ نسبيّ href=style.css /my-first-site/style.css وجده الخادم: 200 رابطٌ يبدأ بشرطة href=/style.css /style.css لا شيء هنا: 404 أين يبحث المتصفّح عن style.css؟ صندوقٌ في الأعلى هو عنوان الصفحة /my-first-site/، وتحته حالتان. الأولى المميّزة «رابطٌ نسبيّ»: الرابط style.css يصير /my-first-site/style.css ويجده الخادم برمز 200. والثانية «رابطٌ يبدأ بشرطة»: الرابط /style.css يصير /style.css في جذر النطاق، فيردّ الخادم برمز 404. عنوان الصفحة /my-first-site/ رابطٌ نسبيّ href=style.css /my-first-site/style.css وجده الخادم: 200 رابطٌ يبدأ بشرطة href=/style.css /style.css لا شيء هنا: 404
الرابط نفسه بطريقتين من صفحةٍ عنوانها /my-first-site/: الرابط النسبيّ المميّز يُقرأ داخل مجلّد المشروع فيجده الخادم برمز 200، والرابط الذي يبدأ بشرطة يُقرأ من جذر النطاق فيردّ الخادم برمز 404.

وصفحتك ليست في جذر الخادم، فهي في المجلّد /my-first-site/ من نطاق kutaibashi.github.io. فالرابط النسبيّ style.css يُقرأ من المجلّد الذي فيه الصفحة، فيصير /my-first-site/style.css ويجده الخادم. أمّا الرابط /style.css فيُقرأ من جذر النطاق، حيث لا يوجد شيء. وعلى حاسوبك قد لا تلاحظ الفرق أبدًا، لأنّ الخادم المحلّيّ الذي تجرّب عليه يضع الصفحة غالبًا في جذره.

ولكي ترى الخطأ على الموقع الحقيقيّ لا في رسمٍ فقط، أُضيفت الشرطة عمدًا في الجلسة التالية ودُفع التعديل. ثمّ طلب curl الملفّين: الأوّل من جذر النطاق حيث ذهب المتصفّح يبحث، والثاني من مكانه الحقيقيّ. ثمّ عاد git revert عن الخطأ بالتزامٍ جديد، ودُفع هو أيضًا:

طرفيّة داكنة: git diff يُظهر سطر الرابط إلى ملفّ التنسيق يتغيّر من href=style.css بالأحمر إلى href=/style.css بالأخضر، ثمّ الالتزام والدفع، ثمّ curl على kutaibashi.github.io/style.css يردّ HTTP/2 404، وcurl على kutaibashi.github.io/my-first-site/style.css يردّ HTTP/2 200، ثمّ git revert --no-edit HEAD يصنع التزامًا عنوانه Revert، ثمّ git push.
الخطأ كلّه في جلسةٍ واحدة: git diff يُظهر الشرطة المضافة إلى رابط ملفّ التنسيق، ثمّ الدفع، ثمّ curl يجد الملفّ في جذر النطاق مفقودًا برمز 404 وفي مجلّد المشروع موجودًا برمز 200، ثمّ git revert يعكس الالتزام ويُدفع. لقطة شاشة من جهازي.

وبين الدفعتين عُرضت الصفحة المنشورة على الهاتف كما يراها أيّ زائر. في اليمين الصفحة قبل الخطأ، وفي اليسار بعده: المحتوى نفسه، والملفّ style.css نفسه على الخادم، لكنّ المتصفّح بحث عنه في المكان الخطأ فلم يجده، فعرض الصفحة بتنسيقه الافتراضيّ. ولاحظ في الصورة اليسرى رابط «انتقل إلى المحتوى» في أعلاها: هو رابط التجاوز الذي بُني في مقال إتاحة الويب. والتنسيق هو الذي يخفيه حتّى يصل إليه التركيز، فلمّا غاب التنسيق ظهر للجميع. والصفحة بلا تنسيق ما زالت صفحةً مقروءة، بعناوينها وقوائمها بالترتيب الصحيح، وهذه من ثمار الهيكل الدلاليّ:

شاشتا هاتف متجاورتان للصفحة نفسها. في اليمين الصفحة بتنسيقها: خلفيّة كريميّة، وروابط حمراء متجاورة، وزرّ بإطارٍ أحمر، وبطاقات بيضاء. وفي اليسار الصفحة بلا تنسيق: خلفيّة بيضاء، وروابط زرقاء في قائمةٍ منقّطة، وزرٌّ رماديّ عاديّ، وخطٌّ بلا تصميم، وقد ظهر في أعلاها رابط «انتقل إلى المحتوى» الذي يخفيه التنسيق عادةً.
الصفحة نفسها على الهاتف قبل الخطأ وبعده: في اليمين بتنسيقها، وفي اليسار بعد أن طلب المتصفّح ملفّ التنسيق من جذر النطاق فلم يجده، فظهرت بالتنسيق الافتراضيّ ومعها رابط التجاوز الذي يخفيه التنسيق عادةً. لقطة من المتصفّح.

والقاعدة العمليّة: في موقع المشروع اكتب روابط ملفّاتك نسبيّة دائمًا، بلا شرطةٍ في أوّلها. فالرابط النسبيّ يعمل على حاسوبك، ويعمل في المجلّد /my-first-site/، ويبقى يعمل إن نقلت الموقع يومًا إلى نطاقٍ خاصّ في جذره. أمّا إن رأيت صفحتك بيضاء بعد النشر، فافتح أدوات المطوّر في المتصفّح وانظر في تبويب الشبكة: ستجد الملفّ الذي طُلب من المكان الخطأ باللون الأحمر وبجانبه الرمز 404.

نطاقٌ باسمك بدل github.io

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

وخطوات الربط ثلاث. أوّلها في إعدادات Pages نفسها: تكتب نطاقك في خانة Custom domain وتضغط Save، فيضيف GitHub إلى جذر الفرع ملفًّا اسمه CNAME فيه اسم النطاق.[5] وثانيها عند مزوّد DNS: للنطاق الفرعيّ www سجلٌّ من نوع CNAME يشير إلى kutaibashi.github.io من غير اسم المستودع. وللنطاق الأساسيّ من غير www أربعة سجلّاتٍ من نوع A تشير إلى العناوين الأربعة التي رأيتها في dig:

185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

ويوصي التوثيق بإعداد الاثنين معًا، النطاق الأساسيّ وwww، فيحوّل GitHub أحدهما إلى الآخر تلقائيًّا. وقد يحتاج انتشار تغييرات DNS إلى 24 ساعة، فلا تقلق إن لم يعمل النطاق في الدقيقة الأولى.[5]

وثالثها الأمان. فحين يتحقّق GitHub من أنّ سجلّاتك صحيحة، يطلب شهادة TLS لنطاقك من Let’s Encrypt تلقائيًّا. ثمّ تفعّل خيار Enforce HTTPS فيتحوّل كلّ طلب HTTP إلى HTTPS، وقد يستغرق ظهور هذا الخيار 24 ساعة أيضًا.[6] وتعمل الشهادة هنا كما يشرحها مقال HTTPS وشهادات SSL، مع فرقٍ واحد: GitHub يجدّدها عنك.

ثمّ خطوةٌ يتجاهلها أغلب الشروح: تحقّق من ملكيّة النطاق في إعدادات حسابك على GitHub. فبعد التحقّق لا يستطيع أيّ حسابٍ آخر أن ينشر موقعًا على نطاقك أو على نطاقاته الفرعيّة المباشرة.[9] والخطر حقيقيّ: لو حذفت المستودع يومًا وبقيت سجلّات DNS تشير إلى GitHub، يستطيع غيرك أن يربط نطاقك بموقعه. ويحذّر التوثيق أيضًا من السجلّات العامّة مثل *.example.com، لأنّها تفتح الباب نفسه حتّى بعد التحقّق.

حدود الخدمة وما لا تصلح له

المجّانيّ له حدود، وهي معلنةٌ في صفحة حدود الخدمة.[10] فالموقع المنشور لا يتجاوز 1 GB، ويُنصح ألّا يتجاوزه المستودع أيضًا. وللموقع حدٌّ مرن من عرض النطاق مقداره 100 GB في الشهر، وحدٌّ مرن من 10 بناءات في الساعة، ويتوقّف النشر إن استغرق أكثر من 10 دقائق. وصفحة من ثلاثة ملفّات مثل صفحتك تقاس بالكيلوبايت، فهذه الحدود بعيدةٌ عنها جدًّا.

والأهمّ من الأرقام ما تمنعه الشروط. فالخدمة غير مخصّصة، ولا مسموح بها، لتشغيل عملٍ تجاريّ أو متجرٍ إلكترونيّ أو أيّ موقعٍ غرضه الأوّل تسهيل المعاملات التجاريّة أو بيع البرمجيّات خدمةً، كما تقول الشروط بنصّها. ولا تصلح لمعاملاتٍ حسّاسة مثل إرسال كلمات المرور أو أرقام البطاقات.[10] فإن كان مشروعك متجرًا، فمكانه استضافةٌ حقيقيّة أو منصّةٌ من النوع الذي يقارنه مقال منصّات بناء المواقع.

وتفصيلٌ عن الخصوصيّة يستحقّ أن تعرفه قبل أن تنشر. فحين يزور أحدٌ موقعك على GitHub Pages، يسجّل GitHub عنوان IP الخاصّ به ويحفظه لأغراض الأمان، سواءٌ كان الزائر مسجّلًا في GitHub أم لا.[1] وإن كان جمهورك في أوروبا فاذكر هذا في صفحة الخصوصيّة إن كانت لموقعك صفحةٌ منها.

البديل: شبكة Cloudflare

وليست GitHub الوحيدة التي تنشر المواقع الثابتة مجّانًا. فشركة Cloudflare، صاحبة شبكة توصيل المحتوى المعروفة باسمها، تقدّم خدمةً تفعل الشيء نفسه من مستودعك على GitHub أو GitLab. وهنا تفصيلٌ حديث تتجاهله الشروح القديمة: الخدمة التي اشتهرت باسم Cloudflare Pages لم تعد ما تنصح به الشركة للمشاريع الجديدة. فصفحة توثيقها، في نسختها المحدّثة في 25 آب 2026، تقول إنّ Workers تغطّي أغلب حالات Pages بميزاتٍ أوسع، وتطلب أن تبدأ المشاريع الجديدة عليها بدل Pages.[11]

والطريق من لوحة Cloudflare قريبٌ ممّا فعلته هنا: تختار من صفحة Workers & Pages إنشاء تطبيق، ثمّ استيراد مستودع. ثمّ تختار حساب Git والمستودع نفسه، وتضغط Save and Deploy، فيُنشر الموقع على نطاقٍ فرعيّ من workers.dev.[12] وإن لم يكن في مستودعك ملفّ إعداد، تتعرّف الأداة إلى الموقع الثابت من وجود index.html في مجلّده، وتفتح لك طلب سحب فيه الإعداد اللازم، مع معاينةٍ تجرّبها قبل الدمج.

ومجّانيّتها سخيّة في الملفّات الثابتة: طلبات الملفّات الثابتة مجّانيّة وبلا حدّ، والحدّ في الخطّة المجّانيّة 20,000 ملفّ في كلّ نسخة و25 MiB للملفّ الواحد.[13] فمتى تختارها بدل GitHub Pages؟ إن كان نطاقك مسجّلًا في Cloudflare أصلًا، أو كنت تعرف أنّك ستحتاج بعد قليل إلى شيفرةٍ صغيرة تعمل على الخادم، مثل نموذج تواصلٍ يرسل رسالةً إلى بريدك. أمّا لصفحتك الأولى، ومستودعها على GitHub، فأقصر طريقٍ هو الإعداد الذي فعّلته في دقيقة.

خلاصة عمليّة

ضع index.html في جذر مستودعٍ عامّ، واختر من Settings ثمّ Pages الفرع main والمجلّد الجذر، وانتظر أقلّ من دقيقة. تأكّد بـcurl من أنّ الردّ 200 وأنّ تاريخ آخر تعديلٍ هو دقيقة نشرك. اكتب روابط ملفّاتك نسبيّة بلا شرطةٍ في أوّلها، وضع في الجذر صفحة 404.html بروابط تبدأ باسم المستودع. وإن ربطت نطاقًا، فاضبط www وسجلّات A الأربعة، وفعّل Enforce HTTPS، وتحقّق من ملكيّة النطاق.

وصفحتك الآن على الويب فعلًا، بعنوانٍ يفتحه أيّ أحد، وكلّ ما فيها يجري في متصفّح الزائر. لكنّ المواقع التي تستعملها كلّ يوم تسأل خوادم أخرى عن البيانات: الطقس، والأسعار، وآخر الرسائل. وهذا الحوار بين صفحتك وخوادم غيرها له اسم، هو موضوع مقال واجهة برمجة التطبيقات، الخطوة التالية في السلسلة.

المصادر

  1. توثيق GitHub، «What is GitHub Pages?»: خدمة استضافة مواقع ثابتة تأخذ ملفّات HTML وCSS وJavaScript من مستودع على GitHub وتنشرها؛ موقع حسابٍ واحد في مستودع باسم owner.github.io، وموقع مشروعٍ لكلّ مستودع على owner.github.io/repositoryname؛ ويُسجَّل عنوان IP للزائر ويُحفظ لأغراض الأمان. قُرئ في 30 أيلول 2026.
  2. توثيق GitHub، «Creating a GitHub Pages site»: المستودع عامّ في GitHub Free، والموقع متاحٌ للجميع حتّى لو كان المستودع خاصًّا، والملفّ الأوّل index.html أو index.md أو README.md في أعلى مصدر النشر، وقد يستغرق ظهور التغييرات حتّى 10 دقائق، ولا تُدعم لغات الخوادم مثل PHP وRuby وPython.
  3. مايك لينكسفاير، «GitHub is enabling broader access for developers in Syria following new government trade rules»، مدوّنة GitHub، 4 أيلول 2025: مع تخفيف العقوبات وقيود التصدير عادت الميزات الخاصّة والمدفوعة متاحةً للمطوّرين في سوريا، وكان التعاون على المستودعات العامّة متاحًا دائمًا.
  4. توثيق GitHub، «Configuring a publishing source for your GitHub Pages site»: Settings ثمّ Pages ثمّ Deploy from a branch، والمجلّد جذر المستودع أو ‎/docs، وكلّ دفعٍ إلى الفرع يُنشر. ولقطة الخانة في المقال من مستودع توثيق GitHub برخصة CC BY 4.0.
  5. توثيق GitHub، «Managing a custom domain for your GitHub Pages site»: ملفّ CNAME في جذر الفرع عند النشر من فرع، وسجلّ CNAME للنطاق www إلى user.github.io بلا اسم المستودع، وسجلّات A إلى 185.199.108.153 و185.199.109.153 و185.199.110.153 و185.199.111.153، وقد يستغرق انتشار DNS وظهور Enforce HTTPS حتّى 24 ساعة، والتحذير من السجلّات العامّة.
  6. توثيق GitHub، «Securing your GitHub Pages site with HTTPS»: مواقع github.io المنشأة بعد 15 حزيران 2016 تُقدَّم عبر HTTPS تلقائيًّا، وللنطاق الخاصّ يطلب GitHub شهادةً من Let’s Encrypt بعد فحص DNS، وخيار Enforce HTTPS يحوّل طلبات HTTP إلى HTTPS.
  7. توثيق GitHub، «Creating a custom 404 page for your GitHub Pages site»: ملفٌّ اسمه 404.html أو 404.md في مصدر النشر يُعرض حين تُطلب صفحةٌ غير موجودة.
  8. موسوعة MDN، «What is a URL?»، قسم الروابط المطلقة والنسبيّة: إن بدأ مسار الرابط بالشرطة المائلة جلب المتصفّح المورد من جذر الخادم، من غير اعتبارٍ لسياق الصفحة الحاليّة.
  9. توثيق GitHub، «Verifying your custom domain for GitHub Pages»: التحقّق يمنع حسابات GitHub الأخرى من الاستيلاء على نطاقك ونطاقاته الفرعيّة المباشرة، وقد يقع الاستيلاء حين تحذف المستودع والنطاق ما زال مضبوطًا لـGitHub Pages.
  10. توثيق GitHub، «GitHub Pages limits»: لا يُسمح باستعمال الخدمة لتشغيل عملٍ تجاريّ أو متجرٍ إلكترونيّ أو بيع البرمجيّات خدمةً، ولا للمعاملات الحسّاسة؛ وحدٌّ للموقع المنشور 1 GB، وحدٌّ مرن لعرض النطاق 100 GB في الشهر، و10 بناءات في الساعة، ومهلة 10 دقائق للنشر.
  11. توثيق Cloudflare، «Cloudflare Pages»، آخر تحديث 25 آب 2026: تغطّي Workers أغلب حالات Pages بميزاتٍ أوسع، وهي المنصّة الأساسيّة لدى Cloudflare، فابدأ المشاريع الجديدة عليها.
  12. توثيق Cloudflare، «Builds» (آخر تحديث 22 أيلول 2026): ربط Worker جديد بمستودعٍ على GitHub أو GitLab من Import a repository، والمعاينة على workers.dev، وطلب سحبٍ للإعداد حين يغيب ملفّ الإعداد. و«Automatic configuration»: المواقع الثابتة تُكتشف من أيّ مجلّدٍ فيه index.html.
  13. توثيق Cloudflare، «Workers pricing»: طلبات الملفّات الثابتة مجّانيّة وبلا حدّ. و«Workers limits»: في الخطّة المجّانيّة 20,000 ملفّ ثابت لكلّ نسخة، و25 MiB للملفّ الواحد.

اترك تعليقاً

الحقول المميّزة بـ مطلوبة