استخدام Git Hooks لأتمتة فحص وتنسيق الكود قبل أي عملية Push

عندما يكبر المشروع وتزداد سرعة التطوير، تصبح الأخطاء الصغيرة مثل نسيان تنسيق الملفات أو تمرير شيفرة غير متوافقة مع أدوات الفحص سبباً مباشراً في تعطيل مسارات CI/CD وإهدار وقت الفريق. هنا تظهر قوة Git Hooks كطبقة محلية ذكية تعمل قبل إرسال التغييرات إلى المستودع البعيد.

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

إذا كنت تبني ثقافة تطوير احترافية، فهذه الخطوة تُكمل ما شرحناه في مقال ما هو DevOps؟ ولماذا تدفع الشركات ثروات لمهندسي الأتمتة السحابية؟، كما تتكامل مباشرة مع ممارسات استراتيجيات العمل الجماعي: نظام GitHub Flow وكيف تعمل الشركات الكبرى؟.

ما هي Git Hooks ولماذا هي مهمة في المشاريع الجادة؟

Git Hooks هي سكربتات ينفذها Git تلقائياً عند حدوث أحداث محددة مثل pre-commit وpre-push. الهدف منها هو تنفيذ قواعد تلقائية دون انتظار مراجعة بشرية متأخرة.

في البنية الهندسية الحديثة، يتم توزيع مسؤولية الجودة على أكثر من طبقة: جهاز المطور، مستودع الشيفرة، وأنظمة البناء. لذلك فإن hooks المحلية لا تلغي دور الخادم، لكنها تقلل الضجيج داخل أنظمة مثل Jenkins أو GitHub Actions.

أهم الفوائد العملية

• منع رفع ملفات غير منسقة أو غير صالحة للاختبارات الأولية.
• تقليل عدد مرات فشل pipeline بسبب أخطاء بسيطة.
• توحيد معايير التنسيق داخل الفريق دون نقاشات متكررة.
• تسريع مراجعة Pull Request لأن المراجعة تنتقل من الشكل إلى المنطق.

الفرق بين pre-commit وpre-push

خطاف pre-commit يعمل قبل إنشاء الالتزام نفسه، ولذلك يناسب مهاماً سريعة مثل فحص المسافات البيضاء أو تشغيل منسق الشيفرة. أما pre-push فيعمل قبل إرسال التغييرات إلى المستودع البعيد، وهو مناسب لاختبارات أثقل مثل unit tests أو فحص البناء.

اختيار المكان الصحيح مهم جداً. وضع اختبارات طويلة داخل pre-commit قد يزعج المطورين ويشجعهم على تعطيل الخطاف. أما نقل كل شيء إلى pre-push فقد يسمح بتراكم أخطاء محلية قبل اكتشافها.

إعداد خطاف pre-push لفحص وتنسيق الكود

توجد الخطافات داخل المجلد .git/hooks. غالباً ستجد ملفات نموذجية تنتهي بالامتداد .sample. المطلوب هو إنشاء ملف باسم pre-push ومنحه صلاحية التنفيذ.

1. ادخل إلى مجلد المشروع.
2. أنشئ ملف الخطاف.
3. أضف أوامر الفحص والتنسيق.
4. اجعل الملف قابلاً للتنفيذ.

mkdir -p .git/hooks
cat > .git/hooks/pre-push <<'EOF'
#!/usr/bin/env bash

set -e

echo "Running formatter..."
npm run format

echo "Running linter..."
npm run lint

echo "Running tests..."
npm test

echo "All checks passed. Proceeding with push."
EOF

chmod +x .git/hooks/pre-push

هذا المثال يفترض أن المشروع يستخدم Node.js وأن الأوامر معرفة داخل ملف package.json. عند فشل أي أمر، سيمنع Git عملية push تلقائياً.

مثال على أوامر المشروع داخل package.json

{
  "scripts": {
    "format": "prettier --write .",
    "lint": "eslint .",
    "test": "npm run test:unit"
  }
}

كيف نجعل الخطافات قابلة للمشاركة داخل الفريق؟

المشكلة المعروفة أن مجلد .git/hooks لا يُرفع إلى المستودع عادة. لذلك من الأفضل حفظ الخطافات داخل مجلد إصدار مثل githooks/ ثم ربطه عبر إعداد core.hooksPath.

mkdir -p githooks

cat > githooks/pre-push <<'EOF'
#!/usr/bin/env bash
set -e

echo "Checking staged project before push..."
npm run format
npm run lint
npm test
EOF

chmod +x githooks/pre-push
git config core.hooksPath githooks

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

لا تعتمد على Git Hooks المحلية وحدها لحماية الإنتاج. المطور يستطيع تجاوزها باستخدام --no-verify، لذلك يجب أن تبقى اختبارات الخادم وسياسات Branch Protection وعمليات المراجعة الإلزامية طبقة أمنية أساسية لا يمكن تجاوزها.

أفضل الممارسات المعمارية عند ربط Git Hooks مع CI/CD

المعماريات الناضجة لا تكرر نفس الحمل الثقيل في كل نقطة. الأفضل هو توزيع المسؤوليات بذكاء: تنسيق سريع وفحص أساسي محلياً، ثم اختبارات أشمل داخل CI. هذا يمنع استهلاك وقت المطور بلا داعٍ ويحافظ على موثوقية خط النشر.

• pre-commit للمهام الخفيفة جداً.
• pre-push للفحوص المنطقية متوسطة الزمن.
• CI pipeline لاختبارات التكامل والبناء والحزم.
• CD للنشر بعد اجتياز جميع الضوابط.

هذا النهج مهم جداً في التطبيقات التي تُبنى داخل حاويات. فإذا كنت تعتمد على بيئات موحدة باستخدام Docker، فربط الفحوص المحلية مع الحاوية التطويرية يحل مشكلة اختلاف البيئة التي ناقشناها في مقال مشكلة “الكود يعمل على جهازي فقط” وكيف يحلها Docker نهائياً؟.

أخطاء شائعة يجب تجنبها

تشغيل أوامر تعدّل الملفات أثناء push دون تنبيه

عند استخدام منسقات مثل Prettier داخل pre-push، قد يتم تعديل الملفات بعد آخر commit. الأفضل إما إيقاف العملية مع رسالة واضحة، أو استخدام التنسيق في pre-commit.

إطالة زمن التنفيذ بشكل يضر بالإنتاجية

إذا استغرق الخطاف عدة دقائق في كل مرة، فسيبحث المطورون عن طرق لتجاوزه. اجعل الفحوص المحلية انتقائية وسريعة، وانقل الاختبارات الثقيلة إلى الخادم.

عدم توثيق آلية التثبيت

أي مشروع احترافي يحتاج ملف توثيق يشرح كيفية تفعيل hooks، خاصة عند العمل على فرق متعددة الأنظمة أو عند إدارة الفروع كما شرحنا في ما وراء الالتزام (Commit): كيف تدير فروع المشروع (Branches) باحترافية؟.

لا تضع أسراراً مثل مفاتيح API أو بيانات SSH داخل ملفات الخطافات. يجب أن تبقى هذه الملفات آمنة وقابلة للمراجعة، وأن تعتمد على متغيرات بيئية أو أدوات أسرار مخصصة بدلاً من القيم الصلبة.

خاتمة

استخدام Git Hooks ليس ترفاً تنظيمياً، بل خطوة هندسية ذكية لتقليل الأخطاء قبل أن تنتقل إلى المستودعات البعيدة أو أنابيب النشر. عند تصميمها بشكل متوازن، ستمنح فريقك جودة أعلى، مراجعات أسرع، وفشلاً أقل داخل أنظمة CI/CD.

ابدأ بخطاف بسيط يفحص التنسيق وlint والاختبارات السريعة، ثم وسّعه تدريجياً حسب حجم المشروع ونضج الفريق. بهذه المنهجية يتحول push من مجرد إرسال كود إلى نقطة تحكم جودة حقيقية.