08 जन॰ 2026·8 मिनट
Claude Code git hooks — सुरक्षित कमिट्स और तेज़ रिव्यू के लिए
Claude Code git hooks सीक्रेट्स रोक सकते हैं, फॉर्मैटिंग लागू कर सकते हैं, सही टेस्ट चला सकते हैं, और तेज़ रिव्यू के लिए छोटे कमिट सारांश लिख सकते हैं।
Claude Code git hooks सीक्रेट्स रोक सकते हैं, फॉर्मैटिंग लागू कर सकते हैं, सही टेस्ट चला सकते हैं, और तेज़ रिव्यू के लिए छोटे कमिट सारांश लिख सकते हैं।
अधिकांश रिव्यू की तकलीफ "कठोर" कोड से नहीं आती — यह उन टालने योग्य गलतियों से आती है जो कमिट में घुस जाती हैं: एक डिबग फ्लैग रह जाना, एक अनफ़ॉर्मैटेड फ़ाइल जो शोरभरे diffs बनाती है, एक टेस्ट अपडेट मिस होना, या कॉन्फ़िग में सीक्रेट कॉपी होना। हर एक छोटी है, लेकिन साथ मिलकर वे एक साफ़ रिव्यू को धीमी बैक-एंड-फोर्थ में बदल देते हैं।
कमिट-समय स्वचालन इसे रोकने का सबसे आसान स्थान है। जब चेक्स ठीक कमिट बनने से पहले चलते हैं, तो वे समस्याओं को पकड़ लेते हैं जब बदलाव अभी भी आपके दिमाग में ताज़ा हैं। गलती सुधारना सेकंड लेता है क्योंकि आप पहले से ही उस काम के संदर्भ में हैं। तुलना कीजिए कि यह दो दिन बाद PR में मिलने से, जब और कमिट्स जुड़ गए हों और रिव्यूअर को पूछना पड़े कि क्या हुआ।
Git hooks इस काम के लिए व्यावहारिक उपकरण हैं क्योंकि वे लोकली चलते हैं, CI का इंतज़ार किए बिना। लेकिन ये जादू नहीं हैं। हुक्स छोड़े जा सकते हैं, मिसकन्फ़िगर हो सकते हैं, या मशीनों पर असंगत रह सकते हैं अगर आपकी टीम उन्हें स्टैंडर्डाइज़ नहीं करती। वे अपनी तरफ से गुणवत्ता की गारंटी भी नहीं दे सकते। इन्हें गेट नहीं, गार्डरेल समझें।
हुक्स सबसे ज़्यादा वहां मदद करते हैं जहाँ “रिव्यू टैक्स” रोकना है — वही बार-बार आने वाला, कम-मान वाली फ़ीडबैक जो बार-बार प्रकट होती रहती है। सामान्य उदाहरणों में ऐसे संवेदनशील स्ट्रिंग्स जो टोकन लगते हैं, फॉर्मैटिंग और लिंट शोर, "क्या आपने सही टेस्ट चलाए?" जैसे बेसिक चेक्स, और छोटे कॉन्टेक्स्ट सारांश शामिल हैं जो रिव्यूअर को इरादा समझने में मदद करते हैं।
यही जगह है जहाँ Claude Code git hooks बढ़िया बैठते हैं: वे उबाऊ सत्यापन का काम कर सकते हैं और उसी पल थोड़ा मनुष्यों जैसा पढ़ने योग्य संदर्भ जोड़ सकते हैं जब आप कमिट कर रहे हों।
अपेक्षाएँ सेट करना मायने रखता है। लोकल हुक्स को तेज़ और अनुमाननीय रखें ताकि लोग उनसे नफ़रत न करें। तेज़ चेक्स आपके लैपटॉप पर रहने चाहिए; धीमे चेक्स बाद में। एक अच्छा विभाजन सेकंड्स कमिट टाइम पर और मिनट्स CI में है। अगर कोई हुक नियमित रूप से इतना लम्बा लगता है कि कोई "skip" चुन लेता है, तो वह आपके रपो की रक्षा बंद कर देता है।
सरल उदाहरण: आप एक मॉड्यूल बदलते हैं और कुछ फ़ंक्शन रिफैक्टर करते हैं। बिना स्वचालन के, रिव्यूअर 400 लाइनें देखता है जो idr की तरह हिली-डुली हैं, कोई टेस्ट का ज़िक्र नहीं, और उसे बेसिक सवाल पूछने पड़ते हैं। कमिट-टाइम चेक्स के साथ, कमिट फॉर्मैटेड है, संबंधित टेस्ट सेट रन हुआ है, और कमिट मैसेज में एक छोटा सारांश है। रिव्यू वहाँ से शुरू होता है जहाँ उसे शुरू होना चाहिए: डिज़ाइन पर, न कि क्लीनअप पर।
Git hooks सरल चेक्स के लिए बढ़िया हैं, पर आमतौर पर वे हाँ/नहीं नियमों पर रुक जाते हैं: "क्या फ़ाइल फॉर्मैटेड है?" या "क्या आपने लिंटर चलाया?"। Claude Code एक हल्का निर्णय-स्तर जोड़ सकता है जो स्टेज्ड डिफ़ और कुछ संबंधित फ़ाइलों को पढ़कर उन निर्णयों को लेता है जो इंसानों के रिव्यू से बेहतर मेल खाते हैं।
Claude Code git hooks के साथ, हुक वास्तव में यह देख सकता है कि आपने क्या बदला, न कि केवल रिपो में क्या मौजूद है। इससे ऑटोमेशन ज्यादा चयनात्मक बनता है। यह छुई हुई मॉड्यूल्स, संपादित कॉन्फ़िग फ़ाइलों, और नए पर्यावरण वेरिएबल्स पर ध्यान केंद्रित कर सकता है, न कि हर कमिट को पूरे बिल्ड की तरह ट्रीट करने पर।
जहाँ "डिफ पढ़ो और सोचे" व्यावहारिक होता है:
सीमाएँ मायने रखती हैं क्योंकि एक धीमा हुक छोड़ा जाता है। लक्ष्य छोटा रखें: सामान्य गलतियों को जल्दी पकड़ने वाले गार्डरेल जोड़ें, हर कमिट पर दूसरा CI सिस्टम न चलाएँ।
एक अच्छा नियम: अगर यह कुछ सेकंड में खत्म नहीं हो सकता, तो संभवतः यह CI या pre-push में होना चाहिए। कई टीमें कमिट टाइम पर तेज़ लोकल चेक चलाती हैं और भारी टेस्ट सूट बाद में रखती हैं।
फेल्योर मोड के लिए योजना बनाएं। अगर मॉडल कॉल टाइमआउट हो जाता है, तो तय करें कि कमिट को ब्लॉक करना है या सरल चेक पर fallback करना है। एक fallback वर्कफ़्लो को अनुमाननीय रखता है और लोगों को हुक डिसेबल करने की आदत से बचाता है।
कुछ सेटअप होस्टेड मॉडल कॉल करते हैं; कुछ अधिक आइसोलेटेड वातावरण में चलते हैं। तय करें कि डेवलपर मशीन से कौन सा कोड भेजा जा सकता है (यदि कुछ भी), और क्या भेजा जा रहा है उसे सीमित रखें। स्टेज्ड डिफ़ प्लस कुछ संदर्भ फ़ाइलें अक्सर पर्याप्त होती हैं।
यदि आप संवेदनशील रिपो पर काम करते हैं, तो स्पष्ट रहें कि एनालिसिस कहाँ चलती है और क्या लॉग होता है। एक ठोस उदाहरण: अगर कमिट नया कॉन्फ़िग वैल्यू जोड़ता है जैसे STRIPE_SECRET=..., हुक कमिट रोक सकता है, बताता है क्या जोखिम लग रहा है, और सुझाव देता है कि इसे सीक्रेट मैनेजर या लोकल env फ़ाइल में रखें इससे पहले कि यह रिमोट रपो पर पहुँचे।
Git hooks तभी उपयोगी होते हैं जब लोग उन्हें चालू रखें और कमिट से डरना न सीख लें। चाल यह है कि सही हुक को सही काम के लिए चुनें और कोई भी धीमी चीज़ हॉट पाथ से बाहर रखें।
जहाँ आम तौर पर चेक्स होते हैं उसका एक सरल मानचित्र:
जब आप Claude Code git hooks जोड़ते हैं, तो उन्हें एक मददगार रिव्यूअर की तरह ट्रीट करें जो तुरंत आता है, न कि एक बोतलनैक। नेटवर्क कॉल, फुल टेस्ट सूइट, या लंबे एनालिसिस वाली चीज़ों को pre-push या CI में रखें, न कि pre-commit में।
यह तय करने का एक व्यावहारिक तरीका है कि क्या कहाँ चलेगा: चेक्स को गति और प्रभाव के हिसाब से सॉर्ट करें। यदि यह उच्च-जोखिम मुद्दों (जैसे लीकेड कीज़) को पकड़ता है और सेकंड या दो में चल सकता है, तो यह pre-commit में होना चाहिए। यदि यह 30–90 सेकंड लेता है, तो उसे pre-push में शिफ्ट करें या केवल जब कुछ फ़ाइलें बदलें तब चलाएँ।
टीमों को प्रवर्तन पर भी स्पष्ट रुख चाहिए। सिंगल-डेवलपर रिपो के लिए opt-in हुक ठीक हैं। टीम रपो के लिए, मूल बातें (सीक्रेट्स, फॉर्मैटिंग, कमिट मैसेज नियम) को लागू करना सामान्य है और भारी चेक्स लोकली सलाह दें जबकि CI अंतिम गेट बना रहे।
हुक आउटपुट लोगों की सोचे से ज़्यादा मायने रखता है। एक फेल हुक बताना चाहिए कि क्या हुआ और अगला कदम क्या है। संदेश छोटा और विशिष्ट रखें। जहाँ संभव हो सही फ़ाइल और लाइन दिखाएँ, एक स्पष्ट फिक्स कमांड दें, केवल असली आपातकाल के लिए ही bypass बताएँ (और कब नहीं), और बड़ी लॉग केवल तब दिखाएँ जब यूज़र "verbose" मांगे।
उदाहरण: अगर आप Koder.ai से कोई प्रोजेक्ट एक्सपोर्ट करते हैं और लोकली कमिट करना शुरू करते हैं, एक तेज़ pre-commit हुक तुरंत कॉपी किए गए API टोकन को पकड़ सकता है, जबकि pre-push धीमे "सिर्फ़ बदले गए मॉड्यूल के टेस्ट" नियम चलाता है इससे पहले कि कोई और ब्रांच देखे।
सीक्रेट वह कुछ भी है जो किसी को आपकी तरह एक्ट करने देता है या प्राइवेट सिस्टम्स तक एक्सेस देता है। सोचिए API टोकन, OAuth क्लाइंट सीक्रेट्स, क्लाउड कीज़, डेटाबेस पासवर्ड, प्राइवेट वेबहुक URLs, साइनिंग कीज़, और यहां तक कि "टेम्परेरी" टेस्ट क्रेडेंशियल्स। एक अनजाना कमिट किसी फ़ोर्क, CI लॉग, या पेस्ट किए गए डिफ में जा सकता है, और फिर वह अस्थायी नहीं रहता।
सबसे आसान जीत है केवल वही स्कैन करना जो आप कमिट करने वाले हैं। एक हुक को स्टेज्ड बदलावों (index) की जाँच करनी चाहिए, न कि पूरे रपो की। इससे यह तेज़ रहता है और पुराने फ़ाइलों से शोर नहीं आता जिन्हें आपने छुआ ही नहीं। यह फीडबैक भी फ़ेयर बनाता है: "इस कमिट में समस्या है" बजाय "आपके रपो में कभी समस्या थी"।
जल्दी फ्लैग करने वाली सामान्य चीज़ें: हाई-एंट्रॉपी टोकन (लंबे रैंडम दिखने वाले स्ट्रिंग्स), ज्ञात की फ़ॉर्मैट्स (AWS कीज़, GitHub टोकन, JWTs), password=... या api_key: ... जैसे पैटर्न कॉन्फ़िग में, क्रेडेंशियल्स एम्बेडेड निजी URLs, और .env फाइलें या प्रोडक्शन कॉन्फ़िग्स की नकल।
फॉल्स पॉज़िटिव्स होते हैं, खासकर टेस्ट डेटा, हैश, या example docs के साथ। एक allowlist बनाएं ताकि लोग पूरे चेक को डिसेबल किए बिना आगे बढ़ सकें। allowlist संकीर्ण रखें: फ़िक्सचर के लिए सटीक फ़ाइल पाथ्स, या स्पष्ट मार्कर जैसे “dummy” या “example” जिन्हें आपका डिटेक्टर पहचानता है।
जब सीक्रेट मिला, तो कमिट फेल कर दें और संदेश बताएं कि आगे क्या करना है। Claude Code git hooks इसे और मित्रतापूर्ण बना सकते हैं डिफ़ के आधार पर छोटा स्पष्टीकरण देकर, पर मुख्य बात साफ़, सुरक्षात्मक अगले कदम बताना है:
ERROR: Possible secret detected in staged file: config/app.yaml (line 12)
Reason: looks like an API token
Next steps:
1) Remove it from the change or move it to env vars
2) Rotate the token (assume it is compromised)
3) Re-stage and retry commit
If this is a false positive, add a narrow allowlist rule in .secrets-allowlist
ठोस उदाहरण: कोई बैकएंड कॉन्फ़िग अपडेट करता है और TEMP_API_KEY जोड़ देता है ताकि फीचर dev में चले। हुक कमिट रोक देता है, सुझाव देता है कि इसे environment variable में रखें, और याद दिलाता है कि अगर वह असली था तो टोकन रोटेट करें। यह एक छोटा रुकाव है जो बाद में बड़े साफ़-सफ़ाई को रोकता है।
फॉर्मैटिंग लड़ाइयाँ रिव्यूअर का समय बर्बाद करती हैं, पर धीमे हुक्स हुक्स को डिसेबल कराने का सबसे तेज़ तरीका हैं। स्वीट स्पॉट सरल नियम है, हर भाषा के लिए एक टूल, और केवल वही फ़ाइलें छूना जो कमिट होने वाली हैं।
प्रत्येक भाषा के लिए एक फ़ॉर्मैटर चुनें और उसे सत्य का स्रोत बनाएं। दो फ़ॉर्मैटर जो असहमत हों (या फ़ॉर्मैटर + लिंटर जो भी कोड rewrite करे) शोरभरे diffs और अनंत churn बनाएंगे। इसे निष्पादित रखें: एक JS/TS फ़ॉर्मैटर, एक Go फ़ॉर्मैटर, एक Dart फ़ॉर्मैटर। फिर सुनिश्चित करें कि हर कोई वही वर्ज़न चलाए ताकि हुक आउटपुट मशीनों पर स्थिर रहे।
सबसे बड़ा स्पीड विन केवल स्टेज्ड फ़ाइलों को फॉर्मैट करना है। हर कमिट पर पूरे रपो को फॉर्मैट करना टीमों की शिकायत का मुख्य कारण है। स्टेज्ड-ओनली तरीका भी diff को उसपर रखता है जो आपने बदला, और यही रिव्यूअर्स चाहते हैं।
तेज़ कमिट रखने के व्यावहारिक विकल्प:
Auto-fix बनाम फेल टीम की पसंद है, पर मिश्रित दृष्टिकोण अच्छा काम करता है। मशीनी संपादनों के लिए auto-fix बेहतरीन है क्योंकि यह "commit, fail, re-run, commit again" लूप को बचाता है। फेल होना बेहतर हो सकता है जब आप चाहते हैं कि लोग मुद्दा देखें और दिशा चुनें। यदि आप फेल करते हैं, तो एक सरल निर्देश प्रिंट करें जिसे कोई भी 10 सेकंड में फॉलो कर सके।
छोटी-छोटी चीजें स्टैंडर्डाइज़ करें जो क्रॉस-प्लेटफ़ॉर्म शोर पैदा करती हैं। लाइन एंडिंग्स और trailing whitespace आम अपराधी हैं, खासकर जब लोग Windows, macOS, और CI के बीच स्विच करते हैं।
एक सरल नीति जो कम तकलीफ देती है:
Claude Code git hooks यहां glue का काम कर सकते हैं: यह पता लगाना कि स्टेज्ड फाइलों में किसे किस फ़ॉर्मैटर की ज़रूरत है, सही क्रम में चलाना, और विफलताओं को सादे भाषा में समझाना। उदाहरण के लिए, अगर किसी ने एक Go फाइल और एक TS फाइल स्टेज की है, तो हुक हर एक को सही टूल से फॉर्मैट कर सकता है, परिणामों को re-stage कर सकता है, और फिर संक्षेप में नोट दे सकता है जैसे “2 files reformatted, no behavior changes”. रिव्यूअर्स साफ़ diffs देखते हैं और डेवलपर्स बार-बार कमिट करने पर दबाव महसूस नहीं करते।
एक सरल नियम commits को सुरक्षित बनाता है बिना उन्हें दर्दनाक बनाए: केवल वही टेस्ट चलाएँ जो आपने वास्तव में स्टेज किया है। जब हुक स्टेज्ड डिफ (आपके वर्किंग ट्री नहीं) देखता है, तो यह आधे-अधूरे फ़ाइलों से फ़ॉल्स अलार्म से बचता है।
शुरू करें यह पहचान कर कि किन क्षेत्रों को छुआ गया है। ज्यादातर रिपोज़ में प्राकृतिक संरचना होती है: पैकेजेस, सर्विसेस, ऐप्स, या मॉड्यूल्स। एक हुक git diff --cached --name-only पढ़ सकता है, फिर उन पाथ्स को छोटे टेस्ट कमांड्स से मैप कर सकता है।
कुछ मैपिंग नियम जो बाद में भी समझने में आसान रहते हैं:
web/ या frontend/ -> npm test (या जो सबसे छोटा लक्षित कमांड हो)api/ या server/ -> बैकएंड यूनिट टेस्ट (डिफ़ॉल्ट रूप से इंटीग्रेशन स्किप)mobile/ -> तेज़ widget/unit टेस्ट, न कि फुल डिवाइस सूइटdb/ या migrations/ -> migration linting + छोटा schema चेकshared/ -> shared पैकेज टेस्ट, साथ ही कुछ तीव्र consumersयदि आप Claude Code git hooks का उपयोग करते हैं, तो आप एक कदम आगे जा सकते हैं: Claude स्टेज्ड फ़ाइलों को देखकर एक न्यूनतम टेस्ट सेट प्रस्तावित कर सकता है, फिर हुक वे कमांड चलाता है। पर फाइनल डिसिजन नियम-आधारित रखें ताकि टीम भविष्यवाणी कर सके कि क्या होगा।
कार्यक्षभार को commit और push के बीच बाँट दें। कमिट्स तेज़ रहने चाहिए ताकि लोग हुक्स बायपास न करना शुरू करें। एक व्यावहारिक पैटर्न है:
फ्लैकी और धीमे टेस्ट्स के लिए स्पष्ट नीति चाहिए, वरना आपका हुक शोर बनेगा। टीम के रूप में तय करें क्या कमिट ब्लॉक करता है बनाम क्या केवल चेतावनी देता है। काम करने लायक दृष्टिकोण है: साफ़ फेलियर पर ब्लॉक (फॉर्मैटिंग, सामान्यत: स्थिर यूनिट टेस्ट), जाने-माने फ्लैकी टेस्ट्स पर वार्न, और धीमी सूइट्स को push/CI में रखें। अगर कोई टेस्ट फ्लैकी है, तो उसे बग मानें: ट्रैक करें, ठीक करें, और जैसे ही स्थिर हो जाएं वार्न मोड हटाएँ।
एक अच्छा डिफ हमेशा आसानी से रिव्यूबल नहीं होता। एक छोटा कमिट-टाइम सारांश 10 मिनट की पढ़ाई को 2 मिनट के चेक में बदल सकता है, खासकर जब बदलाव कई फाइलों को छूता हो या रिफैक्टर शामिल हो।
विचार सरल है: जब आप git commit चलाते हैं, आपका हुक Claude Code से स्टेज्ड डिफ पढ़ने और 3–6 लाइन का नोट बनाने को कहता है जो वे प्रश्नों का जवाब दे जो रिव्यूअर्स हमेशा पूछते हैं: क्या बदला, क्यों बदला, जोखिम कितना है, और किस तरह टेस्ट किया गया।
आउटपुट तंग और सुसंगत रखें ताकि रिव्यूअर्स भरोसा करना सीखें:
आप इसे सीधे कमिट मैसेज में डाल सकते हैं (उदा., एक छोटा फुटर के रूप में), या एक फ़ाइल में सेव कर सकते हैं जिसे टीम PR विवरण में कॉपी करे। कमिट मैसेज तब अच्छा है जब आप चाहते हैं कि संदर्भ बदलाव के साथ घूमे। अलग फ़ाइल तब बेहतर है जब टीम साफ़, कन्वेन्शनल कमिट सब्जेक्ट पसंद करे।
सारांश टूल रिव्यूअर से भी सक्त होना चाहिए। मॉडल को कोई भी डिफ़ कंटेंट भेजने से पहले, उन लाइनों को फ़िल्टर करें जो API कीज़, प्राइवेट कीज़, टोकन, .env वैल्यूज़, और क्रेडेंशियल्स जैसी पैटर्न से मेल खाती हों। यदि हुक संवेदनशील पैटर्न पाता है, तो वह लाइनों को रेडैक्ट कर सकता है या एक सामान्य सारांश पर fallback कर सकता है जैसे "credentials-related changes redacted"।
उदाहरण: आप बिलिंग एंडपॉइंट अपडेट करते हैं और तीन फ़ाइलें छूते हैं। स्टेज्ड डिफ शोरभरा है पर सारांश कहता है: “Adds idempotency key handling for charge creation to prevent double billing. Reason: retries caused duplicate charges. Risk: medium (payment path). Testing: unit tests for billing service, manual request replay.” — यही रिव्यूअर को चाहिए, बिना हर लाइन पढ़े।
आप एक छोटा बग फिक्स करते हैं और उसी कमिट में एक कॉन्फ़िग भी ट्वीक करते हैं। बग billing/tax.go में एक-लाइन का बदलाव है। कॉन्फ़िग config/staging.yaml में एक नया एंडपॉइंट दर्शाती है।
आप चलाते हैं git commit -am "Fix tax rounding". आपके Claude Code git hooks तेज़ चेक्स करते हैं, एक अनुमाननीय क्रम में।
पहले, सीक्रेट स्कैन यह देखता है कि क्या बदला — न कि पूरा रपो। यह फ्लैग करता है कि स्टेज्ड कॉन्फ़िग में ऐसा कुछ है जो रियल API की जैसा दिखता है。
ERROR: Possible secret detected in config/staging.yaml:12
Pattern: api_key=sk_live_...
Fix: remove the key and use an env var reference (e.g., API_KEY)
Override: set ALLOW_SECRETS=1 (not recommended)
आप वैल्यू को env var reference से बदलते हैं और फिर से कमिट करते हैं।
फिर, फॉर्मैटिंग केवल जहाँ ज़रूरी है वहाँ चलती है। अगर आपकी Go फाइल फॉर्मैटेड नहीं है, तो यह "run gofmt on billing/tax.go" जैसे छोटे संकेत के साथ फेल करेगा। आप फ़ॉर्मैटर चलाते हैं और हुक सेकंड्स में पास हो जाता है।
फिर टेस्ट गेट लक्षित सेट चलाता है। क्योंकि आपने billing/ छुआ है, यह केवल billing यूनिट टेस्ट चलाता है (पूरा सूइट नहीं)। अगर कोई टेस्ट फेल होता है, हुक लोकली reproduce करने का सटीक कमांड दिखाता है। आप rounding edge case ठीक करते हैं और वही टेस्ट फिर से चलाते हैं।
अंत में, हुक डिफ से रिव्यूअर सारांश जनरेट करता है। यह छोटा और विशेष होता है, जैसे:
रिव्यूअर जो देखता है वह एक साफ़ कमिट है: किसी सीक्रेट का रिसाव नहीं, सुसंगत फॉर्मैटिंग, और बदलाव से मिलते-जुलते टेस्ट। उन्हें तैयार सारांश भी मिलता है, ताकि वे लॉजिक पर फोकस कर सकें बजाय इरादे खोजने के।
हुक्स को दर्दनाक बनाने का सबसे तेज़ तरीका है उन्हें कष्टकारी बनाना। अगर कोई हुक इतना लंबे समय तक चलता है कि वह किसी का फ्लो तोड़ दे, लोग उसे --no-verify के साथ बायपास कर लेंगे या हुक हटा देंगे। किसी भी धीमी चीज़ को pre-commit से बाहर रखें और CI/डिमांड पर चलाएँ।
व्यावहारिक नियम: pre-commit को टाइपो-चेक जैसा महसूस होना चाहिए, टेस्ट सूइट जैसा नहीं। अगर आप Claude Code से स्मार्ट चेक्स चाहते हैं, तो उन्हें यह तय करने में उपयोग करें कि क्या चलाना है, न कि हर चीज़ चलाने में।
डिफ़ॉल्ट रूप से हुक्स को तेज़ रखें और ज़रूरी होने पर सख़्त बनाएं। उदाहरण: हर कमिट पर तेज़ फॉर्मैट + सीक्रेट स्कैन चलाएँ, पर टेस्ट केवल प्रभावित मॉड्यूल के लिए चलाएँ।
एक सरल स्पीड बजट जो अच्छा काम करता है:
pre-commit: कुल 1 से 5 सेकंडcommit-msg: 1 सेकंड से कमpre-push या CI में ले जाएँAI सुझाव देने में अच्छी है, नीति में नहीं। अगर आप AI को बिना नियम दिए "diff रिव्यू करो" कह देंगे, तो हर बार अलग नतीजा मिलेगा। तय करें कि हुक को क्या करना चाहिए (और क्या कभी नहीं)। उदाहरण: यह रिव्यूअर सारांश जनरेट कर सकता है, पर कोड को तब तक नहीं rewrite कर सकता जब तक कि किसी फ़ॉर्मैटर ने deterministic बदलाव न किए हों।
कई हुक्स गलती से आपकी वर्किंग ट्री स्कैन कर लेते हैं, फिर कमिट फेल कर देते हैं क्योंकि कुछ आपने स्टेज नहीं किया। यह अनुचित लगता है।
इसे टालने के लिए हमेशा स्टेज्ड कंटेंट का उपयोग करें। एक अच्छा टेस्ट है: एक फ़ाइल एडिट करें, आधी स्टेज करें, और जाँचें कि हुक केवल स्टेज्ड ही रिपोर्ट करे।
अगर हर कमिट एक वार्न ट्रिगर करे, तो वार्न शोर बन जाता है। पैटर्न्स को ट्यून करें, फ़िक्स्चर पाथ्स के लिए allowlists जोड़ें, और "शायद" मिलने वाले मामलों को वार्न में डाउनग्रेड करें साथ में स्पष्ट फिक्स बताएं।
ठोस उदाहरण: अगर आपका सीक्रेट स्कैनर fixtures/ में टेस्ट कीज़ को फ्लैग कर रहा है, तो उस फ़ोल्डर को इग्नोर करने का नियम जोड़ें, पर ऐप कॉन्फ़िग फ़ाइलों में वास्तविक कीज़ को ब्लॉक करना बनाए रखें।
अगर आप Claude Code git hooks से मदद चाहते हैं बिना अपनी टीम को परेशान किए, लक्ष्य सरल है: असली समस्याओं को जल्दी पकड़ो, सब कुछ सामान्य होने पर शांत रहो, और कमिट लूप तेज़ रखो।
अधिकांश रिपोज़ के लिए एक व्यावहारिक चेकलिस्ट:
एक छोटी डिटेल जो फायदे देती है: रिव्यूअर सारांश हर बार एक जैसा दिखाएँ। एक सरल टेम्पलेट काफी है, और इससे रिव्यूअर्स जल्दी स्कैन करना सीख जाते हैं।
Review summary:
- What changed: <1-2 bullets>
- Risky areas: <files/modules>
- Tests run: <command or “not run + why”>
अनुकूल अपनाने के अगले कदम:
यदि आप चैट-फर्स्ट तरीके से टूलिंग बनाना पसंद करते हैं, तो Koder.ai (koder.ai) छोटे हेल्पर स्क्रिप्ट्स जनरेट करने में उपयोगी हो सकता है और आप स्नैपशॉट्स व रोलबैक के साथ सुरक्षित तरीके से इटरेट कर सकते हैं इससे पहले कि आप सोर्स कोड को अपने रपो में एक्सपोर्ट करें।
शुरुआत उन बार-बार होने वाली चीज़ों से करें जो रिव्यूअर का समय बर्बाद करती हैं:
जिस भी चीज़ में समय लगता है (फुल टेस्ट सुइट, गहरी स्टेटिक एनालिसिस), उसे pre-push या CI में रखें।
एक अच्छा डिफ़ॉल्ट वर्कफ़्लो:
pre-commit: स्टेज्ड बदलावों को देखने वाले तेज़ चेक (सीक्रेट्स, फॉर्मैटिंग, तेज़ लिंट, चयनित यूनिट टेस्ट)commit-msg: कमिट मैसेज नियम (लंबाई, फॉर्मैट, टिकट ID)pre-push: धीमे पर स्थानीय चेक (बड़े टेस्ट, बिल्ड)अगर कोई चेक नियमित रूप से कुछ सेकंड से ज़्यादा लेता है, उसे बाद में शिफ्ट करें।
कमिट-टाइम हुक्स को गार्डरेल समझें, अकेला एन्फोर्समेंट न मानें.
व्यावहारिक नीति: हुक्स डेवलपर्स की मदद करते हैं; CI मुख्य ब्रांच की रक्षा करता है।
स्टेज्ड डिफ (index) स्कैन करें, पूरे रपो को नहीं.
अगर पूरा-रपो स्कैन ज़रूरी है, तो उसे शेड्यूल पर या CI में चलाएँ।
जब मैच हाई-कॉन्फिडेंस हो (असली की फ़ॉर्मैट, प्राइवेट की ब्लॉक्स, स्पष्ट password= वैल्यूज़), तो ब्लॉक करें। अस्पष्ट मामलों में चेतावनी दें।
नैरो allowlist बनाएं जैसे:
DUMMY_KEY)लगातार फॉल्स अलार्म दिखने पर लोग हुक डिसेबल कर देंगे।
केवल स्टेज्ड फाइलों को फ़ॉर्मैट करें, और हर भाषा के लिए एक ही फॉर्मैटर रखें.
व्यावहारिक डिफ़ॉल्ट्स:
इससे diffs साफ़ रहते हैं बिना हर कमिट को बड़ा रीराइट बनाए।
बदले गए पाथ्स को छोटे, तेज़ टेस्ट कमांड्स से मैप करें.
उदाहरण तरीका:
git diff --cached --name-only के ज़रिये बदले हुए क्षेत्र पहचानेंpre-push या CI के लिए रखेंइससे commits तेज़ रहते हैं और आम टूट-फूट जल्दी पकड़ी जाती है।
संक्षिप्त और सुसंगत रखें (3–6 लाइनें). एक सरल टेम्पलेट:
इसे कमिट मैसेज में जोड़ें या PR विवरण के लिए अलग टेक्स्ट आउटपुट रखें।
मॉडल को भेजने से पहले रेडैक्ट करें और सतर्क रहें.
.env वैल्यूज़, प्राइवेट कीज़, कूकीज़ या ऑथ हेडर्स जैसी पंक्तियाँ हटाएँप्राइवेट रैपो में हमेशा “कम शेयर करें” की पॉलिसी अपनाएँ।
हुक्स को अनुमाननीय और तेज़ बनाएँ:
pre-commit के लिए 1–5 सेकंड)अगर हुक फ़्लैकी या धीमा लगेगा तो डेवलपर्स --no-verify का उपयोग करेंगे।