مستودعاتي كانت فوضى: كيف أنقذتني خطاطيف Git (Git Hooks) من جحيم الـ ‘commit’ الكارثي؟

ليلة الكود المشؤوم: “يا ويلي، شو اللي عملته!”

كنت أجلس في مكتبي، الساعة تقارب منتصف الليل، وأنا أعمل على إصلاح خطأ برمجي عاجل في أحد مشاريع الذكاء الاصطناعي الهامة. العيون تدمع من التعب، وكوب القهوة الرابع بجانبي فارغ. أخيراً، وبعد ساعات من البحث والتصحيح، وجدت الحل. بفرحة ممزوجة بالإرهاق، كتبت الأمر السحري بسرعة: git commit -am "fix the damn bug" ثم git push origin main. أغلقت حاسوبي وأنا أشعر بالرضا، وذهبت إلى النوم.

في صباح اليوم التالي، استيقظت على وابل من الرسائل على هاتفي. “أبو عمر، السيرفر واقع!”، “البيلد فشل!”، “ما الذي حدث للنظام؟”. فتحت الحاسوب على عجل وقلبي يدق بسرعة. نظرت إلى سجل الأخطاء، وكانت الصدمة: لقد نسيت حذف بعض أسطر الـ console.log التي استخدمتها لتصحيح الأخطاء، والأسوأ من ذلك، تركت متغيرًا حساسًا (API Key) مكشوفًا في الكود الذي قمت برفعه!

شعرت بالخجل والإحراج. خطأ بسيط كهذا كاد أن يسبب كارثة. في تلك اللحظة، قلت لنفسي: “لازم يكون في طريقة تمنع هاي الأخطاء السخيفة قبل ما تصير”. ومن هنا، بدأت رحلتي مع منقذي الصامت، “خطاطيف Git” أو Git Hooks.

ما هي خطاطيف Git (Git Hooks) يا أبو عمر؟

ببساطة يا جماعة الخير، خطاطيف Git هي عبارة عن سكربتات (نصوص برمجية) صغيرة تعمل تلقائيًا عند نقاط معينة في دورة حياة Git. فكر فيها كأنها “حارس شخصي” أو “مدقق آلي” لمستودع الكود الخاص بك. قبل أن تقوم بعمل commit أو push، يقوم هذا الحارس بفحص عملك بناءً على قواعد أنت تحددها. إذا كان كل شيء “تمام التمام”، يسمح لك بالمرور. أما إذا وجد مشكلة، فإنه يوقف العملية ويخبرك: “أوقف! في عندك مشكلة، صلحها ورجاع.”

نصيحة أبو عمر: أفضل تشبيه للـ Git Hooks هو “قائمة التحقق قبل الإقلاع” التي يستخدمها الطيارون. هل كل شيء في مكانه؟ هل الأنظمة تعمل؟ ممتاز، يمكنك الإقلاع الآن. هذا بالضبط ما تفعله الخطاطيف لمشروعك.

كيف تعمل هذه الخطاطيف؟ “فكّ الشيفرة”

الأمر أبسط مما تتخيل. في كل مستودع Git تقوم بإنشائه، يوجد مجلد مخفي اسمه .git. داخل هذا المجلد، ستجد مجلدًا آخر اسمه hooks. هذا هو “عش” الخطاطيف.

إذا نظرت داخل مجلد .git/hooks، ستجد مجموعة من الملفات التي تنتهي بـ .sample. هذه مجرد أمثلة. لتفعيل أي خطاف، كل ما عليك فعله هو:

  • إزالة لاحقة .sample من اسم الملف.
  • كتابة السكربت الذي تريده داخل هذا الملف.
  • التأكد من أن الملف قابل للتنفيذ (عبر الأمر chmod +x .git/hooks/your-hook-name).
  • هذه السكربتات يمكن أن تكون مكتوبة بأي لغة برمجة يفهمها نظام التشغيل لديك، مثل Bash, Python, Ruby, أو حتى JavaScript (باستخدام Node.js).

    أشهر الخطاطيف وأكثرها فائدة (مع أمثلة عملية)

    هناك العديد من الخطاطيف، لكن دعونا نركز على الأكثر عملية والتي ستغير طريقة عملك للأفضل.

    الخطاف pre-commit: حارسك الأول قبل الكارثة

    هذا هو الخطاف الأهم برأيي. يتم تشغيله بعد أن تكتب git commit وقبل أن يطلب منك كتابة رسالة الـ commit. إذا فشل هذا السكربت (أي أعاد قيمة خروج غير صفرية)، يتم إلغاء عملية الـ commit بأكملها.

    استخداماته العملية:

    • فحص جودة الكود (Linting): التأكد من أن الكود يتبع معايير التنسيق والجودة المتفق عليها في الفريق.
    • تنسيق الكود (Formatting): تشغيل أدوات مثل Prettier أو Black لتوحيد شكل الكود تلقائيًا.
    • تشغيل الاختبارات الوحدوية السريعة (Unit Tests): للتأكد من أنك لم تكسر أي وظيفة أساسية.
    • البحث عن كلمات حساسة: مثل “TODO”, “FIXME” أو حتى مفاتيح API عن طريق الخطأ.

    مثال: سكربت pre-commit لفحص وتنسيق الكود

    هذا مثال بسيط باستخدام سكربت Shell لمشروع JavaScript. قم بإنشاء ملف باسم pre-commit داخل .git/hooks وضع فيه الكود التالي:

    #!/bin/sh
    
    echo "يا جماعة الخير، جاري فحص الكود قبل الـ commit..."
    
    # 1. تشغيل الـ Linter (مثل ESLint)
    npm run lint
    if [ $? -ne 0 ]; then
      echo "❌ أوقف! في عندك أخطاء لينتنج (linting)، صلحها ورجاع."
      exit 1
    fi
    
    # 2. تشغيل الاختبارات الوحدوية
    npm test
    if [ $? -ne 0 ]; then
      echo "❌ الاختبارات فشلت! لا يمكنك عمل commit حتى تنجح جميع الاختبارات."
      exit 1
    fi
    
    echo "✅ كل شي تمام التمام، بتقدر تعمل commit هلقيت."
    exit 0
    

    لا تنسَ أن تجعل الملف قابلاً للتنفيذ: chmod +x .git/hooks/pre-commit. الآن، في كل مرة تحاول فيها عمل commit، سيتم تشغيل هذه الفحوصات تلقائيًا!

    الخطاف pre-push: آخر فرصة قبل “الفضيحة”

    يتم تشغيل هذا الخطاف بعد أن تكتب git push، ولكن قبل أن يتم إرسال أي شيء إلى المستودع البعيد (Remote Repository). هذه هي فرصتك الأخيرة لمنع وصول كود سيء إلى الفريق.

    استخداماته العملية:

    • تشغيل الاختبارات التكاملية (Integration Tests): هذه الاختبارات قد تكون أبطأ، لذا من الأفضل تشغيلها قبل الـ push وليس مع كل commit.
    • منع الـ Push المباشر على الفروع الرئيسية: مثل main أو master، لتشجيع استخدام الـ Pull Requests.

    مثال: سكربت pre-push لمنع الـ push على فرع main

    #!/bin/sh
    
    current_branch=$(git rev-parse --abbrev-ref HEAD)
    
    if [ "$current_branch" = "main" ] || [ "$current_branch" = "master" ]; then
      echo "✋ يا زلمة وين رايح؟! ممنوع تعمل push مباشرة على فرع $current_branch."
      echo "اعمل Pull Request لو سمحت، هاي الأصول."
      exit 1
    fi
    
    echo "جاري تشغيل الاختبارات النهائية قبل الـ push..."
    # ./run-integration-tests.sh # أمر تشغيل الاختبارات الطويلة
    
    if [ $? -ne 0 ]; then
      echo "❌ الاختبارات النهائية فشلت. لا يمكن إكمال عملية الـ push."
      exit 1
    fi
    
    exit 0
    

    الخطاف commit-msg: لرسائل commit احترافية

    يتم تشغيل هذا الخطاف بعد كتابة رسالة الـ commit وقبل إنشاء الـ commit فعليًا. يتيح لك فحص الرسالة أو تعديلها.

    استخداماته العملية:

    • فرض صيغة معينة لرسائل الـ commit: مثل صيغة “Conventional Commits” التي تسهل تتبع التغييرات وإنشاء سجلات التغيير (Changelogs) تلقائيًا.
    • إضافة رقم تذكرة (Ticket ID) تلقائيًا: إذا كان اسم الفرع يحتوي على رقم تذكرة من نظام مثل Jira.

    تحدي الإعداد اليدوي: كيف أشارك هذه الخطاطيف مع فريقي؟

    هنا تكمن مشكلة صغيرة: مجلد .git/hooks لا يتم تتبعه بواسطة Git، وهذا قرار تصميمي مقصود. يعني هذا أن الخطاطيف التي تعدها على جهازك ستبقى على جهازك فقط. فكيف نضمن أن كل أعضاء الفريق يستخدمون نفس الخطاطيف؟

    الحل ليس في نسخ ولصق الملفات يدويًا، بل في استخدام أدوات متخصصة تسهل هذه المهمة.

    أدوات لتسهيل المهمة: Husky و pre-commit

    هذه الأدوات هي الحل الاحترافي لمشاركة الخطاطيف وإدارتها ضمن الفريق.

    • Husky: أداة رائعة لمشاريع JavaScript/TypeScript. تقوم بتثبيتها عبر npm، وتتيح لك تعريف خطاطيفك مباشرة في ملف package.json أو في مجلد .husky يتم تتبعه مع المشروع. عندما يقوم أي مطور بتثبيت اعتماديات المشروع (npm install)، يقوم Husky تلقائيًا بإعداد الخطاطيف له.
    • pre-commit: إطار عمل مكتوب بلغة Python ولكنه متعدد اللغات (language-agnostic). تعرّف خطاطيفك في ملف .pre-commit-config.yaml. ميزته الكبرى هي وجود مستودع ضخم من الخطاطيف الجاهزة التي يمكنك استخدامها مباشرة لفحص ملفات JSON, YAML, Python, JavaScript وغيرها الكثير.

    نصيحة أبو عمر: أنا شخصيًا أميل لـ Husky في مشاريع الـ frontend والـ Node.js لسهولته وتكامله. أما في مشاريع البايثون والذكاء الاصطناعي والمشاريع متعددة اللغات، فأستخدم إطار pre-commit لأنه قوي وشامل ويوفر عليّ كتابة الكثير من السكربتات من الصفر.

    الخلاصة: خطاطيف Git ليست رفاهية، بل ضرورة! ✅

    في البداية، قد يبدو إعداد خطاطيف Git عملاً إضافيًا. لكن صدقني، هو استثمار صغير جدًا في الوقت سيوفر عليك وعلى فريقك ساعات لا تحصى من تصحيح الأخطاء السخيفة، والنقاشات حول تنسيق الكود، والمشاكل الناتجة عن commits غير مدروسة.

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

    نصيحتي الأخيرة لك: لا تنتظر حتى تقع في كارثة مثل التي وقعت بها. ابدأ اليوم. ابدأ بخطاف pre-commit بسيط لفحص جودة الكود. ستشكرني لاحقًا. 🚀

    أبو عمر

    سجل دخولك لعمل نقاش تفاعلي

    كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

    آراء من النقاشات

    لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

    آخر المدونات

    اختبارات الاداء والجودة

    تغطية اختباراتي 100% لكن الكود كان هشًا: كيف أنقذني الاختبار الطفري (Mutation Testing) من جحيم الثقة الزائفة؟

    كنت أظن أن تغطية الاختبار بنسبة 100% هي درع الأمان لكودي، لكني كنت مخطئًا. في هذه المقالة، أسرد لكم قصتي مع الثقة الزائفة وكيف كشف...

    5 أبريل، 2026 قراءة المزيد
    أتمتة العمليات

    خوادمنا كانت جزرًا معزولة: كيف أنقذني ‘الكود كبنية تحتية’ (IaC) من جحيم التكوين اليدوي؟

    أشارككم قصة حقيقية عن ليلة كابوسية انهارت فيها خوادمنا، وكيف كانت هذه الكارثة هي البداية لتبني مفهوم "الكود كبنية تحتية" (IaC). استكشفوا معي كيف حوّل...

    5 أبريل، 2026 قراءة المزيد
    ​معمارية البرمجيات

    خدماتي كانت متشابكة كخيوط العنكبوت: كيف أنقذتني ‘المعمارية الموجهة بالأحداث’ (EDA) من جحيم الاقتران المحكم؟

    أشارككم قصتي مع نظام برمجي كاد أن ينهار بسبب التشابك والاقتران المحكم بين خدماته. اكتشفوا كيف كانت المعمارية الموجهة بالأحداث (EDA) طوق النجاة الذي حوّل...

    5 أبريل، 2026 قراءة المزيد
    تجربة المستخدم والابداع البصري

    كل شاشة في تطبيقي كانت تبدو مختلفة: كيف أنقذني ‘نظام التصميم’ من جحيم إعادة اختراع العجلة؟

    أتذكر جيداً ذلك المشروع الذي كاد أن يودي بي إلى الجنون بسبب عدم اتساق التصميم. في هذه المقالة، أشارككم تجربتي الشخصية وكيف كان "نظام التصميم"...

    5 أبريل، 2026 قراءة المزيد
    برمجة وقواعد بيانات

    استعلاماتي كانت تزحف كالسلحفاة: كيف أنقذتني ‘فهارس قاعدة البيانات’ (Database Indexes) من جحيم الانتظار الطويل؟

    أشارككم قصتي مع استعلام SQL استغرق دقائق ليُنفّذ، وكيف تحول إلى أجزاء من الثانية بفضل الفهارس (Indexes). سنغوص في عالم فهارس قواعد البيانات، من هي؟...

    5 أبريل، 2026 قراءة المزيد
    الشبكات والـ APIs

    خدماتي المصغرة كانت فوضى: كيف أنقذتني ‘بوابة الواجهات البرمجية’ (API Gateway) من جحيم الإدارة؟

    أشارككم تجربتي الشخصية مع فوضى إدارة الخدمات المصغرة (Microservices) وكيف كانت بوابة الواجهات البرمجية (API Gateway) هي المنقذ الذي أعاد النظام والمنطق إلى بنيتي التحتية....

    5 أبريل، 2026 قراءة المزيد
    البودكاست