Git कमिट संदेश टेम्पलेट

पुन: प्रयोज्य Conventional Commits और PR-तैयार संदेश टेम्पलेट जो आपके टर्मिनल और एडिटर में विस्तृत होते हैं।

टेम्पलेट श्रेणी अवलोकन

सुसंगत कमिट संदेश किसी रिपॉज़िटरी का इतिहास पठनीय बनाते हैं, स्वचालित changelog सक्षम करते हैं और कोड रिव्यू तेज़ करते हैं — लेकिन हर बार हाथ से एक ठीक से संरचित Conventional Commit टाइप करना इतना थकाऊ है कि अधिकांश डेवलपर एक-पंक्ति सारांश पर लौट आते हैं। एक टेक्स्ट एक्सपैंडर इसे एक छोटे ट्रिगर को टाइप, scope, सारांश, बॉडी और फ़ुटर के साथ पहले से तैयार पूर्ण कमिट ढाँचे में बदलकर हल करता है, ताकि आप प्रारूप याद रखने के बजाय विवरण भरें। चूँकि Lightning Assist सिस्टम-व्यापी काम करता है — टर्मिनल सहित, जहाँ अधिकांश कमिट वास्तव में होते हैं, और VS Code के कमिट बॉक्स में — वही टेम्पलेट काम करते हैं चाहे आप कमांड लाइन, अपने IDE या Git GUI से कमिट करें। Push-to-Talk आवाज़ डिबग के बीच जब आपके हाथ कीबोर्ड से दूर हों तब लंबा बॉडी पैराग्राफ भी बोलकर लिखवा सकती है।

इन टेम्पलेट्स का उपयोग कब करें

हर कमिट पर कमिट संदेश टेम्पलेट का उपयोग करें, लेकिन वे उन कमिट पर सबसे अधिक काम आते हैं जो बाद में मायने रखते हैं: बग फ़िक्स जिन्हें आप फिर देखेंगे, breaking changes जो अन्य टीमों को प्रभावित करते हैं, और किसी ऐसे रिपो में कोई भी कमिट जो इतिहास से रिलीज़ या changelog स्वतः उत्पन्न करता है। यदि आपका प्रोजेक्ट Conventional Commits, semantic-release या किसी changelog स्वचालन का उपयोग करता है, तो सुसंगत ढाँचा केवल स्वच्छता नहीं है — यही tooling को काम करने योग्य बनाता है। एकल प्रोजेक्ट पर भी, सुसंगत प्रारूप में लिखा पठनीय git log वास्तविक समय बचाता है जब आप किसी रिग्रेशन का bisect करते हैं या याद करने की कोशिश करते हैं कि छह महीने पहले कोई बदलाव क्यों किया गया था।

इस श्रेणी में उदाहरण टेम्पलेट

  • Conventional Commit ढाँचा: टाइप, वैकल्पिक scope, सारांश, बॉडी और ticket संदर्भ वाला फ़ुटर।
  • बग संदर्भ के साथ fix कमिट: क्या टूटा, फ़िक्स और वह issue जो यह बंद करता है।
  • Breaking-change कमिट: परिवर्तन और रिलीज़ tooling के लिए स्पष्ट रूप से चिह्नित BREAKING CHANGE फ़ुटर।

अभ्यास में उदाहरण टेम्पलेट

Conventional Commit ढाँचा

किसी भी कमिट के लिए रोज़मर्रा का टेम्पलेट, Conventional Commits विनिर्देश के अनुसार जो स्वचालित वर्ज़निंग और changelog टूल को शक्ति देता है। संरचना है एक टाइप (feat, fix, chore, docs, refactor, test आदि), कोष्ठक में एक वैकल्पिक scope, लगभग पचास अक्षरों से कम का संक्षिप्त अनिवार्य सारांश, एक खाली पंक्ति, फिर क्यों समझाने वाला बॉडी, और ticket संदर्भों के लिए एक फ़ुटर। इसे ;cc जैसे छोटे ट्रिगर पर रखें ताकि संदेश लिखने से पहले यह टर्मिनल में विस्तृत हो। हर बार एक सुसंगत ढाँचा भरना ही git log को महीनों बाद वास्तव में उपयोगी बनाता है, और यही एक रिलीज़ टूल जो changelog स्वचालित रूप से उत्पन्न कर सकता है और जो नहीं कर सकता उसके बीच अंतर है।

[#type#]([#scope#]): [#summary#]

[#why this change was made#]

Refs: [#ticket#]

बग संदर्भ के साथ fix कमिट

बग-फ़िक्स कमिट वे हैं जिन्हें भविष्य के आपको सबसे अधिक समझने की आवश्यकता होती है, इसलिए वे "fix bug" से अधिक के हकदार हैं। तीन चीज़ें कैद करें: क्या टूटा (अवलोकनीय लक्षण), फ़िक्स क्या करता है और यह कौन-सा issue बंद करता है ताकि ट्रैकर स्वतः अपडेट हो। "Closes #" फ़ुटर ही वह है जो कमिट को आपके issue ट्रैकर से जोड़ता है और अधिकांश प्लेटफ़ॉर्म पर merge पर ticket बंद करता है। इसे ;fix जैसे ट्रिगर पर रखें। जब आप किसी डिबगिंग सत्र में गहरे हों और मूल कारण को सरल भाषा में दर्ज करना चाहें, Push-to-Talk आवाज़ आपको प्रवाह तोड़े बिना बॉडी बोलकर लिखवाने देती है, और AI Enhance एक बिखरे हुए बोले गए स्पष्टीकरण को एक साफ़ पैराग्राफ़ में कस सकता है।

fix([#scope#]): [#what was broken#]

[#root cause and what the fix does#]

Closes #[#issue#]

Breaking-change कमिट

जब कोई कमिट किसी API, कॉन्फ़िगरेशन प्रारूप या किसी अन्य अनुबंध को बदलता है जिस पर अन्य कोड निर्भर करता है, तो breaking change को स्पष्ट रूप से चिह्नित किया जाना चाहिए ताकि रिलीज़ tooling एक major वर्ज़न उछाल ट्रिगर करे और changelog उपयोगकर्ताओं को चेतावनी दे। Conventional Commits मानक इसी के लिए एक BREAKING CHANGE: फ़ुटर (या टाइप के बाद एक !) का उपयोग करता है। बताएँ कि क्या टूटा और, सबसे महत्वपूर्ण, उपभोक्ताओं को माइग्रेट करने के लिए क्या करना होगा — माइग्रेशन नोट के बिना एक breaking change बस सपोर्ट प्रश्नों की बाढ़ बन जाता है। इसे ;ccbreak जैसे जानबूझकर ट्रिगर पर रखें ताकि आप इसका सहारा केवल तब लें जब आप सचमुच इसका अर्थ रखते हों, क्योंकि किसी breaking change को गलत लेबल करना उसे लेबल न करने से बुरा है।

[#type#]([#scope#])!: [#summary#]

[#what changed#]

BREAKING CHANGE: [#what consumers must change to migrate#]

Refs: [#ticket#]

शुरुआत कैसे करें

टाइप, scope, सारांश, बॉडी और ticket के प्लेसहोल्डर के साथ ;cc जैसे छोटे ट्रिगर पर सामान्य Conventional Commit ढाँचे से शुरू करें। fix टाइप और "Closes #" फ़ुटर से पहले से भरा एक ;fix वेरिएंट जोड़ें, और दुर्लभ लेकिन महत्वपूर्ण breaking कमिट के लिए BREAKING CHANGE फ़ुटर वाला ;ccbreak वेरिएंट। अपने टर्मिनल या एडिटर के कमिट बॉक्स में ट्रिगर टाइप करें और यह टाइप करते ही इनलाइन विस्तृत होता है — बिना हॉटकी के, और दोनों में समान रूप से काम करता है क्योंकि विस्तार सिस्टम-व्यापी है। जब ढाँचे स्वाभाविक लगें, तो PR-विवरण और कोड-रिव्यू-उत्तर टेम्पलेट जोड़ें ताकि पूरा परिवर्तन-सबमिशन प्रवाह सुसंगत हो।

प्रो टिप्स

  • सारांश पंक्ति को ~50 अक्षरों के नीचे और अनिवार्य रूप में रखें ("add", न कि "added") — अधिकांश git tooling और समीक्षक इस परंपरा की अपेक्षा करते हैं।
  • fix कमिट पर एक "Closes #[issue]" फ़ुटर का उपयोग करें ताकि परिवर्तन का merge आपके ट्रैकर में जुड़े ticket को स्वतः बंद कर दे।
  • breaking-change टेम्पलेट को वास्तविक अनुबंध परिवर्तनों के लिए आरक्षित रखें और हमेशा माइग्रेशन चरण शामिल करें — इसके बिना एक breaking नोट केवल सपोर्ट बोझ बनाता है।
  • डिबग के बीच जब आपके हाथ कीबोर्ड से दूर हों तब Push-to-Talk से कमिट बॉडी बोलकर लिखवाएँ, फिर AI Enhance से शब्दों को कसें।

किसी भी ऐप में इन टेम्पलेट्स का उपयोग करें

इन उदाहरणों से पुन: प्रयोज्य स्निपेट बनाएं और उन्हें त्वरित पहुंच, ट्रिगर शॉर्टकट या एआई एन्हांसमेंट के साथ चलाएं।

निःशुल्क परीक्षण प्रारंभ करें

संबंधित पृष्ठ और Snippet

अपने वर्कफ़्लो के लिए संबंधित गाइड, टेम्प्लेट और तुलनाओं का अन्वेषण करें।