Create index.hi.md

content/v1.0.0/index.hi.md

@@ -0,0 +1,85 @@
+पारंपरिक कमिट्स 1.0.0
+सारांश
+पारंपरिक कमिट्स विनिर्देश एक हल्का समझौता है जो कमिट संदेशों पर आधारित होता है। यह नियमों का एक सरल सेट प्रदान करता है जिससे एक स्पष्ट कमिट इतिहास तैयार किया जा सकता है, जिससे स्वचालित उपकरणों को आसानी से बनाया जा सके। यह विनिर्देश SemVer के साथ तालमेल बिठाता है, कमिट संदेशों में किए गए फीचर्स, फिक्सेस और ब्रेकिंग चेंजेस का वर्णन करते हुए।
+
+कमिट संदेश को इस प्रकार संरचित किया जाना चाहिए:
+
+less
+Copy code
+<प्रकार>[वैकल्पिक स्कोप]: <विवरण>
+
+[वैकल्पिक बॉडी]
+
+[वैकल्पिक फुटर(s)]
+<br /> कमिट में निम्नलिखित संरचनात्मक तत्व शामिल होते हैं, जो आपके लाइब्रेरी के उपभोक्ताओं को इरादे को संप्रेषित करते हैं:
+fix: 'fix' प्रकार का कमिट आपके कोडबेस में किसी बग को ठीक करता है (यह Semantic Versioning के 'PATCH' के साथ मेल खाता है)।
+feat: 'feat' प्रकार का कमिट आपके कोडबेस में एक नया फीचर जोड़ता है (यह Semantic Versioning के 'MINOR' के साथ मेल खाता है)।
+BREAKING CHANGE: कमिट में फुटर BREAKING CHANGE: हो, या प्रकार/स्कोप के बाद ! जोड़ा गया हो, तो यह ब्रेकिंग API चेंज को इंगित करता है (यह Semantic Versioning के 'MAJOR' के साथ मेल खाता है)। किसी भी प्रकार के कमिट में ब्रेकिंग चेंज हो सकते हैं।
+fix: और feat: के अलावा अन्य प्रकार भी अनुमति हैं, जैसे @commitlint/config-conventional (जो Angular convention पर आधारित है) build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, और अन्य सुझाव देता है।
+BREAKING CHANGE: <विवरण> के अलावा अन्य फुटर भी प्रदान किए जा सकते हैं और वे git trailer format के समान एक परंपरा का पालन करते हैं।
+अतिरिक्त प्रकार पारंपरिक कमिट्स विनिर्देश द्वारा अनिवार्य नहीं हैं, और उनके Semantic Versioning में कोई प्रभाव नहीं होता (जब तक कि उनमें BREAKING CHANGE शामिल नहीं हो)। <br /><br /> एक स्कोप कमिट के प्रकार के साथ प्रदान किया जा सकता है, जिससे अतिरिक्त संदर्भीय जानकारी मिलती है और इसे कोष्ठक में रखा जाता है, जैसे feat(parser): ऐरेस को पार्स करने की क्षमता जोड़ें।
+
+उदाहरण
+विवरण और ब्रेकिंग चेंज फुटर के साथ कमिट संदेश
+yaml
+Copy code
+feat: दी गई कॉन्फ़िगरेशन ऑब्जेक्ट को अन्य कॉन्फ़िग्स का विस्तार करने की अनुमति दें
+
+BREAKING CHANGE: अब कॉन्फ़िगरेशन फ़ाइल में `extends` कुंजी का उपयोग अन्य कॉन्फ़िग फ़ाइलों का विस्तार करने के लिए किया जाता है।
+ब्रेकिंग चेंज को आकर्षित करने के लिए ! का उपयोग करके कमिट संदेश
+makefile
+Copy code
+feat!: उत्पाद शिप होने पर ग्राहक को ईमेल भेजें।
+स्कोप और ! के साथ ब्रेकिंग चेंज को आकर्षित करने के लिए कमिट संदेश
+scss
+Copy code
+feat(api)!: उत्पाद शिप होने पर ग्राहक को ईमेल भेजें।
+! और BREAKING CHANGE फुटर दोनों के साथ कमिट संदेश
+makefile
+Copy code
+chore!: Node 6 के लिए समर्थन समाप्त करें।
+
+BREAKING CHANGE: उन जावास्क्रिप्ट फीचर्स का उपयोग करें जो Node 6 में उपलब्ध नहीं हैं।
+बिना बॉडी के कमिट संदेश
+makefile
+Copy code
+docs: CHANGELOG की वर्तनी सही करें।
+स्कोप के साथ कमिट संदेश
+scss
+Copy code
+feat(lang): पोलिश भाषा जोड़ें।
+बहु-पैरा बॉडी और कई फुटर्स के साथ कमिट संदेश
+yaml
+Copy code
+fix: अनुरोधों की रेसिंग को रोकें।
+
+एक अनुरोध आईडी और नवीनतम अनुरोध का संदर्भ पेश करें। नवीनतम अनुरोध के अलावा अन्य आने वाली प्रतिक्रियाओं को खारिज करें।
+
+टाइमआउट्स हटा दें जो रेसिंग मुद्दे को कम करने के लिए उपयोग किए गए थे लेकिन अब अप्रचलित हैं।
+
+Reviewed-by: Z
+Refs: #123
+विनिर्देश
+इस दस्तावेज़ में "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", और "OPTIONAL" शब्दों की व्याख्या RFC 2119 के अनुसार की जानी चाहिए।
+
+कमिट्स में एक प्रकार होना चाहिए, जो एक संज्ञा हो, जैसे feat, fix, इत्यादि, इसके बाद वैकल्पिक स्कोप, वैकल्पिक !, और अनिवार्य अंत दो बिंदु और स्थान होना चाहिए।
+feat प्रकार का उपयोग तब किया जाना चाहिए जब कोई कमिट आपके एप्लिकेशन या लाइब्रेरी में एक नया फीचर जोड़ता है।
+fix प्रकार का उपयोग तब किया जाना चाहिए जब कोई कमिट आपके एप्लिकेशन में बग को ठीक करता है।
+प्रकार के बाद एक स्कोप प्रदान किया जा सकता है। स्कोप में कोडबेस के एक हिस्से का वर्णन होता है जिसे कोष्ठक में लिया जाता है, उदाहरण: fix(parser):
+एक विवरण प्रकार/स्कोप उपसर्ग के बाद तुरंत आना चाहिए। विवरण कोड में किए गए परिवर्तनों का एक संक्षिप्त सारांश होना चाहिए, जैसे fix: जब स्ट्रिंग में एकाधिक स्पेस होते हैं तो ऐरे पार्सिंग समस्या को ठीक करें।
+कमिट बॉडी दी जा सकती है, और इसे छोटे विवरण के बाद एक रिक्त लाइन से शुरू करना चाहिए।
+कमिट बॉडी फ्री-फॉर्म होती है और इसमें एक या अधिक न्यूलाइन पृथक पैराग्राफ हो सकते हैं।
+एक या अधिक फुटर एक रिक्त लाइन के बाद बॉडी के बाद दिए जा सकते हैं। प्रत्येक फुटर में एक शब्द टोकन होना चाहिए, इसके बाद :<space> या <space># सेपरेटर और एक स्ट्रिंग मूल्य।
+फुटर के टोकन में व्हाइटस्पेस वर्णों के स्थान पर - का उपयोग करना चाहिए, उदाहरण: Acked-by (यह फुटर अनुभाग को बहु-पैरा बॉडी से अलग करने में मदद करता है)। BREAKING CHANGE के लिए एक अपवाद है, जिसका उपयोग टोकन के रूप में भी किया जा सकता है।
+फुटर का मान रिक्त स्थान और न्यूलाइन शामिल कर सकता है, और जब अगला मान्य फुटर टोकन/सेपरेटर जोड़ी देखी जाती है तो पार्सिंग समाप्त होनी चाहिए।
+ब्रेकिंग चेंजेस को कमिट के प्रकार/स्कोप उपसर्ग में या फुटर में इंगित किया जाना चाहिए।
+यदि फुटर में शामिल किया गया है, तो ब्रेकिंग चेंज में अपरकेस टेक्स्ट BREAKING CHANGE होना चाहिए, इसके बाद एक बिंदु, स्थान, और विवरण होना चाहिए, उदाहरण: BREAKING CHANGE: पर्यावरण वेरिएबल्स अब कॉन्फ़िगरेशन फ़ाइलों से प्राथमिकता प्राप्त करते हैं।
+यदि प्रकार/स्कोप उपसर्ग में शामिल किया गया है, तो ब्रेकिंग चेंज को ! का उपयोग करके इंगित किया जाना चाहिए। ! का उपयोग होने पर, फुटर सेक्शन में BREAKING CHANGE: छोड़ा जा सकता है, और कमिट विवरण का उपयोग ब्रेकिंग चेंज को वर्णित करने के लिए किया जाना चाहिए।
+feat और fix के अलावा अन्य प्रकार का उपयोग कमिट संदेशों में किया जा सकता है, उदाहरण: docs: रेफरेंस डॉक्यूमेंट अपडेट करें।
+पारंपरिक कमिट्स के घटकों को केस सेंसिटिव नहीं माना जाना चाहिए, सिवाय BREAKING CHANGE के, जो अपरकेस में होना चाहिए।
+BREAKING-CHANGE को BREAKING CHANGE का पर्याय माना जाना चाहिए, जब फुटर में टोकन के रूप में उपयोग किया जाए।
+पारंपरिक कमिट्स का उपयोग क्यों करें
+स्वचालित रूप से CHANGELOGs तैयार करना।
+स्वचालित रूप से सिमेंटिक वर्शन बंप निर्धारित करना (उतरे हुए कमिट्स के प्रकारों के आधार पर)।
+परिवर्तनों की प्रकृति को टीम के सदस्यों, जनता, और अन्य हितधारकों को संप्रेषित करना।
+बिल्ड और प्रकाशन प्रक्रियाओं