كانت الأخطاء الساذجة تصل إلى مستودعنا: كيف أنقذتنا ‘خطافات Git’ من جحيم ‘لقد نسيت تشغيل المدقق’؟

يا جماعة الخير، بتذكر مرة من المرات، كنا بنص سباق مع الزمن (sprint) عشان نسلّم ميزة جديدة للعميل. ضغط الشغل كان عالي، والقهوة ما كانت تفارق مكاتبنا. في آخر يوم، وبعد سهرة طويلة من الكود، واحد من الشباب الطيبة في الفريق، شب شاطر ومجتهد، عمل push للكود تبعه على الفرع الرئيسي قبل ما يروح ينام.

تاني يوم الصبح، صحينا على “مصيبة”. الـ CI/CD pipeline ضارب أحمر، والـ build فاشل، والتطبيق على بيئة الاختبار (staging environment) واقع. بعد شوية حفر وتنقيب، اكتشفنا الكارثة: أخونا في الله كان ناسي فاصلة منقوطة (semicolon) في ملف JavaScript حساس، وكمان تارك وراه جيش من الـ console.log اللي كان يستخدمها للـ debugging.

لما سألته، حكالي جملته الشهيرة اللي صارت نكتة عنا في الفريق: “والله يا أبو عمر نسيت… نسيت أشغل الـ linter والـ formatter قبل ما أعمل commit. من العجلة والنعس، كبست ورفعت”.

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

ما هي خطافات Git (Git Hooks)؟

ببساطة شديدة، تخيل إنه عندك حارس أمن على باب المبنى تبعك. هالحارس عنده تعليمات واضحة: قبل ما أي شخص يفوت، لازم يتأكد من هويته، يتأكد إنه مش حامل أي شيء ممنوع، ويتأكد إنه ملتزم بقواعد اللباس. لو أي شرط من هاي الشروط ما تحقق، الحارس راح يمنعه من الدخول بكل حزم.

خطافات Git هي بالضبط هذا الحارس. هي عبارة عن نصوص برمجية (scripts) بتشتغل تلقائيًا عند نقاط معينة في دورة حياة Git. أشهر هاي النقاط هي:

• قبل الـ commit (pre-commit): الحارس بيفحص الكود قبل ما يتم تسجيله في تاريخ المشروع. هاي أفضل فرصة عشان نمسك أخطاء التنسيق (linting/formatting) أو الأخطاء البرمجية البسيطة.
• قبل الـ push (pre-push): الحارس بيفحص الكود قبل ما يتم رفعه للمستودع البعيد (like GitHub/GitLab). هاي فرصة ممتازة عشان نشغل الاختبارات (tests) ونتأكد إنه الكود الجديد ما كسر أي شيء قديم.
• عند كتابة رسالة الـ commit (commit-msg): الحارس بيتأكد إنه رسالة الـ commit تبعتك مطابقة لنسق معين (مثلاً، تبدأ بـ “feat:” أو “fix:”). هذا بخلي تاريخ المشروع مقروء ومنظم.

الفكرة هي أتمتة عمليات التحقق اللي كلنا بنعرف إنه لازم نعملها، بس أحيانًا بننساها أو بنتجاهلها “عشان مستعجلين”.

المشكلة مع الخطافات الأصلية: ليش مش عملية؟

ممكن حد يسأل: “طيب يا أبو عمر، هاي الخطافات موجودة في Git من زمان، ليش ما كنا نستخدمها؟”. سؤال وجيه. المشكلة إنه الطريقة التقليدية لإدارة الخطافات مزعجة جدًا. ملفات الخطافات بتعيش داخل مجلد .git/hooks. وهذا المجلد، بشكل مقصود من Git، لا يتم تعقبه في نظام إدارة الإصدارات. يعني، ما بنقدر نرفعه على GitHub.

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

Husky: صديقك الوفي لأتمتة خطافات Git

Husky هي أداة بسيطة وعبقرية بتحل مشكلة إدارة الخطافات. فكرتها الأساسية هي إنها بتسمحلك تعرف الخطافات تبعتك داخل ملفات إعدادات المشروع (زي package.json أو ملفات خاصة)، وهي الملفات اللي بنعملها version control بشكل طبيعي.

لما مطور جديد ينزل المشروع ويعمل npm install، Husky بتشتغل في الخلفية وبتثبت الخطافات دي تلقائيًا في مجلد .git/hooks عنده. هيك بنضمن إنه كل أعضاء الفريق، بدون استثناء، عندهم نفس الحراس ونفس قواعد التحقق على أجهزتهم. خلصنا من قصة “عندي بتشتغل!”.

خطوات عملية لتثبيت واستخدام Husky

يلا نشمر عن أيدينا ونشوف كيف بنركب هاي الأداة السحرية. راح أفترض إنه عندك مشروع Node.js جاهز مع package.json.

1. تثبيت Husky:

افتح الطرفية (terminal) في مجلد مشروعك واكتب الأمر التالي:

# باستخدام npm
npm install husky --save-dev

# أو باستخدام yarn
yarn add husky --dev

2. تفعيل Husky:

الآن، لازم نخلي Husky يجهز حاله ويضيف مجلده الخاص للمشروع. هذا الأمر بيعمل مجلد جديد اسمه .husky.

npx husky install

نصيحة من أبو عمر: عشان تضمن إنه Husky يشتغل عند أي مطور جديد بنزل المشروع، ضيف سكربت prepare لملف package.json تبعك. هذا السكربت بيشتغل تلقائيًا بعد عملية npm install.

"scripts": {
"prepare": "husky install"
}

3. إضافة أول خطاف (Hook):

لنفترض إنه بدنا نمنع أي عملية commit لو الاختبارات (tests) فاشلة. بنقدر نضيف خطاف pre-commit بسهولة:

npx husky add .husky/pre-commit "npm test"

هذا الأمر راح ينشئ ملف جديد اسمه pre-commit داخل مجلد .husky، ومحتواه بسيط: npm test. الآن، في كل مرة بتحاول تعمل git commit، راح يشتغل أمر npm test تلقائيًا. لو الاختبارات نجحت، الـ commit بيكمل. لو فشلت، الـ commit بيتوقف، وما بتقدر تكمل إلا لما تصلح الاختبارات.

الاستخدام الاحترافي: Husky + lint-staged

تشغيل الاختبارات على كل commit ممكن يكون بطيء ومزعج. والأكثر شيوعًا هو تشغيل الـ Linter (مثل ESLint) والـ Formatter (مثل Prettier). لكن تشغيلهم على كل ملفات المشروع في كل مرة هو مضيعة للوقت.

الحل الأمثل هو استخدام أداة اسمها lint-staged. هاي الأداة ذكية جدًا، بتسمحلك تشغل أوامر معينة فقط على الملفات اللي تم إضافتها للـ staging area (يعني الملفات اللي ناوي تعملها commit).

1. تثبيت lint-staged:

npm install lint-staged --save-dev

2. إعداد lint-staged:

ضيف إعداداتك في ملف package.json أو في ملف خاص. أنا بفضل package.json للمشاريع الصغيرة.

"lint-staged": {
  "*.{js,jsx,ts,tsx}": [
    "eslint --fix",
    "prettier --write"
  ],
  "*.{json,md,css}": "prettier --write"
}

هذا الإعداد معناه: لأي ملف JavaScript أو TypeScript في الـ staging area، شغل عليه eslint --fix (لإصلاح الأخطاء تلقائيًا) ثم prettier --write (لإعادة تنسيق الكود). ولباقي الملفات مثل JSON و CSS، شغل فقط Prettier.

3. ربط lint-staged مع Husky:

الآن، بدل ما نخلي خطاف الـ pre-commit يشغل npm test، بنخليه يشغل lint-staged. عدل الملف اللي أنشأناه سابقًا، أو أنشئه من جديد بهذا الأمر:

npx husky add .husky/pre-commit "npx lint-staged"

وهيك بنكون وصلنا للجنة! الآن، أي مطور في الفريق لما يجي يعمل commit:

1. Husky راح يشتغل تلقائيًا.
2. راح ينادي على lint-staged.
3. lint-staged راح تشوف الملفات اللي في الـ stage بس.
4. راح تطبق عليها الـ linter والـ formatter.
5. لو في أخطاء ما انحلت تلقائيًا، الـ commit راح يفشل والمطور راح يشوف رسالة الخطأ عشان يصلحها يدويًا.

وبهي الطريقة، بنضمن إنه ما في أي كود غير منسق أو فيه أخطاء linting واضحة بيوصل للمستودع. وداعًا لجملة “نسيت أشغل المدقق”! 🚀

الخلاصة ونصيحة أخيرة

يا جماعة، البرمجة مش بس كتابة كود، هي بناء أنظمة وعمليات بتساعدنا نكون أكثر انتاجية وأقل عرضة للخطأ. الاعتماد على الأدوات الذكية مثل Git Hooks و Husky مش رفاهية، بل هو ضرورة في الفرق الحديثة.

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

نصيحتي الأخيرة: استثمر في الأتمتة. أي مهمة بتلاقي حالك بتكررها يدويًا أكثر من مرتين، فكر كيف ممكن تعملها أتمتة. ابدأ اليوم، ضيف Husky و lint-staged لمشروعك القادم، وشوف الفرق بنفسك. يلا، شدّوا حيلكم! ✅