Git Hooks संपूर्ण गाइड: इंस्टॉलेशन, उपयोग, और टिप्स

Git hooks आपके वर्कफ़्लो में कमिट या पुश जैसे Git एक्शनों से पहले या बाद में स्क्रिप्ट चलाकर कार्यों को स्वचालित करने देते हैं। वे शुरुआती चरण में समस्याएँ पकड़ते हैं, मानकों को लागू करते हैं, और यहां तक कि समस्याओं को अपने-आप ठीक भी कर सकते हैं।

मान लीजिए आपने कोड स्टाइलिंग मानकों को लागू करने के लिए एक स्क्रिप्ट लिखी है। आप उस स्क्रिप्ट को एक ऐसे hook में जोड़ सकते हैं जो कमिट से पहले चलता है। अब, जब भी कोई कमिट करने की कोशिश करेगा, hook चलेगा। यदि कोड hook में दिए गए चेक पास कर लेता है, तो कमिट हो जाएगा। नहीं तो कमिट ब्लॉक हो जाएगा।

और यह केवल समस्याएँ बताने तक सीमित नहीं है। आप स्क्रिप्ट को इस तरह कस्टमाइज़ भी कर सकते हैं कि कमिट होने से पहले वे समस्याएँ ठीक हो जाएँ। इस लेख में, मैं Git hooks के बारे में वह सब कवर करूंगा जिसकी आपको ज़रूरत है—वे क्या हैं, कौन-से महत्वपूर्ण हैं, और उन्हें प्रभावी ढंग से कैसे लागू करें।

Git Hooks क्या हैं?

Git hooks तब अपने-आप कस्टम स्क्रिप्ट चलाते हैं जब कुछ विशेष Git एक्शन होते हैं, जैसे कमिट, पुश या मर्ज से पहले या बाद में। वे Git के साथ बिल्ट-इन आते हैं, इसलिए किसी बाहरी लाइब्रेरी को इंस्टॉल करने की ज़रूरत नहीं है।

जब आप कोई Git रिपॉज़िटरी इनिशियलाइज़ करते हैं, Git डिफ़ॉल्ट रूप से hooks बना देता है। आप इन्हें .git/hooks डायरेक्टरी के अंदर पाएँगे। ये .sample एक्सटेंशन के साथ आते हैं, जो उन्हें डिफ़ॉल्ट रूप से चलने से रोकता है। यदि आप चाहते हैं कि वे डिफ़ॉल्ट रूप से चलें, तो बस .sample एक्सटेंशन हटा दें।

आप hooks किसी भी executable स्क्रिप्टिंग भाषा में लिख सकते हैं। उदाहरण के लिए, pre-commit hook फ़ाइल के अंदर आप एक स्क्रिप्ट जोड़ सकते हैं जो स्टेज्ड फ़ाइलों में "To-do" कमेंट्स की जाँच करे और अगर कोई मिले तो कमिट को ब्लॉक कर दे। यानी हर बार जब आप कमिट करने की कोशिश करेंगे, Git “To-do” से शुरू होने वाले कमेंट्स स्कैन करेगा और लंबित कार्य मिले तो असफल कर देगा। इसी तरह आप post-commit, pre-merge, pre-push और अन्य git एक्शनों के लिए कस्टम hooks बना सकते हैं।

Git Hooks के प्रकार

व्यावहारिक उदाहरणों में जाने से पहले, आइए Git hooks के दो प्रकार समझते हैं। 

क्लाइंट-साइड hooks: श्रेणियाँ और सामान्य उदाहरण

क्लाइंट-साइड hooks स्थानीय मशीनों पर Git ऑपरेशनों के दौरान चलते हैं, जैसे कमिट, रिबेसिंग, और पुश। यहाँ कुछ लोकप्रिय क्लाइंट hooks और उनके उपयोग दिए गए हैं।

• pre-commit: यह कमिट संदेश टाइप करने से पहले चलता है। इसे कमिट से पहले कोड स्टाइल लागू करने, टेस्ट चलाने, या सिंटैक्स एरर जाँचने के लिए उपयोग करें। 
• prepare-commit-msg: Git के डिफ़ॉल्ट कमिट संदेश बनाने के बाद, लेकिन एडिटर खुलने से पहले चलता है। यह hook कस्टम स्क्रिप्ट लॉजिक के आधार पर डिफ़ॉल्ट संदेश को संशोधित या बदल सकता है। 
• commit-msg: कमिट संदेश सेव होने के तुरंत बाद, लेकिन Git के कमिट पूरा करने से पहले चलता है। यह फ़ॉर्मैटिंग, संरचना, या टैगिंग जैसे कमिट संदेश नियम लागू करने का अंतिम चेकपॉइंट है।
• post-commit: कमिट बनने के बाद चलता है। इसे अक्सर नोटिफिकेशन (जैसे कमिट के बाद Slack संदेश भेजना) या लॉगिंग (कमिट मेटाडेटा सहेजना) के लिए उपयोग किया जाता है।
• post-checkout: सफल git checkout कमांड के बाद चलता है। यह तब ट्रिगर होता है जब आप ब्रांच बदलते हैं या किसी विशेष कमिट या पाथ को चेकआउट करते हैं। आप इससे प्रोजेक्ट डिपेंडेंसीज़ रीबिल्ड कर सकते हैं, टेम्प फ़ाइलें हटा सकते हैं, या नई ब्रांच के बारे में सूचित कर सकते हैं।
• post-merge: सफल मर्ज ऑपरेशन के बाद चलता है। इसे अक्सर डिपेंडेंसीज़ अपडेट करने, मर्ज संदेश प्रिंट करने, या कैश साफ़ करने के लिए उपयोग किया जाता है।
• pre-rebase: रिबेस ऑपरेशन से पहले चलता है। आप इसे प्रोटेक्टेड ब्रांचेज़ पर रिबेस रोकने, रिबेस की अनुमति देने से पहले टेस्ट चलाने, या अनकमीटेड बदलाव होने पर रिबेस रोकने के लिए इस्तेमाल कर सकते हैं।
• pre-push: पुश करने से पहले चलता है। यह प्रोटेक्टेड ब्रांचेज़ पर पुश रोकने या प्री-पुश टेस्ट चलाने में मदद करता है।
• post-rewrite: Git द्वारा कमिट्स सफलतापूर्वक री-राइट करने के बाद चलता है। यह git commit --amend (जो आख़िरी कमिट को री-राइट करता है) या git rebase (जो कमिट्स की शृंखला को री-राइट करता है) जैसे ऑपरेशनों पर ट्रिगर होता है। इसे रेफ़रेंसेज़ अपडेट करने या री-राइट के बाद टेस्ट और CI स्टेप्स ट्रिगर करने के लिए उपयोग करें।
• pre-applypatch: git am कमांड इसे तब कॉल करता है जब कोई पैच वर्किंग ट्री पर लग चुका हो लेकिन नया कमिट बनने से पहले। यदि इस hook के चेक असफल होते हैं, तो यह नॉन-ज़ीरो स्टेटस के साथ बाहर निकल सकता है और पैच को कमिट होने से रोक सकता है।
• post-applypatch: Git इसे पैच लगाने और कमिट बनाने के बाद चलाता है। यह कमिट को रद्द नहीं कर सकता, लेकिन लॉगिंग या नोटिफिकेशन भेजने के लिए उपयुक्त है।
• applypatch-msg: Git इसे git am द्वारा पैच लागू करने से पहले चलाता है। इसका उपयोग प्रस्तावित कमिट संदेश की जाँच या संपादन के लिए करें।

सर्वर-साइड hooks: श्रेणियाँ और उपयोग के मामले

सर्वर-साइड hooks रिमोट Git सर्वरों पर चलते हैं और तब ट्रिगर होते हैं जब रिमोट इवेंट होते हैं, जैसे किसी रिपॉज़िटरी पर पुश से पहले या बाद में।

• pre-receive: रिमोट सर्वर इसे पुश स्वीकार करने से पहले चलाता है। आप इसका उपयोग सभी यूज़र्स में सुसंगत कोड स्टाइल लागू करने या बदलाव स्वीकार करने से पहले सुरक्षा जाँच चलाने के लिए कर सकते हैं।
• update: जहाँ pre-receive प्रति पुश एक बार चलता है, वहीं update hook एक ही पुश में बदले जा रहे हर रेफ़रेंस (ब्रांच या टैग) के लिए चलता है।
• post-receive: git push ऑपरेशन पूरा होने के बाद चलता है। इसे अक्सर नोटिफिकेशन भेजने, विस्तृत लॉगिंग, या CI/CD पाइपलाइनों को ट्रिगर करने के लिए उपयोग किया जाता है।
• post-update: पुश में सभी रेफ़रेंसेज़ अपडेट होने के बाद चलता है। आप इसे सरल नोटिफिकेशन के लिए उपयोग कर सकते हैं क्योंकि post-receive के विपरीत यह हर रेफ़रेंस अपडेट के पुराने और नए लॉग दोनों तक पहुँच नहीं कर सकता।
• reference-transaction: यह तब फायर होता है जब कोई रेफ़रेंस ट्रांज़ैक्शन तैयार, कमिट या अबॉर्ट किया जाता है, इसलिए यह कई बार चल सकता है। एक ही ट्रांज़ैक्शन में कई रेफ़रेंसेज़ पर अपडेट्स वैलिडेट/रिजेक्ट करने या ref बदलावों को लॉग और ऑडिट करने के लिए उपयोग करें।
• push-to-checkout: तब ट्रिगर होता है जब आप ऐसे ब्रांच पर git push करते हैं जो रिमोट पर वर्तमान में चेकआउट है। इस hook से आप पुश के बाद सर्वर पर फ़ाइलें अपडेट कर सकते हैं, बदलाव लॉग कर सकते हैं, या वर्किंग डायरेक्टरी में असुरक्षित पुश को ब्लॉक कर सकते हैं।
• pre-auto-gc: Git द्वारा ऑटोमैटिक गार्बेज कलेक्शन ट्रिगर करने से ठीक पहले चलता है। आप इसका उपयोग गार्बेज कलेक्शन शुरू होने को लॉग करने, भारी संसाधन उपयोग के दौरान इसे ब्लॉक करने, या पहले से आवश्यक कार्य संभालने के लिए कर सकते हैं।
• proc-receive: जब git-receive-pack कमांड इनकमिंग पुश को प्रोसेस करता है तब चलता है। यह रिमोट रिपॉज़िटरी में रेफ़रेंसेज़ (ब्रांच और टैग) अपडेट करता है और परिणाम क्लाइंट को रिपोर्ट करता है।

Git Hooks सेट करना

इस सेक्शन में, आपको git hooks इंस्टॉल और सेट करने के चरण मिलेंगे। आप यह भी देखेंगे कि शुरुआत से कस्टम hooks कैसे बनाएँ। 

इंस्टॉलेशन और कॉन्फ़िगरेशन का तरीका

जब आप कोई Git रिपॉज़िटरी इनिशियलाइज़ करते हैं, Git अपने-आप .git/hooks फ़ोल्डर के अंदर hooks का एक सेट बना देता है। उन्हें देखने के लिए, अपना टर्मिनल खोलें और उस रिपॉज़िटरी की रूट पर जाएँ जहाँ आपने git init चलाया था। वहाँ से हिडन .git डायरेक्टरी और फिर hooks सबडायरेक्टरी खोलें। एक साधारण cd कमांड यह सब कर देता है और hooks सबडायरेक्टरी तक पहुँच देता है।

cd .git/hooksसंचालित द्वारा

अंदर जाने पर, आपको .sample एक्सटेंशन के साथ डिफ़ॉल्ट hooks दिखेंगे। किसी डिफ़ॉल्ट hook को सक्षम करने के लिए, उस hook से .sample एक्सटेंशन हटाएँ और उसे executable बनाएं।

उदाहरण के लिए, pre-commit hook से .sample एक्सटेंशन हटाने के लिए नीचे दिया कमांड उपयोग करें।

mv .git/hooks/pre-commit.sample .git/hooks/pre-commitसंचालित द्वारा

इसके बाद, नीचे दिए कमांड से इसे executable बनाएँ:

chmod +x .git/hooks/pre-commitसंचालित द्वारा

इतना करने से डिफ़ॉल्ट hooks का संपादन और सक्षम करना कवर हो जाता है। शुरुआत से कस्टम hooks बनाने के लिए, ये चरण अपनाएँ।

.git/hooks/ में नई फ़ाइल खोलने के लिए चलाएँ:

nano .git/hooks/commit-msgसंचालित द्वारा

इस फ़ाइल में स्क्रिप्ट बनाएँ। उदाहरण:

 #!/bin/sh
echo "✅ Commit message hook triggered"संचालित द्वारा

सेव करें और बाहर निकलें, फिर इसे executable बनाएँ:

chmod +x .git/hooks/commit-msg संचालित द्वारा

ऊपर के उदाहरण में, जब भी कमिट हो जाता है, hooks एक संदेश प्रिंट करते हैं " Commit message hook triggered"

कस्टम hooks सेट करने का एक और तरीका भी है। जब आप कोई रिपॉज़िटरी इनिशियलाइज़ करते हैं, Git डिफ़ॉल्ट hooks शामिल करता है। आप इन्हें टेम्पलेट डायरेक्टरी का उपयोग करके एडिट कर सकते हैं। 

यह ऐसे काम करता है: जब आप git init चलाते हैं, Git ग्लोबल टेम्पलेट डायरेक्टरी की सामग्री नई रिपॉज़िटरी की .git/ डायरेक्टरी में कॉपी करता है, जिसमें hooks भी शामिल हैं। यदि आप ग्लोबल टेम्पलेट डायरेक्टरी में कस्टम hook स्क्रिप्ट जोड़ते हैं, तो आपकी बनाई हर नई रिपॉज़िटरी वे कस्टम hooks अपने-आप इनहेरिट कर लेगी।

Hook स्क्रिप्ट बनाना और कस्टमाइज़ करना

सबसे पहले, आपको यह तय करना होगा कि आप क्या हासिल करना चाहते हैं। क्या वह अस्पष्ट कमिट संदेश पकड़ना है, गलती से पुश होने से रोकना है, या कैश साफ़ करना है? उद्देश्य पहले से तय करना ज़रूरी है, क्योंकि अलग-अलग git hooks अलग काम करते हैं, और आपको पता होना चाहिए कि किसे उपयोग करना है। 

उदाहरण के लिए, यदि आप कमिट संदेश शैली की जाँच करना चाहते हैं, तो आप commit-msg hook उपयोग करेंगे। यदि आप मुख्य ब्रांच पर कुछ खास पुश से बचना चाहते हैं, तो यह काम pre-push hook से करें। 

जब आप hook चुन लें, अगला निर्णय भाषा का है। macOS और Linux पर एक छोटी-सी Bash (या साधारण sh) स्क्रिप्ट अक्सर काफ़ी होती है। Windows पर कुछ टीमें PowerShell का सहारा लेती हैं। 

यदि आपका रेपो बहुभाषी है, तो आप Python या Node.js जैसे यूनिवर्सल इंटरप्रेटर पसंद कर सकते हैं ताकि सब एक ही लॉजिक चला सकें। इसलिए, ऊपर shebang (#!/bin/sh, #!/usr/bin/env python3, आदि) शामिल करना महत्वपूर्ण है ताकि Git को पता हो कि इसे कैसे execute करना है।

एक साधारण pre-commit hook उदाहरण जो .env फ़ाइलों को कमिट होने से रोकता है। यह संवेदनशील API keys को गलती से पुश होने से बचाता है।

#!/bin/sh

# Block committing secrets
if git diff --cached --name-only | grep -q ".env"; then
  echo "❌ .env file detected in commit! Remove it before committing."
  exit 1
fi

exit 0संचालित द्वारा

जब आप hooks को अक्षम करना चाहें, तो सबसे आसान तरीका है उन्हें अस्थायी रूप से रीनेम कर देना (pre-commit को pre-commit.off में बदलना) या उनकी execute अनुमति हटा देना। 

हालाँकि, यदि आपको इसे केवल एक बार बायपास करना हो, तो कमिट hooks को स्किप करने के लिए git commit --no-verify और पुश hooks को स्किप करने के लिए git push --no-verify का उपयोग करें। आप git config core.hooksPath /dev/null से Git को किसी खाली फ़ोल्डर की ओर इशारा करके hooks को ग्लोबली भी अक्षम कर सकते हैं।

Git Hooks के सामान्य उपयोग और उदाहरण

Git hooks आपके वर्कफ़्लो में टेस्टिंग, सुरक्षा जाँच, और गुणवत्ता मानकों को लागू करने के स्वचालन के लिए विशेष रूप से उपयोगी हैं। 

व्यावहारिक ऑटोमेशन परिदृश्य

कोड स्टाइल या लिंटिंग लागू करना: pre-commit hook का उपयोग अक्सर कोड फ़ॉर्मैटिंग ऑटोमेट करने और कमिट से पहले संभावित त्रुटियाँ पकड़ने के लिए होता है।

उदाहरण के लिए, नीचे दिए गए pre-commit hook में prettier अपने-आप फ़ॉर्मैटिंग संभालता है और कमिट से पहले बदलावों को स्टेज कर देता है। उसके तुरंत बाद लिंटर चल सकता है, और कमिट तभी सफल होगा जब लिंटिंग पास हो। यदि असफल होता है, तो कमिट रुक जाएगा।

#!/bin/sh

# Collect staged JS/TS files
FILES=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(js|ts|tsx)$')
[ -z "$FILES" ] && exit 0

echo "Formatting with Prettier..."
npx --yes prettier --write $FILES

# Re-stage files that Prettier changed
echo "$FILES" | xargs git add

echo "Linting with ESLint..."
npx --yes eslint $FILES
STATUS=$?

if [ $STATUS -ne 0 ]; then
  echo "ESLint found issues. Fix them or commit with --no-verify if needed."
  exit $STATUS
fi

echo "Pre-commit checks passed."
exit 0संचालित द्वारा

स्वचालित टेस्ट चलाएँ: आप hooks को इस तरह सेट कर सकते हैं कि वे किसी भी बदलाव को पुश करने से पहले स्वचालित टेस्ट चलाएँ। उदाहरण के लिए, नीचे दिया pre-push hook आपके रेपो में उपलब्ध pytests अपने-आप खोजकर पुश से पहले चलाता है।

#!/bin/sh
echo "Running tests before push..."
pytest -q
STATUS=$?
[ $STATUS -eq 0 ] || { echo "Tests failed. Push aborted."; exit $STATUS;संचालित द्वारा

संवेदनशील डेटा को कमिट होने से अपने-आप ब्लॉक करें: .env, .pem, या .key जैसी संवेदनशील फ़ाइलों में अक्सर सीक्रेट्स होते हैं। नीचे दिया गया pre-commit hook उदाहरण ऐसे पैटर्न की जाँच करता है और मिले तो कमिट ब्लॉक कर देता है।

#!/bin/sh
set -e

STAGED=$(git diff --cached --name-only --diff-filter=ACM)

# Block dotenv and private keys
echo "$STAGED" | grep -E '\.env(\.|$)|(^|/)\.env$|\.pem$|\.key$|id_rsa$' >/dev/null 2>&1 && {
  echo "Sensitive file detected in staged changes. Remove it from the commit."
  exit 1
}संचालित द्वारा

प्रभावी Git Hooks लिखने के टिप्स

यहाँ वे टिप्स शामिल हैं जो मुझे Git hooks लिखते समय उपयोगी लगे हैं। 

Hooks को तेज़ रखें

Hooks हर बार कुछ Git एक्शन ट्रिगर होने पर चलते हैं, इसलिए उन्हें हल्का रखें। यदि आपके पास बड़े टेस्ट सूट हैं, तो बेहतर प्रदर्शन के लिए उन्हें स्थानीय hooks के बजाय CI में चलाएँ। हर कमिट पर पूरे रेपो में लिंटर्स, फ़ॉर्मैटर्स, या चेक्स चलाना आपको धीमा कर देगा, इसलिए केवल बदली हुई फ़ाइलों तक चेक सीमित करें।

क्रॉस-प्लेटफ़ॉर्म संगतता बनाए रखें 

सुनिश्चित करें कि आपके hooks अलग-अलग ऑपरेटिंग सिस्टम पर सुचारू रूप से काम करें। पोर्टेबल shebangs उपयोग करें, लाइन एंडिंग्स सुसंगत रखें (CRLF के बजाय LF), और एब्सोल्यूट पाथ हार्डकोड न करें। 

इसके बजाय, PATH और लोकल प्रोजेक्ट स्क्रिप्ट्स जैसे npm run lint या python -m पर भरोसा करें ताकि यह कई परिवेशों में चले।

डीबगिंग रणनीतियाँ

स्क्रिप्ट कैसे चल रही है इसे ट्रेस करने के लिए विस्तृत लॉगिंग या कोई डिबग फ़्लैग (उदाहरण, HOOK_DEBUG=1) जोड़ें। वर्तमान डायरेक्टरी, ब्रांच, या स्टेज हो रही फ़ाइलों जैसे विवरण प्रिंट करें। इससे निष्पादन प्रवाह का अनुसरण करना और जहाँ समस्या आ रही है वहाँ तक पहुँचना आसान हो जाता है।

विभिन्न इनपुट्स के साथ hooks टेस्ट करें और बदलाव पुश करने से पहले स्थानीय रूप से फेल्योर सीनारियो सिमुलेट करें। यदि कोई hook अप्रत्याशित रूप से प्रगति रोक दे, तो आप Git के --no-verify फ़्लैग से उसे अस्थायी रूप से बायपास कर सकते हैं या ऐसे environment variables का उपयोग कर सकते हैं जो hooks को स्किप करने के लिए बनाए गए हों।

ऑपरेटिंग सिस्टम्स में सुसंगत व्यवहार बनाए रखने के लिए, OS-विशिष्ट कमांड से बचें, और पोर्टेबल स्क्रिप्टिंग भाषाओं को प्राथमिकता दें।

Hooks का स्पष्ट डॉक्यूमेंटेशन करें

अच्छा डॉक्यूमेंटेशन टीम की समझ बढ़ाता है और नए सदस्यों का ऑनबोर्डिंग आसान करता है। एक केंद्रीय README बनाए रखें जिसमें हर hook का उद्देश्य, व्यवहार, और उपयोग दिया हो। इसमें रन कैसे करें, प्रीरिक्विजिट्स, ट्रबलशूटिंग, और बायपासिंग टिप्स शामिल करें। साथ ही, इंस्टॉलेशन/सेटअप निर्देश भी दें। 

Git Hooks के उन्नत इम्प्लीमेंटेशन तकनीकें और सर्वोत्तम प्रथाएँ

यदि आप अधिक एडवांस्ड यूज़र हैं, तो ये टिप्स मदद कर सकते हैं:

परफ़ॉरमेंस ऑप्टिमाइज़ेशन

जटिल वर्कफ़्लो में परफ़ॉरमेंस बेहतर करने के लिए भारी लाइब्रेरी से बचकर बाहरी निर्भरताएँ घटाएँ। इससे स्टार्टअप समय कम होता है और फेल्योर पॉइंट्स भी घटते हैं। 

लिंटिंग जैसे महँगे प्रोसेस के नतीजे कैश करें ताकि फ़ाइलें न बदली हों तो उन्हें दोबारा उपयोग कर सकें। 

यदि hooks में कई चेक्स हैं, तो उन्हें पैरेलल चलाएँ ताकि वे साथ-साथ चलें। साथ ही, hook स्क्रिप्ट्स को मॉड्युलर बनाएँ। यानी hooks को छोटे, पुन: उपयोग योग्य कॉम्पोनेंट्स की तरह स्ट्रक्चर करें जो संदर्भ के आधार पर केवल प्रासंगिक हिस्से चलाएँ।

Hook चेनिंग और ऑर्केस्ट्रेशन

एक ही git इवेंट में कई hooks चलाने के लिए hook चेनिंग का उपयोग करें। उदाहरण के लिए, pre-commit hook में आप पहले लिंटिंग, फिर टेस्ट, और फिर कोड फ़ॉर्मैटिंग—सबको चेन कर सकते हैं। हर कमांड एक के बाद एक चलता है, और यदि कोई असफल होता है (नॉन-ज़ीरो स्टेटस), तो बाद के कमांड्स स्किप हो सकते हैं ताकि ख़राब कमिट रोका जा सके। 

जब hook एक्शन्स एक-दूसरे से स्वतंत्र हों, तो समय बचाने के लिए उन्हें पैरेलल भी चला सकते हैं। वहीं ऑर्केस्ट्रेशन का उपयोग करके कार्यों को सही क्रम में प्रबंधित करें।

कॉन्फ़िग प्रबंधन 

हर रेपो की अपनी .git/hooks डायरेक्टरी होती है। यानी यदि आप कई प्रोजेक्ट्स में वही चेक्स (मान लें, लिंटिंग) चाहते हैं, तो आपको उन्हें हर जगह कॉपी-पेस्ट करना पड़ेगा। बेहतर तरीक़ा है hooks को केंद्रीकृत रूप से प्रबंधित करना ताकि सभी रिपॉज़िटरीज़ उन्हें एक्सेस कर सकें और चला सकें।

आप यह एक कमांड से कर सकते हैं: git config --global core.hooksPath ~/.githooks। यह Git को ~/.githooks फ़ोल्डर में hooks ढूँढने को कहता है। वहाँ बनाए गए किसी भी hook को आपकी सभी रिपॉज़िटरीज़ अपने-आप साझा करेंगी।

आप कॉन्फ़िग फ़ाइलों (JSON या YAML) से hook लॉजिक को अधिक डायनामिक भी बना सकते हैं। हर रिपॉज़िटरी के लिए अलग लॉजिक हार्डकोड करने के बजाय, आपका hook स्क्रिप्ट उस रिपॉज़िटरी की कॉन्फ़िग फ़ाइल पढ़ सकता है और सही नियम अपने-आप लागू कर सकता है।

कंडीशनल एक्ज़ीक्यूशन

Hook स्क्रिप्ट्स के अंदर सरल शर्तें जोड़ सकते हैं ताकि वे केवल तब चलें जब प्रासंगिक हों। इसका मतलब हो सकता है वर्तमान ब्रांच नाम जाँचना, कौन-सी फ़ाइलें वास्तव में बदलीं उन्हें देखना, या ऐसा environment variable पढ़ना जो बताता हो कि उन्हें स्किप करना है।

और अधिक नियंत्रण के लिए, pre-commit जैसे फ्रेमवर्क का उपयोग करें, जहाँ आप कॉन्फ़िग फ़ाइल में घोषित करते हैं कि किस चरण में कौन-से hooks चलेंगे। आप कंडीशनल लॉजिक भी जोड़ सकते हैं, जैसे केवल कुछ ब्रांचेज़ पर hooks चलाना, variables से hooks स्किप करना, या टाइम-आधारित शर्तें जोड़ना। इससे आपके hook स्क्रिप्ट्स डायनामिक हो जाते हैं और वास्तविक वर्कफ़्लो के अनुरूप ढलते हैं।

सहयोग और साझा करने की रणनीतियाँ 

आप git hooks को केंद्रीकृत कर टीमों और रिपॉज़िटरीज़ में साझा करने के दो तरीके उपयोग कर सकते हैं:

Git टेम्पलेट्स

जब आप कोई रिपॉज़िटरी इनिशियलाइज़ करते हैं, Git git/hooks डायरेक्टरी के तहत कुछ डिफ़ॉल्ट hooks जोड़ता है। ये Git के डिफ़ॉल्ट टेम्पलेट से आते हैं।

कस्टम hooks को केंद्रीय रूप से बनाने के लिए, आप एक Git टेम्पलेट डायरेक्टरी बनाएँ, अपने hooks वहाँ लिखें, और Git को ग्लोबली इस नए डायरेक्टरी को डिफ़ॉल्ट टेम्पलेट की तरह उपयोग करने के लिए सेट कर दें। 

git config --global init.templateDir /path/to/hooks-templateसंचालित द्वारा

लेकिन इस तरीके में hooks के लिए वर्ज़न कंट्रोल की कमी है। यह तब खास उपयोगी है जब आपके hooks कम ही बदलते हों। यदि आप hooks को अक्सर अपडेट करते हैं और वर्ज़न कंट्रोल चाहिए, तो अगला तरीका अपनाएँ।

केंद्रीय git रेपो

एक समर्पित, वर्ज़न-नियंत्रित, केंद्रीय रिपॉज़िटरी बनाएँ और अपने सभी कस्टम hook स्क्रिप्ट्स उस रेपो में स्टोर करें, प्रोजेक्ट रेपो से अलग। ताकि आप hooks को प्रोजेक्ट कोडबेस से स्वतंत्र रूप से अपडेट कर सकें। 

इन hooks को मानकीकृत होना चाहिए, यानी किसी एक रिपॉज़िटरी से बँधे पाथ या वैल्यूज़ हार्डकोड करने से बचें।

यह सेटअप टीमों के लिए विशेष रूप से उपयोगी है, क्योंकि हर कोई नियमित रूप से अपडेट खींच सकता है और उन्हें अपने प्रोजेक्ट्स में सिंक कर सकता है। 

और अधिक कुशल तरीका है एक सेटअप स्क्रिप्ट का उपयोग करना जो केंद्रीय hooks रेपो को क्लोन करे और hook स्क्रिप्ट्स को प्रत्येक प्रोजेक्ट की .git/hooks डायरेक्टरी में कॉपी कर दे। उदाहरण सेटअप स्क्रिप्ट: 

#!/usr/bin/env bash
set -euo pipefail

# Location of the shared hooks template repo
HOOKS_TEMPLATE_REPO="[email protected]:your-org/git-hooks-template.git"
HOOKS_TEMPLATE_DIR="$HOME/.git-hooks-template"

# Clone or update the template repo
 echo "Cloning hooks template repo..."
 git clone "$HOOKS_TEMPLATE_REPO" "$HOOKS_TEMPLATE_DIR"

# The repo where you want hooks installed
TARGET_REPO="${1:-$(pwd)}"
TARGET_HOOKS_DIR="$TARGET_REPO/.git/hooks"

# --- Copy strategy ---
echo "Copying hooks into $TARGET_HOOKS_DIR..."
cp -r "$HOOKS_TEMPLATE_DIR/"* "$TARGET_HOOKS_DIR/"

# 4. Make sure hooks are executable
chmod +x "$TARGET_HOOKS_DIR"/* || true

echo "✅ Hooks installed successfully into $TARGET_REPO"संचालित द्वारा

एक और विकल्प symlinks का उपयोग करना है। आप प्रत्येक प्रोजेक्ट की .git/hooks डायरेक्टरी को अपने वर्ज़न-कंट्रोल्ड hooks रेपो की स्क्रिप्ट्स से लिंक कर सकते हैं। तो जैसे ही आप केंद्रीय रेपो अपडेट करेंगे, hooks अपने-आप अपडेट हो जाएँगे क्योंकि symlink उसी ओर इशारा करता है।

इस सिस्टम को भरोसेमंद बनाए रखने के लिए, hooks के रखरखाव की स्पष्ट प्रक्रिया बनाएँ। टीम के सदस्य pull requests से hooks में बदलाव प्रस्तावित करें, समीक्षा के बाद ही मर्ज करें, और जैसे-जैसे hooks विकसित हों, डॉक्यूमेंटेशन अपडेट रखें। 

डेवलपमेंट वर्कफ़्लो के साथ Git Hooks का एकीकरण

Git hooks कंटीन्यूस इंटीग्रेशन (CI) में बड़ी भूमिका निभाते हैं। संदर्भ के लिए, CI का मतलब है बार-बार बदलावों को मर्ज करना, फिर बिल्ड्स और टेस्ट चलाकर शुरुआती चरण में समस्याएँ पकड़ना। Jenkins, GitHub Actions, या GitLab CI जैसे CI/CD टूल्स के साथ hooks को जोड़कर, आप Git इवेंट्स के आधार पर बिल्ड्स ट्रिगर कर सकते हैं, टेस्ट चला सकते हैं, और यहाँ तक कि ऐप्लिकेशंस को डिप्लॉय भी कर सकते हैं।

उदाहरण के लिए, सर्वर-साइड pre-receive hook पुश स्वीकार करने से पहले Git सर्वर पर कस्टम स्क्रिप्ट चलाता है। यदि स्क्रिप्ट असफल होती है, तो सर्वर पुश अस्वीकार कर देता है। आप इसका उपयोग यह जाँचने के लिए कर सकते हैं कि उस ब्रांच पर नवीनतम CI बिल्ड पास हुई थी या नहीं, पुश की अनुमति देने से पहले। उस CI रन में कोड कवरेज चेक, यूनिट/इंटीग्रेशन टेस्ट, या सुरक्षा स्कैन शामिल हो सकते हैं।

Hooks डिप्लॉयमेंट कार्यों को भी स्वचालित कर सकते हैं। post-receive hook एक webhook ट्रिगर कर सकता है जो CI/CD पाइपलाइन शुरू करता है। जब कोड main में मर्ज होता है, तो यह अपने-आप build → deploy → release चक्र शुरू कर देता है।

सुरक्षा संबंधी विचार और सर्वोत्तम प्रथाएँ 

यदि आप आसान सहयोग और साझा सत्य के लिए केंद्रीय hooks बनाए रखते हैं, तो अनधिकृत पहुँच रोकने के लिए hooks डायरेक्टरी पर सुरक्षित फ़ाइल अनुमतियाँ सुनिश्चित करें। केवल विश्वसनीय उपयोगकर्ताओं को लिखने की अनुमति होनी चाहिए। 

आपको हमेशा hook स्क्रिप्ट्स को मिलने वाले इनपुट्स या पैरामीटर्स को वेलिडेट करना चाहिए ताकि कोड इंजेक्शन हमलों से बचा जा सके। उदाहरण के लिए, केवल अल्फ़ान्यूमेरिक और डैश वाले ब्रांच नामों की अनुमति देते हुए सख्त पैटर्न के विरुद्ध इनपुट्स वेलिडेट करें, या ऐसे टैग्स जो vMAJOR.MINOR.PATCH से मेल खाते हों। 

कभी भी hook स्क्रिप्ट्स में संवेदनशील डेटा हार्डकोड न करें। इसके बजाय, रनटाइम पर सुरक्षित रूप से क्रेडेंशियल्स देने के लिए environment variables या समर्पित सीक्रेट मैनेजमेंट टूल्स का उपयोग करें। आप Gitleaks जैसे टूल्स को pre-commit hooks के साथ एकीकृत कर सकते हैं ताकि जिन बदलावों को आप कमिट करने वाले हैं उनमें संवेदनशील जानकारी के लिए सुरक्षा स्कैन चल सकें।

कोई आपके hook को किसी दूसरे सर्वर पर कोड या जानकारी भेजने के लिए रीडायरेक्ट कर सकता है। इसलिए आपके hooks किन डोमेन्स तक पहुँच सकते हैं इसे सीमित रखें। अनजान डेस्टिनेशन सर्वर्स को ब्लॉक करने के लिए प्रॉक्सी या फ़ायरवॉल का उपयोग करें। साथ ही, सुनिश्चित करें कि आपके लॉग्स डिस्प्ले संदेशों में गोपनीय जानकारी न दिखाएँ। 

निष्कर्ष

Git hooks आपके डेवलपमेंट वर्कफ़्लो में सीधे कार्यों को स्वचालित करने और मानकों को लागू करने का सशक्त तरीका हैं। वे कोड स्टाइल और टेस्टिंग से लेकर डिप्लॉयमेंट और सुरक्षा जाँच तक हर चीज़ में मदद करते हैं।

उन्हें समझदारी से उपयोग करके, आप त्रुटियाँ घटाते हैं, समय बचाते हैं, और टीमों के बीच सहयोग को और सहज बनाते हैं।

सरल pre-commit चेक्स से शुरुआत करें, फिर ऑर्केस्ट्रेशन, केंद्रीय प्रबंधन, या CI/CD इंटीग्रेशन जैसे अधिक उन्नत सेटअप आज़माएँ। यदि आप Git यूज़र हैं और अपने कौशल बढ़ाना चाहते हैं, तो यह एडवांस्ड Git कोर्स देखें।