التزاماتي البرمجية كانت قنابل موقوتة: كيف أنقذتني خطافات Git (Git Hooks) من جحيم كسر البناء الرئيسي؟

يا أهلاً وسهلاً فيكم يا جماعة، معكم أخوكم أبو عمر.

خلوني أحكيلكم قصة صارت معي قبل كم سنة، قصة علّمتني درس ما بنساه للممات. كنا شغالين على مشروع كبير ومهم، وكان موعد التسليم قريب والضغط “للركب”. في ليلة من الليالي، كنت سهران بالمكتب بخلص تعديلات ضرورية على ميزة أساسية في النظام. الساعة صارت ٢ بعد نص الليل، عيوني صارت تزغلل من التعب، بس الحمد لله خلصت الشغل. بكل ثقة، فتحت الطرفية (Terminal) وكتبت الأوامر اللي كلنا حافظينها عن غيب:

git add .
git commit -m "Final touches on the new feature"
git push origin main

سكرت اللابتوب وروّحت عالبيت وأنا حاسس حالي “أبو العرّيف”، منجز ومخلص شغلي. نمت وأنا بحلم بالتقدير اللي رح أحصل عليه ثاني يوم.

صحيت الصبح على صوت تلفوني برن بشكل هستيري. على الخط كان مدير المشروع، صوته معصّب لدرجة حسيت حرارة التلفون ارتفعت. “أبو عمر! شو عامل؟! النظام كله واقع! البناء (Build) مكسور وما حدا قادر يشتغل!”.

قلبي وقع بين رجليي. فتحت اللابتوب بسرعة البرق لألاقي مصيبة. التزامي (commit) الأخير كان فيه سطر console.log("test") نسيته في ملف جافاسكريبت حساس، وهذا السطر تسبب بفشل أداة تنسيق الكود (Linter) في بيئة التكامل المستمر (CI/CD)، وبالتالي فشل البناء بأكمله وتوقّف النشر على البيئة التجريبية. فريق كامل من المطورين والمختبرين قعدوا مكتفين إيديهم ساعتين كاملات بس بسببي أنا وبسبب سطر برمجي تافه نسيته من التعب.

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

ما هي خطافات Git (Git Hooks) أصلاً؟

ببساطة شديدة، تخيل إنه عندك حارس شخصي ذكي واقف على باب مكتبك. كل ما تحاول تطلع من المكتب (تعمل git commit) أو تسلّم ملفاتك للمدير (تعمل git push)، هالحارس بوقفك وبقلك: “لحظة يا صاحبي، وين رايح؟ ورجيني شو معك”.

بعدين بيمسك ملفاتك وبشيك عليها حسب قائمة مهام معينة: هل الكود منسّق؟ هل في أخطاء إملائية؟ هل نسيت أي أوامر طباعة مؤقتة؟ هل الوحدات الاختبارية (Unit Tests) بتشتغل صح؟

إذا كل شي تمام، بقلك: “اتفضل، طريقك خضرا”. أما إذا لقى مشكلة، بمنعك من الخروج (بيلغي الـ commit) وبقلك: “ارجع صلح مشاكلك بالأول بعدين تعال”.

هذا الحارس الذكي هو تماماً ما تفعله خطافات Git. هي عبارة عن سكربتات (ملفات برمجية) بسيطة بتشتغل تلقائياً عند مراحل معينة من عملية Git. مكانها بيكون داخل مشروعك في مجلد مخفي اسمه .git/hooks.

أنواع خطافات Git: حراس على كل بوابة

الخطافات بتنقسم لنوعين رئيسيين، وكل نوع إله استخداماته ومكانه الصحيح.

خطافات جانب العميل (Client-Side Hooks): حارسك الشخصي

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

1. خطاف pre-commit (قبل الالتزام)

هذا هو الخطاف الأهم والأكثر استخداماً، وهو اللي كان رح ينقذني من مصيبة الصبح هديك. بيشتغل مباشرة بعد ما تكتب git commit وقبل ما تفتح محرر الرسالة. مهمته فحص التغييرات اللي أنت محددها للالتزام (staged changes).

• الاستخدام المثالي: تشغيل أدوات تنسيق الكود (Linters) مثل ESLint أو Flake8، وأدوات التنسيق التلقائي (Formatters) مثل Prettier أو Black.
• مثال: تخيل عندك مشروع Node.js، ممكن تعمل سكربت بسيط يتأكد إنه ما في أخطاء linting.

#!/bin/sh
# .git/hooks/pre-commit

echo "أبو عمر بقول: دير بالك قبل ما تعمل commit! جاري فحص الكود..."

# شغّل الـ linter على الملفات المضافة للت提交
npm run lint

# إذا فشل الأمر اللي فوق (exit code غير صفر)، الـ commit رح يفشل
if [ $? -ne 0 ]; then
 echo "يا حبيب، الكود فيه أخطاء linting! صلحها بالأول."
 exit 1
fi

echo "الكود نظيف وزي الليرة الذهب! بتقدر تكمل."
exit 0

2. خطاف prepare-commit-msg (تحضير رسالة الالتزام)

هذا الخطاف بيشتغل بعد pre-commit، ومهمته يساعدك في كتابة رسالة الالتزام. ممكن يعدّل على الرسالة الافتراضية.

• الاستخدام المثالي: إضافة رقم تذكرة (Ticket) من اسم الفرع (Branch) تلقائياً لرسالة الالتزام. مثلاً لو اسم الفرع feature/PROJ-123-user-login، الخطاف يضيف `[PROJ-123]` في بداية الرسالة.

3. خطاف commit-msg (فحص رسالة الالتزام)

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

• الاستخدام المثالي: التأكد من أن الرسالة تتبع معايير معينة مثل “Conventional Commits” (مثلاً، لازم تبدأ بـ feat:, fix:, docs:).

4. خطاف pre-push (قبل الدفع)

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

• الاستخدام المثالي: تشغيل مجموعة سريعة من الاختبارات التكاملية (Integration Tests) أو حتى بناء المشروع للتأكد من أن كل شيء يعمل مع بعضه بشكل سليم.

#!/bin/sh
# .git/hooks/pre-push

echo "آخر فحص قبل ما شغلك يشوف النور... جاري تشغيل الاختبارات النهائية..."

npm run test:integration

if [ $? -ne 0 ]; then
 echo "للأسف، الاختبارات فشلت. لا يمكنك عمل push حتى تصلحها."
 exit 1
fi

exit 0

خطافات جانب الخادم (Server-Side Hooks): حارس المشروع الجماعي

هاي الخطافات بتشتغل على السيرفر اللي مستضيف الكود (مثل GitHub, GitLab, Bitbucket). مهمتها فرض قوانين على مستوى المشروع ككل، وما حدا من المطورين بقدر يتجاوزها.

من الأمثلة عليها pre-receive و post-receive. استخداماتها تشمل:

• منع أي حدا يعمل push مباشرة على الفرع الرئيسي main.
• التأكد من أن كل الالتزامات موقعة رقمياً.
• إرسال إشعار لفريق الـ QA أو لـ Slack بعد كل عملية push ناجحة.

هذه الخطافات عادةً تدار من قبل مدير النظام أو قائد الفريق، وهي تكمل عمل الخطافات المحلية ولا تغني عنها.

كيف نبدأ؟ إعداد أول خطاف لك (خطوة بخطوة)

طيب يا أبو عمر، حمستنا! كيف أبلش أستخدم هاي الشغلات؟ فيه طريقتين، طريقة يدوية وطريقة احترافية باستخدام أدوات.

الطريقة اليدوية: للمحبين للتحكم الكامل

هاي الطريقة بتعلمك الأساسيات، وهي بسيطة جداً:

1. افتح الطرفية (Terminal) وادخل على مجلد مشروعك.
2. اذهب إلى مجلد الخطافات: cd .git/hooks
3. رح تلاقي ملفات بتنتهي بـ .sample. هاي مجرد أمثلة.
4. لإنشاء خطاف pre-commit، ببساطة أنشئ ملف جديد بهذا الاسم: touch pre-commit.
5. أهم خطوة: لازم تعطي الملف صلاحيات التنفيذ: chmod +x pre-commit. بدون هاي الخطوة، Git رح يتجاهل الملف.
6. افتح الملف بأي محرر نصوص واكتب السكربت تبعك (مثل الأمثلة اللي فوق). ممكن تكتبه بأي لغة سكربتات بتعرفها (Bash, Python, Ruby, JavaScript with Node).

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

الطريقة السهلة والاحترافية: استخدام أدوات مثل Husky

وهون بيجي دور الأبطال الحقيقيين. أدوات مثل Husky (لمشاريع JavaScript/TypeScript) أو pre-commit framework (لمشاريع Python وغيرها) بتحل مشكلة المشاركة.

فكرتها إنها بتدير الخطافات وبتخلي إعداداتها جزء من المشروع نفسه (في ملف package.json أو ملف إعدادات آخر)، وبالتالي أي حدا بيعمل clone للمشروع وبيشغل npm install، بتنزل عنده الخطافات تلقائياً. خلينا ناخذ Husky كمثال:

1. ثبّت Husky:
   npm install husky --save-dev
2. فعّل Git Hooks:
   npx husky install
   (هذا الأمر بيخلق مجلد .husky اللي رح نحط فيه سكربتات الخطافات)
3. شغّل Husky تلقائياً بعد كل npm install:
   npm set-script prepare "husky install"
4. أضف أول خطاف لك (مثلاً pre-commit):
   npx husky add .husky/pre-commit "npm run lint"

هذا الأمر الأخير رح يعمل ملف اسمه .husky/pre-commit ومحتواه كالتالي:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npm run lint

الآن، كل مرة أي مطور في الفريق بيحاول يعمل commit، رح يشتغل الأمر npm run lint تلقائياً. إذا فشل، الـ commit رح يتوقف. والجميل في الموضوع أن مجلد .husky يتم إضافته لـ Git، وبالتالي يصبح جزءاً من المشروع وموحداً للجميع.

نصائح من خبرة أبو عمر: لا تقع في هذه الأخطاء

بعد سنين من استخدام الخطافات، جمعتلكم كم نصيحة من الآخر:

نصيحة 1: ابدأ بسيطاً. لا تتحمس وتضيف كل أنواع الفحوصات في خطاف pre-commit. هذا رح يخلي عملية الـ commit بطيئة ومملة. ابدأ بشي سريع ومهم مثل الـ linter.

نصيحة 2: اجعلها سريعة. المطور بفقد صبره بسرعة. إذا الخطاف بياخذ أكثر من 5-10 ثواني، رح تلاقي الناس بلشت تستخدم الأمر git commit --no-verify لتجاوزه، وهيك بنكون ما استفدنا إشي. المهام الطويلة (مثل الاختبارات الشاملة) مكانها في pre-push أو على سيرفر الـ CI/CD.

نصيحة 3: وحّدوا الخطافات في الفريق. استخدموا أدوات مثل Husky. ما في فايدة تكون أنت الوحيد اللي عندك حارس شخصي وباقي الفريق فايت طالع على راحته. التوحيد هو أساس القوة.

نصيحة 4: وفّر مخرجًا. لازم تعرف إنه فيه مخرج طوارئ. أحياناً بتكون مضطر تعمل commit سريع لشيء بسيط جداً وما بدك تستنى الفحوصات. هنا يأتي دور git commit --no-verify أو git push --no-verify. لكن استخدمها بحكمة يا صاحبي، مش كل طبخة بتنحرق معناها بنكب الطنجرة كلها.

نصيحة 5: لا تستبدل الـ CI/CD. الخطافات هي خط الدفاع الأول، وليست الوحيد. هي شبكة أمان شخصية. لكن المصدر النهائي للحقيقة والجودة هو دائماً خط أنابيب التكامل والنشر المستمر (CI/CD Pipeline) الذي يعمل على سيرفر محايد.

الخلاصة: من قنبلة موقوتة إلى حارس أمين 🛡️

العودة لقصتي في البداية، لو كان عندي خطاف pre-commit بسيط يشغل الـ linter، كان اكتشف سطر الـ console.log في أقل من ثانية، وكان منعني من ارتكاب هذا الخطأ الكارثي، ووفر عليّ وعلى فريقي ساعات من الإحباط والوقت الضائع.

خطافات Git حولت التزاماتي البرمجية من “قنابل موقوتة” محتملة إلى مساهمات نظيفة وموثوقة. أعطتني الثقة بأن أي كود أدفعه للمستودع قد مرّ على الأقل بأبسط فحوصات الجودة.

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