دورة حياة الكود داخل GitHub

GitHub من منظور عملي: أكثر من مجرد مستودع كود

كثير يتعامل مع GitHub على أنه مكان يرفع فيه الكود وخلاص. لكن مع الوقت تكتشف أن الموضوع أعمق من “رفع مشروع”. هو بيئة كاملة لإدارة الكود، تتبع التغييرات، مراجعة العمل، وأتمتة النشر.

في هذا المقال سأربط المفاهيم بالخطوات العملية الفعلية التي تطبقها يوميًا داخل GitHub.

---

1) Git vs GitHub: التطبيق الفعلي

Git يشتغل محليًا. GitHub هو المكان الذي تدفع إليه عملك.

السيناريو العملي:

git init
git add .
git commit -m "Initial commit"
git remote add origin https://github.com/username/project.git
git push -u origin main

هنا:

• أنشأت مستودع محلي
• ربطته بـ GitHub
• دفعت الكود

الفرق يصبح واضحًا: Git يدير التاريخ، GitHub ينشره ويتابع التعاون حوله.

---

2) Repository عمليًا: ماذا يحدث بعد كل Commit؟

كل Commit يسجل:

• التغييرات الدقيقة
• الوقت
• المطور
• رسالة توضح السبب

عرض التاريخ:

git log --oneline
git show commit_hash

عمليًا هذا يعني أنك تستطيع:

• الرجوع لأي نسخة سابقة
• مقارنة تغييرات بين إصدارين
• معرفة من تسبب في Bug معين

---

3) الفروع: أسلوب عمل وليس أمر تقني

بدل تعديل main مباشرة:

git checkout -b feature-login

تعمل على ميزة مستقلة. بعد الانتهاء:

git push origin feature-login

ثم تفتح Pull Request من GitHub.

عمليًا هذا يمنع:

• كسر الكود الأساسي
• إدخال ميزة غير مكتملة

---

4) Pull Requests عمليًا

عند فتح Pull Request يمكنك:

• مقارنة الفروقات (Diff View)
• إضافة تعليق على سطر محدد
• طلب تغييرات (Request Changes)
• الموافقة (Approve)

في الفرق الاحترافية:

• لا يتم الدمج بدون مراجعة
• لا يتم الدمج بدون نجاح الاختبارات

يمكنك تفعيل Branch Protection:

• منع push مباشر على main
• إجبار وجود Review
• إجبار نجاح CI

---

5) Issues: تتبع العمل بشكل عملي

بدل إرسال رسالة تقول “في مشكلة في تسجيل الدخول”، تفتح Issue:

• عنوان واضح
• خطوات إعادة الخطأ
• النتيجة المتوقعة
• النتيجة الحالية

ثم تربطها بالفرع:

Fixes #12

بمجرد دمج الـ Pull Request يتم إغلاق الـ Issue تلقائيًا.

---

6) GitHub Projects (إدارة العمل كلوحة مهام)

يمكنك استخدام GitHub Projects لتحويل Issues إلى:

• To Do
• In Progress
• Done

هذا يحول GitHub من مستودع كود إلى أداة إدارة مشروع كاملة.

---

7) GitHub Actions عمليًا (CI/CD)

ملف workflow بسيط لاختبار مشروع Laravel:

name: Laravel CI

on:
  push:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Dependencies
        run: composer install
      - name: Run Tests
        run: php artisan test

الآن:

• أي push على main يشغل الاختبارات
• لو فشلت، يظهر ذلك في Pull Request
• يمكن منع الدمج حتى النجاح

هذا يجعل الجودة جزءًا من النظام وليس قرارًا بشريًا فقط.

---

8) Releases & Tags

لإنشاء إصدار رسمي:

git tag v1.0.0
git push origin v1.0.0

ومن GitHub يمكنك إنشاء Release:

• إضافة ملاحظات الإصدار
• إرفاق ملفات
• توثيق التغييرات

هذا مهم في:

• المكتبات
• المشاريع المفتوحة
• الإصدارات الإنتاجية

---

9) Secrets و Environment Variables

بدل تخزين مفاتيح API داخل الكود:

• Settings → Secrets → Actions
• إضافة متغيرات سرية

ثم استخدامها داخل workflow:

env:
  API_KEY: ${{ secrets.API_KEY }}

بهذا الشكل:

• لا ترفع أسرار للمستودع
• تحافظ على أمان المشروع

---

10) إدارة الصلاحيات عمليًا

يمكنك تحديد:

• Read
• Write
• Maintain
• Admin

في المشاريع الحساسة:

• المطور العادي لا يملك صلاحية حذف المستودع
• لا يملك صلاحية تغيير Branch Protection

التوزيع الصحيح للصلاحيات يقلل الأخطاء البشرية.

---

11) GitHub كمحفظة تقنية حقيقية

المستودع الجيد يحتوي:

• README واضح
• تنظيم ملفات نظيف
• Commits مفهومة
• Issues مرتبة
• Pull Requests موثقة

هذه ليست تفاصيل شكلية. هي تعكس طريقة تفكيرك كمطور.

---

الخلاصة

GitHub ليس مكانًا لرفع الكود فقط. هو نظام إدارة عمل كامل:

• Version Control
• Collaboration
• Code Review
• CI/CD
• Project Tracking

عندما تستخدم كل هذه الطبقات، يتحول المشروع من “ملفات” إلى نظام هندسي متكامل.