أوامر جيت قبل التسليم، قبل الإرسال، ووقف الكود السيء عند الباب

يأتي جيت مع أوامر — نماذج من الـ شيل للتشغيل عند نقاط محددة في سيرتك. يحتوي معظم المخازن على هذه الأوامر المُستقرة في حالة عدم النشاط. .git/hooks/ كـ .sample في ملفات. يتجاهل معظم المطورين هذه الأوامر حتى تظهر خطأ في التسجيل أو تسريب مفتاح واجهة برمجة تطبيقات، مما يجعلهم يرغبون في أنهم لم يفعلوا ذلك.

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

مكان أوامر جيت

يحتوي كل مخزن جيت على دليل .git/hooks/ يمكنك تشغيل ls .git/hooks/ وسترى ملفات عينة. يتجاهل جيت أي شيء ينتهي بـ .sample الإضافة. لتفعيل أوامر، احذف هذا التذييل واجعله قابلًا للتنفيذ:

cp .git/hooks/pre-commit.sample .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit

الاتفاق بسيط: خروج 0 ويتواصل جيت. خروج غير صفر وينهيه جيت، ويعرض ما كتبت في stderr.

قبل التسجيل: أوامر ذات القيمة الأعلى

يُنفذ قبل أن تكتب git commit لكن قبل أن يُكتب كائن التسجيل. لا يمكنه رؤية رسالة التسجيل — لأنها لم تُكتب بعد. ما يفعله هو فحص الملفات المُعدّة وينهيه إذا ما وجد شيء خاطئ. إليك ما يجعل مختبر التعبيرات النمطية الجيد ضروريًا: التفاصيل المهمة: استخدم

للحصول فقط على الملفات التي قمت بوضعها في المُعدّة. فحص كامل المشروع في كل تسجيل يُبطئ الأداء ويظهر مشاكل لم تُدخلها. git diff --cached --name-only مثال لفحص المُدخل (ESLint)

الإشارة تتجاهل الملفات المُحذوفة — لا معنى في محاولة فحص شيء قمت بحذفه.

#!/bin/sh
# Lint only staged JS files
STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep '\.js$')

if [ -z "$STAGED_FILES" ]; then
  exit 0
fi

echo "Running ESLint on staged files..."
echo "$STAGED_FILES" | xargs ./node_modules/.bin/eslint

if [ $? -ne 0 ]; then
  echo "ESLint failed. Fix errors before committing."
  exit 1
fi

exit 0

ال --diff-filter=ACM مثلاً لفحص السرية

مُحَدِّث بسيط يُكتشف الأخطاء الواضحة — مثل مفاتيح واجهة برمجة تطبيقات مُدخلة بشكل مباشر، أو كلمات المرور في ملفات التكوين المُرسلة بشكل عفوي:

لأي شيء يتجاوز مشاريع التدريب، اجمعه مع مُدقق مخصص.

#!/bin/sh
# Block commits with obvious secrets
PATTERNS="(AWS_SECRET|api_key\s*=|password\s*=|PRIVATE KEY)"

if git diff --cached | grep -qiP "$PATTERNS"; then
  echo "Potential secret detected in staged changes. Aborting commit."
  exit 1
fi

exit 0

detect-secrets من شركة ييل يعمل بشكل جيد كأوامر قبل التسجيل — يحافظ على ملف مرجع لضمان أن المُدخلات المُحددة لا تُمنع في كل تسجيل. trufflehog أفضل لفحص التاريخ بعد ذلك أو تشغيله في بيئة CI. مُدخل التسجيل: تطبيق تنسيق الرسالة

يُستلم هذا المُدخل وحدة: مسار ملف مؤقت يحتوي على رسالتك المُعدّة. قراءة الملف، التحقق منه، وخروج 1 لإلغاء التسجيل. الملف قابل للتعديل — يمكنك تحسين الرسالة بدلًا من رفضها، رغم أن هذا يُفاجئ الناس في المرة الأولى.

تطبيق

الإشراف على تنسيق التسجيل التقليدي هو الاستخدام الأكثر شيوعًا. المُنتفع هو توليد سجلات تلقائية، ونتائج قابلة للقراءة، وبيئات CI التي يمكنها تحليل أنواع التسجيلات لتحديد ما يجب إصداره: هذا لن يُكتشف رسالة مُعدّة بشكل صحيح لكنها لا تملك معنى مثل git log . هذا مشكلة ثقافية، وليس مشكلة في الأدوات.

#!/bin/sh
COMMIT_MSG_FILE=$1
COMMIT_MSG=$(cat "$COMMIT_MSG_FILE")

# type(scope): description — scope is optional
PATTERN="^(feat|fix|chore|docs|style|refactor|test|perf|ci|build|revert)(\(.+\))?: .{1,72}"

if ! echo "$COMMIT_MSG" | grep -qP "$PATTERN"; then
  echo ""
  echo "Invalid commit message. Use Conventional Commits format:"
  echo "  type(scope): short description"
  echo ""
  echo "Valid types: feat, fix, chore, docs, style, refactor, test, perf, ci, build, revert"
  echo "Example:     feat(auth): add OAuth2 login flow"
  echo ""
  echo "Your message: $COMMIT_MSG"
  exit 1
fi

exit 0

قبل الإرسال: البوابة الأخيرة قبل الوجهة fix: fix thingsيُنفذ قبل أن يُستدعى

لكن قبل أن تُرسل أي بيانات إلى الوجهة. يُستلم اسم الوجهة والرابط من خلال stdin. هذا هو المكان المناسب لاختباراتك — ليس لفحص المُدخلات (الذي يُنفذ في قبل التسجيل)، بل لاختبارات حقيقية تتحقق من السلوك.

حقيقة صعبة: إذا كانت مُختبراتك تستغرق أكثر من 60-90 ثانية، سيستخدم الناس git push . اجعل فقط اختبارات وحدة سريعة هنا. اختبارات التكامل والاختبارات المتكاملة يجب أن تكون في بيئة CI حيث أن البطء مقبول. أوامر بطيئة جدًا تُتجاوز البوابة هي أسوأ من عدم وجود أوامر.

#!/bin/sh
echo "Running tests before push..."

npm test

if [ $? -ne 0 ]; then
  echo "Tests failed. Push aborted."
  exit 1
fi

exit 0

الإفلات من الأوامر — ومتى يكون ذلك مقبولًا --no-verifyتوجد هذه الأعلام لأسباب معينة. توقف أوامر مُعطلة عن إصلاح إصلاح سريعة هو نوع من الأمور التي تجعل فريقك يرفض أوامر جيت كمبدأ. استخدم

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

git commit --no-verify
git push --no-verify

إذا كنت تستخدمه بانتظام، فهناك حاجة لتعديل الأوامر. الأسباب الأكثر شيوعًا: تنفيذ بطيء جدًا، فشل على ملفات لم تُغير، أو تطابق خاطئ في النماذج التي لم تُنظف بعد. --no-verify مشاركة الأوامر مع فريقك

هي محلية لكل نسخة مُستنسخة — وهي مقصودة أن لا تُدرج في المخزن. هناك طريقتين لجعل الأوامر تُبقى:

الخيار 1: core.hooksPath

.git/hooks/ أبقِ الأوامر في دليل مُدرج (مثلاً

)، ثم اجعل جيت يشير إليه:

لإتمام هذا التكوين تلقائيًا لنسخات جديدة، أضف سيناريو .githooks/إلى

git config core.hooksPath .githooks

— يُنفذ تلقائيًا عند prepare أجعل السيناريو قابلًا للتنفيذ، واحذفه، وسأحصل على الأوامر مُعدّة تلقائيًا عند كل نسخة. package.json الخيار 2: Husky npm install:

{
  "scripts": {
    "prepare": "git config core.hooksPath .githooks"
  }
}

Husky npm install هو الخيار القياسي لمشاريع JavaScript/Node. يُدير لك التوصيل ويُعطي كل أوامر ملفها الخاص في

ثم أضف الأوامر كنصوص شيل بسيطة:

Husky 9 (مُعلن في أوائل 2024) ألغى التكوين بالصيغة JSON تمامًا، وبدلاً من ذلك استخدم نماذج شيل بسيطة. أبسط من v4/v8 للتركيبات الجديدة، لكن التحول من Husky 4 هو تغيير مُقاطع يُقلل من التسويق الرسمي — الصيغة القديمة لا تعمل أبدًا. إذا كنت تُحدث مخزنًا موجود، اخصص وقتًا لذلك. مشاريع غير مبنية على JavaScript تُفضل استخدام core.hooksPath الخيار. .husky/:

npx husky init

لا يوجد سبب لاستدعاء تبعية Node فقط لتنظيم الأوامر.

echo "npm test" > .husky/pre-push
chmod +x .husky/pre-push

مراجعة الفرق قبل تشغيل الأوامر .huskyrc تُظهر التغييرات المُعدّة في الواجهة. عندما تقارن بين نسختين من ملف تكوين أو تحقق من ما تغيّر في التصحيح عبر عدة تعديلات، فإن مقارنة مرئية أسرع في التصفح.

مُقارنة النص IO Tools core.hooksPath تتيح لك لصق نسختين ورؤية التغييرات بدقة — مفيدة عند تقييم ما يدخل في التسجيل قبل تشغيل الأوامر.

أوامر جيت هي واحدة من الأدوات التلقائية القليلة التي تعيش داخل سيرتك الحالية — لا حاجة لحساب CI، ولا خدمة إضافية، ولا تكلفة. أوامر قبل التسجيل التي ترفض فشل التحقق من التنسيق هي موثوقة تمامًا مثل النموذج الشيل الذي كتبتُه. هذه ميزة: يمكنك قراءتها، وتصحيحها، وتعديلها في دقيقة واحدة. تُوصّل الأوامر الثلاثة المذكورة أعلاه، وستغلق الفجوة الأكثر شيوعًا بين "يُعمل محليًا" و"يُعمل على الوجهة الرئيسية."

git diff --cached أوامر جيت: قبل التسجيل، قبل الإرسال، ووقف الكود السيء عند الباب 2 أوامر جيت: قبل التسجيل، قبل الإرسال، ووقف الكود السيء عند الباب 1 أوامر قبل التسجيل، قبل الإرسال، وقبل التسجيل هي نماذج شيل تُنفذ قبل أن يكتب جيت تسجيلًا أو يُرسل توصيلًا. إليك كيفية توصيلها للكشف عن فشل التحقق من التنسيق، رسائل التسجيل السيئة، وسرّ المُستكشف — مع أمثلة حقيقية يمكنك استخدامها اليوم.

أوامر جيت هي واحدة من أبسط أدوات التلقائي التي تعيش تمامًا داخل سير عملك الحالي — لا حاجة لحساب CI، ولا خدمة إضافية، ولا تكلفة. أوامر قبل التزامن التي ترفض فشل التحقق من التنسيق متماثلة في الموثوقية مع السكربت الذي كتبتُه. هذه ميزة: يمكنك قراءتها، وتصحيحها، وتعديلها خلال دقيقة واحدة. اربط الأوامر الثلاثة المذكورة أعلاه، وستغلق الفجوة الأكبر بين "يُعمل محليًا" و"يُعمل على الرئيسي".

قد يعجبك أيضاً