पुल रिक्वेस्ट विवरण टेम्पलेट

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

एक अच्छा पुल रिक्वेस्ट विवरण तेज़, आत्मविश्वासी समीक्षा और धीमे आगे-पीछे के बीच का अंतर है — फिर भी डेवलपर हर PR पर वही ढाँचा (सारांश, प्रेरणा, टेस्ट नोट्स, चेकलिस्ट) लिखते हैं और समय-सीमा में अक्सर इसे छोड़ देते हैं। संरचना PR भर में समान है; केवल विशिष्टताएँ बदलती हैं। एक टेक्स्ट एक्सपैंडर सिद्ध विवरण फ्रेमवर्क सहेज लेता है ताकि एक छोटा ट्रिगर पूरा टेम्पलेट डाल दे, और आप शीर्षक दोबारा बनाने के बजाय वास्तविक परिवर्तन समझाने में समय लगाते हैं। Lightning Assist इन्हें GitHub, GitLab या Bitbucket में डालता है — जहाँ भी आप विवरण टाइप करें — सारांश, क्यों और टेस्ट योजना के प्लेसहोल्डर के साथ। एक रिपो-नेटिव PR टेम्पलेट के विपरीत जो केवल एक प्रोजेक्ट में लागू होता है, वही snippet हर रिपॉज़िटरी और टूल में काम करता है जिसे आप छूते हैं।

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

पुल रिक्वेस्ट विवरण टेम्पलेट हर उस PR पर उपयोग करें जहाँ स्पष्ट विवरण समीक्षा तेज़ करता है — यानी लगभग सभी: फ़ीचर कार्य, बग फ़िक्स, रीफैक्टर, और यहाँ तक कि तुच्छ परिवर्तन। संरचना (क्या, क्यों, कैसे, कैसे टेस्ट करें) स्थिर है; केवल विशिष्टताएँ बदलती हैं। इसे मानकीकृत करना समीक्षाओं को तेज़ और अधिक गहन बनाता है, "क्यों" को पकड़ता है जो अन्यथा merge होते ही खो जाता है, और टीम भर में गुणवत्ता सुसंगत रखता है चाहे PR कोई भी खोले। एक टेक्स्ट-एक्सपैंडर संस्करण को रिपो-नेटिव PR टेम्पलेट पर बढ़त है: वही लाइब्रेरी हर रिपॉज़िटरी, संगठन और Git होस्ट में काम करती है, इसलिए आपके विवरण की गुणवत्ता हर प्रोजेक्ट के कॉन्फ़िगर होने पर निर्भर नहीं करती।

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

• मानक PR विवरण: क्या बदला, क्यों, और समीक्षक इसे कैसे सत्यापित कर सकता है।
• बगफ़िक्स PR: मूल कारण, फ़िक्स, और रिग्रेशन टेस्ट जो इसे साबित करता है।
• छोटा/तुच्छ PR: एक हल्का वैरिएंट जो फिर भी इरादा और जोखिम बताता है।

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

## What
[#One-line summary of the change#]

## Why
[#Motivation / linked issue: #123#]

## How
[#Brief description of the approach#]

## How to test
- [#step 1#]
- [#step 2#]

## Checklist
- [ ] Tests added/updated
- [ ] Docs updated if needed

## Bug
[#Link to issue#] — [#what was broken#]

## Root cause
[#The underlying cause#]

## Fix
[#What this change does#]

## Regression test
[#The test that now covers this case#]

## Summary
[#One-line description of the trivial change#]

**Risk:** [#none / low — e.g. copy-only, no logic change#]
**Testing:** [#how verified, or "n/a"#]

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

अपना मानक PR विवरण एक बार लिखें और इसे ;prdesc पर एक snippet बनाएँ, सारांश, जुड़े issue और टेस्ट योजना के प्लेसहोल्डर के साथ। एक बगफ़िक्स वैरिएंट (;prbug) और एक हल्का (;prsmall) जोड़ें। ट्रिगर टाइप करें और यह टाइप करते समय इनलाइन विस्तृत होता है — किसी हॉटकी की ज़रूरत नहीं (या Hotkey Mode का उपयोग करें) — GitHub, GitLab या Bitbucket में। केवल विशिष्टताएँ भरें; संरचना हर PR पर पुन: प्रयुक्त होती है। इसे अपने commit-message snippets के साथ जोड़ें ताकि पूरा परिवर्तन सुसंगत रूप से प्रलेखित हो, और बनाएँ दबाने से पहले जल्दबाज़ी में लिखे विवरण को स्पष्ट गद्य में कसने के लिए AI Enhance का उपयोग करें।

प्रो टिप्स

• जुड़े issue के साथ हमेशा "क्यों" शामिल करें — यह वह भाग है जिसकी समीक्षकों को सबसे अधिक ज़रूरत है और जो समय-सीमा में सबसे अधिक छूट जाता है।
• एक स्पष्ट "कैसे टेस्ट करें" खंड रखें; यही धीमी समीक्षा को तेज़, आत्मविश्वासी अनुमोदन में बदलता है।
• तुच्छ PR के लिए हल्का वैरिएंट उपयोग करें ताकि छोटे परिवर्तन तेज़ रहें पर कभी खाली विवरण बॉक्स के साथ न आएँ।
• रिपो-नेटिव PR टेम्पलेट के विपरीत, टेक्स्ट-एक्सपैंडर snippets हर रिपॉज़िटरी और Git होस्ट में काम करते हैं, इसलिए गुणवत्ता प्रति-प्रोजेक्ट कॉन्फ़िग पर निर्भर नहीं करती।