Git وGitHub للمبتدئين: إدارة إصدارات مشاريع الويب خطوة بخطوة
دليل عملي لفهم Git وGitHub وبناء سير عمل بسيط لحفظ تغييرات مشاريع الويب، إنشاء الفروع، مزامنة العمل وفتح Pull Request.
ما الفرق بين Git وGitHub؟
يسجل Git تاريخ التعديلات على المشروع محليًا، ويتيح لك الرجوع إلى إصدارات سابقة ومراجعة ما تغيّر. أما GitHub فهو خدمة عبر الإنترنت تستضيف مستودعات Git وتسهّل مشاركة العمل ومراجعته. يمكنك استخدام Git وحده، لكن ربطه بـGitHub مفيد للاحتفاظ بنسخة بعيدة والتعاون مع الآخرين.
مصطلحات Git التي تحتاجها أولًا
- Repository: مجلد المشروع مع تاريخ التغييرات الذي يديره Git.
- Commit: لقطة موصوفة من تغييرات تريد تسجيلها في التاريخ.
- Branch: مسار مستقل للعمل على ميزة أو إصلاح دون تغيير الفرع الأساسي مباشرة.
- Remote: مستودع بعيد مرتبط بالمشروع المحلي، وغالبًا يكون على GitHub.
- Push: إرسال الـcommits المحلية إلى المستودع البعيد.
- Pull: جلب ودمج التغييرات من المستودع البعيد إلى العمل المحلي.
- Pull Request: طلب لمراجعة تغييرات فرع قبل دمجها في فرع آخر على GitHub.
إنشاء أول مستودع Git
بعد تثبيت Git، انتقل إلى مجلد مشروعك ثم نفّذ git init. بعدها استخدم git status لمعرفة الملفات التي تغيرت، وgit add لاختيار ما سيدخل في الـcommit، ثم git commit لتسجيل التغيير.
git init
git status
git add .
git commit -m "Initial project"اكتب رسالة commit توضّح ما أنجزته؛ فالرسائل المحددة أسهل في المراجعة من عبارات عامة مثل "update" أو "changes".
ربط المشروع بـGitHub
أنشئ مستودعًا جديدًا على GitHub، ثم اربطه بالمشروع المحلي عبر remote. المثال التالي يستخدم اسم origin وهو الاسم الشائع للمستودع البعيد.
git remote add origin https://github.com/USERNAME/REPOSITORY.git
git branch -M main
git push -u origin mainبدّل الرابط التجريبي بعنوان مستودعك الحقيقي. واحرص على عدم تضمين كلمات المرور أو مفاتيح API في ملفات المشروع أو سجل commits.
لماذا نستخدم Branch؟
بدلًا من إجراء جميع التعديلات على main، أنشئ فرعًا مستقلًا للميزة أو الإصلاح. يساعدك ذلك على إبقاء الفرع الأساسي مستقرًا ومراجعة التغييرات قبل دمجها.
git switch -c feature/contact-form
# عدّل الملفات واختبرها
git add .
git commit -m "Add contact form"
git push -u origin feature/contact-formكيف يعمل Pull Request؟
بعد رفع الفرع إلى GitHub، يمكنك فتح Pull Request من فرع الميزة إلى main. أضف وصفًا يشرح ما تغير، وما الذي اختبرته، وأي نقاط تحتاج مراجعة. بعد المراجعة والاختبارات يمكن دمج التغيير ثم حذف الفرع إذا لم تعد تحتاجه.
متى تستخدم clone وpull؟
استخدم git clone للحصول على نسخة محلية من مستودع قائم. أما إذا كان المستودع موجودًا على جهازك وتريد جلب تحديثات الفريق ودمجها، فاستخدم git pull بعد التحقق من حالة الملفات المحلية.
git clone https://github.com/USERNAME/REPOSITORY.git
cd REPOSITORY
git pullسير عمل بسيط لمشروع ويب
- اسحب آخر تغييرات من الفرع الأساسي عند الحاجة.
- أنشئ branch باسم يصف المهمة.
- عدّل الملفات واختبر الموقع محليًا.
- سجّل تغييرات صغيرة وواضحة في commits.
- ارفع الفرع إلى GitHub.
- افتح Pull Request وراجع التغييرات.
- ادمج التغيير بعد اكتمال المراجعة والاختبارات.
أخطاء شائعة عند البداية
- العمل مباشرة على
mainفي كل مهمة. - إنشاء commit واحد ضخم يحتوي تغييرات غير مترابطة.
- رفع ملفات سرية مثل مفاتيح API أو ملفات إعداد محلية.
- استخدام
git add .دون مراجعة ما سيُسجّل في المشروع. - سحب تغييرات جديدة مع وجود عمل محلي غير محفوظ دون فهم حالة الشجرة.
قبل أي خطوة قد تؤثر في عملك، افحص الملفات باستخدام git status واطّلع على تفاصيل التعديلات بواسطة git diff.
Git وGitHub عند نشر موقعك
يتولى Git تتبّع تطور المشروع، بينما يوفّر GitHub مكانًا مركزيًا لاستضافة المستودع ومراجعة التغييرات. وإذا كانت خطوتك التالية هي نشر موقع ثابت على GitHub Pages، فراجع دليل نشر الموقع على GitHub Pages؛ ذلك المقال يركز على النشر والاستضافة، وليس على أساسيات Git.
الخلاصة
ليس عليك حفظ عدد كبير من أوامر Git منذ اليوم الأول. ابدأ بفهم التسلسل الأساسي: عدّل الملفات، افحص status، أضف التغييرات، أنشئ commit، ثم استخدم branch وpush وPull Request عند التعاون. ومع الممارسة ستصبح إدارة إصدارات مشروعك جزءًا طبيعيًا من سير العمل.
مصادر وروابط موثوقة
سير عمل آمن للتغييرات
ابدأ من نسخة حديثة من الفرع الرئيسي، وأنشئ فرعًا باسم يوضح المهمة، ثم اجعل كل commit صغيرًا ومرتبطًا بهدف واحد. قبل الحفظ راجع git status وgit diff للتأكد من عدم إضافة ملفات سرية أو تغييرات غير مقصودة.
git status
git switch -c feature/update-readme
git diff
git add README.md
git commit -m "docs: update project guide"
git push -u origin feature/update-readmeالأوامر مثال توضيحي. لا تستخدم git push --force كحل افتراضي، ولا تضع مفاتيح API أو ملفات إعدادات خاصة في المستودع. استخدم pull request للمراجعة وتشغيل الاختبارات قبل الدمج.
عند حدوث تعارض
- اقرأ مقاطع التعارض وحدد التغيير الصحيح من كل طرف.
- احذف علامات التعارض بعد حلها ثم شغّل الاختبارات.
- راجع سجل commits قبل الدمج حتى تكون التغييرات مفهومة.
سير عمل آمن للتغييرات الصغيرة
قبل تعديل المشروع، تأكد من الفرع الحالي ونظافة شجرة العمل. أنشئ فرعًا باسم يصف المهمة، ثم اجعل كل commit يمثل تغييرًا يمكن شرحه ومراجعته. قبل فتح Pull Request، راجع الملفات المتغيرة وتأكد من عدم إدراج أسرار أو ملفات بناء مؤقتة.
git status
git switch -c docs/update-guide
# عدّل الملفات ثم راجع التغيير
git diff
git add articles/example.html
git commit -m "Improve practical guide"
git push -u origin docs/update-guideالأوامر مثال توضيحي؛ غيّر اسم الفرع والملف وفق مشروعك. بعد دفع الفرع، افتح PR يوضح المشكلة والتغيير والاختبارات التي أجريتها. إذا ظهر تعارض، حدّث فرعك بحذر وراجع diff النهائي قبل الدمج.
سير عمل Git آمن للمشاريع الصغيرة
يساعد Git على حفظ تاريخ التغييرات ومراجعتها والعودة إلى نسخة سابقة عند الحاجة. فائدته لا تقتصر على النسخ الاحتياطي؛ إذ يتيح العمل في فرع منفصل، ومناقشة التغيير قبل الدمج، ومعرفة الملف الذي تغير وسبب التغيير.
| الخطوة | الغرض | ما يجب مراجعته |
|---|---|---|
| status | معرفة الملفات المعدلة | عدم إضافة ملفات غير مقصودة |
| diff | قراءة التغييرات قبل الحفظ | عدم تضمين أسرار أو تغييرات جانبية |
| commit | حفظ وحدة تغيير مفهومة | رسالة تصف السبب بوضوح |
| branch | عزل العمل عن الفرع الرئيسي | أن يبدأ من النسخة الصحيحة |
| pull request | مراجعة التغيير قبل الدمج | الاختبارات والملفات المتأثرة |
اجعل كل commit مفهومًا
يفضل أن يحتوي commit على تغيير مترابط يمكن شرحه بجملة واحدة. تجنب جمع تنسيق شامل وإصلاح bug وتحديث محتوى في commit واحد إذا كانت المراجعة ستصبح أصعب. قبل الحفظ، استخدم diff لمراجعة كل سطر وتأكد من عدم إدراج ملفات البناء أو بيانات البيئة أو ملفات مؤقتة.
حل تعارضات الدمج بحذر
يحدث التعارض عندما يتغير الجزء نفسه في فرعين. لا تحذف علامات التعارض آليًا دون فهم التغييرات؛ اقرأ النسختين وحدد السلوك الذي ينبغي الحفاظ عليه، ثم شغّل الاختبارات بعد الحل. إذا لم تكن متأكدًا، اطلب مراجعة بدل اختيار نسخة لمجرد أنها أحدث.
حماية الأسرار
لا تحفظ كلمات المرور أو مفاتيح API أو رموز الوصول في المستودع. إذا تسرب سر إلى commit، فحذف السطر في commit لاحق لا يلغي احتمال بقائه في التاريخ؛ ينبغي إبطال السر من الجهة المصدرة ومعالجة التاريخ وفق سياسة المشروع. استخدم ملفات إعداد محلية مستثناة من Git، مع توثيق أسماء المتغيرات المطلوبة دون قيمها.
قائمة قبل طلب المراجعة
- الفرع يبدأ من النسخة المقصودة.
- diff لا يحتوي تغييرات غير مرتبطة.
- الاختبارات أو الفحوصات ذات الصلة ناجحة.
- وصف طلب المراجعة يشرح الهدف والمخاطر.
- لا يوجد سر أو بيانات شخصية ضمن الملفات.
راجع مقدمة Git في GitHub Docs ودليل Pull Requests لتطبيق سير عمل واضح.
سير عمل آمن للتعاون باستخدام Git وGitHub
يصبح Git أكثر فائدة عندما يتفق الفريق على طريقة واضحة للعمل، لا عندما يكتفي كل شخص بتنفيذ أوامر منفصلة. ابدأ بتحديث الفرع الأساسي، ثم أنشئ فرعًا قصير العمر باسم يوضح المهمة. اجعل كل commit يمثل تغييرًا منطقيًا صغيرًا، واكتب رسالة تصف السبب أو السلوك الذي تغير بدل عبارات عامة مثل «تعديلات». هذا التنظيم يسهل مراجعة التاريخ ومعرفة التغيير الذي أدخل مشكلة لاحقًا.
قبل فتح Pull Request
راجع git status للتأكد من الملفات التي ستدخل في commit، وافحص git diff بحثًا عن أسرار أو ملفات ناتجة عن البناء أو تعديلات غير مقصودة. شغّل الاختبارات والفحوصات التي يحددها المشروع، ثم اكتب وصفًا يوضح المشكلة والحل وطريقة التحقق وأي مخاطر معروفة. أرفق لقطات شاشة عندما يتغير السلوك المرئي، لكن لا تستخدمها بديلًا عن شرح التغيير.
حل التعارضات دون فقدان العمل
عند حدوث تعارض، لا تستبدل الملف كاملًا بأحد الطرفين قبل فهم الاختلاف. افتح علامات التعارض، وحدد المقاطع التي يجب دمجها، ثم احذف العلامات وشغّل الاختبارات بعد الحل. إذا كان التغيير يمس ملفًا مشتركًا أو بنية بيانات، تواصل مع صاحب التغيير الآخر بدل التخمين. يمكن أن يساعد commit صغير قبل إعادة التنظيم في جعل التراجع أسهل.
احمِ بيانات المستودع
لا ترفع ملفات البيئة أو كلمات المرور أو مفاتيح الخدمات إلى مستودع عام. استخدم ملف تجاهل مناسبًا، لكن تذكر أن إضافة ملف إلى ignore لا تزيله إذا سبق تتبعه؛ عند تسريب سر، ألغِه ودوّره فورًا. راجع صلاحيات أعضاء المستودع، وفعّل مراجعة التغييرات وحماية الفرع حيث تتاح. تعامل مع أي نص أو شيفرة قادمة من مساهم خارجي كمدخل يحتاج إلى مراجعة.
للتفاصيل العملية راجع توثيق GitHub للتعاون عبر Pull Requests وكتاب Pro Git. الهدف ليس اتباع طقوس ثابتة، بل جعل كل تغيير مفهومًا وقابلًا للاختبار والتراجع.
الخلاصة
الخلاصة: اعمل في فروع منفصلة، وراجع diff قبل commit، واكتب وصفًا واضحًا لطلب المراجعة. Git يساعد على التتبع والتراجع، لكنه لا يحمي الأسرار إذا أودعتها في المستودع.