नामकरण शैली

कई विकास बिंदुओं के बारे में बहुत सारी जानकारी है। टिप्पणियों को कैसे लिखा जाए, कक्षाओं का नाम कैसे दिया जाए, विधियों, किस पैटर्न का उपयोग करना है, आदि। आदि लेकिन एक ऐसा क्षेत्र है जिसमें बहुत से लोग कुछ सुधारने की संभावना के बारे में भी नहीं सोचते - यह लेखन लिख रहा है।

यह क्यों आवश्यक है? समय और तंत्रिकाओं को बचाने के लिए, अधिक और कम नहीं। हम इसके बारे में थोड़ी देर बाद चर्चा करेंगे, लेकिन अब हम इस बात पर विचार करेंगे कि आम तौर पर कमिट कैसे कहते हैं।

सामान्य शैली

यदि आप GitHub के साथ समान कमिट्स से गुजरते हैं, तो आप कमिट लिखने के लिए काफी व्यापक विकल्प देख सकते हैं। लेखन के लिए मुख्य सिफारिशें निम्नानुसार प्रतिष्ठित की जा सकती हैं:

क्या करें + किस इकाई के लिए + विवरण (वैकल्पिक)

कमिट्स के लिए एक सामान्य शैली खोजने की कोशिश करें और उससे चिपके रहें। अपने लिए, मुझे यह शैली सुविधाजनक लगी जब मैंने पहली बार संकेत दिया कि मैं क्या कर रहा हूं। उदाहरण के लिए, add । उसके बाद, मैं कुछ इंगित करता हूं कि मैं कार्रवाई कर रहा हूं। उदाहरण के लिए, ui-bootstrap.js dependency । ज्यादातर मामलों में, ऐसा रिकॉर्ड पर्याप्त से अधिक है। यदि किसी प्रकार का व्याख्यात्मक शिलालेख है, तो इसे एक अलग बड़ी प्रविष्टि में डालना बेहतर है, जिसके बारे में हम बात करेंगे। यदि रिकॉर्ड छोटा है, लेकिन बहुत आवश्यक है, तो आप इसे सीधे प्रतिबद्ध में जोड़ सकते हैं। लेकिन फिर से सोचना बेहतर है कि क्या यह शिलालेख वास्तव में आवश्यक है, या क्या यह अनावश्यक ध्यान आकर्षित करेगा।

यह इस तरह होता है:

 dependency for managing ui-bootstrap.js components was added here on 18.06.2013 by olegafx 

लेकिन बेहतर:

 add ui-bootstrap.js dependency 

कमिट में बड़े पद

तो बड़े संदेशों का क्या करें? जरूर लिखें। उदाहरण के लिए, यह एक संदेश के साथ महत्वपूर्ण जानकारी हो सकती है कि आपकी प्रतिबद्धता पिछली कार्यक्षमता को तोड़ देती है, इसे बहुत ही शांत और सरल नए के साथ बदल देती है। यह सबसे बड़ी परियोजनाओं में भी होता है, इसलिए लोगों को यह बताना बहुत महत्वपूर्ण है कि इसे फिर से कैसे काम किया जाए।

सबसे आसान तरीका है कि आप कमिटमेंट के मुख्य संदेश के तहत एक खाली लाइन जोड़ें और वहां पहले से ही जानकारी दर्ज करना शुरू कर दें। वैसे, यहां आप पहले से ही भूत काल में क्रिया लिख ​​सकते हैं, यदि आप वास्तव में चाहते हैं। उदाहरण के लिए:

 replace twitter-bootstrap.css with pure.css Made UI much cleaner. BREAKING CHANGE. You need to use new class-names for grid-related elements. 

एक छोटे से पत्र के साथ एक संदेश लिखना

पहला शब्द कैपिटल लेटर के साथ लिखने का कोई विशेष कारण नहीं है। थोड़ा पढ़ने के साथ बहुत आसान है।

यह इस तरह होता है:

 Add ui-bootstrap.js dependency ADD ui-bootstrap.js dependency 

लेकिन बेहतर:

 add ui-bootstrap.js dependency 

भूत काल का उपयोग न करें

बेहतर सरल है। बीता हुआ समय बहुत जटिल संदेश पढ़ने वाला है। कल्पना कीजिए कि आप Git को एक्सेस कर रहे हैं: "Git, add," "Git, delete," आदि।

यह इस तरह होता है:

 added ui-bootstrap.js dependency 

लेकिन बेहतर:

 add ui-bootstrap.js dependency 

हम अतिरिक्त विराम चिह्न हटाते हैं

उदाहरण के लिए, आपको संदेश के अंत में एक अवधि की आवश्यकता क्यों है? तो यह स्पष्ट है कि यह समाप्त हो गया है यही बात अर्धविराम पर भी लागू होती है।

यह इस तरह होता है:

 add ui-bootstrap.js dependency; 

लेकिन बेहतर:

 add ui-bootstrap.js dependency 

रूसी भाषा

कमिट में रूसी भाषा का उपयोग करने में कुछ भी शर्मनाक नहीं है। लेकिन आपको यह करने की आवश्यकता है यदि आप 1000% सुनिश्चित हैं कि यह कोड केवल रूसी-भाषी लोगों के लिए दिलचस्प होगा। उदाहरण के लिए, आपके पास वीके के लिए एक स्क्रिप्ट है जो सभी स्टास मिखाइलोव प्रशंसकों के नक्शे की ओर इशारा करती है। जाहिर है, इससे विदेशी नागरिकों को बहुत कम रुचि होगी। और रूसियों के लिए भी, ईमानदार होना।

भेजने से पहले ब्रश करता है

स्थानीय रिपॉजिटरी में सभी कमिट्स को आपके पसंद के अनुसार नाम दिया जा सकता है। यदि आपके लिए यह याद रखना आसान है कि "अस्थायी प्रतिबद्ध 1" कुछ कार्यक्षमता का पहला कार्यशील संस्करण है, और "अस्थायी प्रतिबद्ध 2" इसका सही और परिष्कृत संस्करण है, तो कृपया, कोई भी आपको विशेष रूप से डांटेगा नहीं। लेकिन। बहुत बड़ा है। भेजने से पहले, कृपया अपने कमिट्स को सर्वोत्तम संभव तरीके से लाएं। अधिकांश मामलों के लिए, एक महान कमांड करेगा:

 git rebase -i 

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

अपनी पसंदीदा शैली का पता लगाएं।

मुझे एक AngularJS प्रोजेक्ट में मिला। यहां तक ​​कि उनके पास कमिटमेंट पर एक अलग दस्तावेज भी है। उपरोक्त सभी बिंदु जिनके बारे में मैंने बात की, वे इस दस्तावेज़ में हैं। और वह अद्भुत है। क्योंकि मुझे अलग-अलग स्रोतों से इन क्षणों की तलाश करनी थी, मेरा अपना अनुभव, लेकिन यहां सब कुछ पहले से ही एक जगह पर है और एक अच्छी सरल भाषा में लिखा गया है। मुख्य बिंदुओं पर संक्षेप में विचार करें।

कमिट के प्रकार को निर्दिष्ट करें

कई पूर्वनिर्धारित प्रकार हैं:

• सुविधा - नए एप्लिकेशन स्तर की कार्यक्षमता जोड़ते समय उपयोग की जाती है
• फिक्स - यदि आपने कुछ गंभीर बग ठीक किया है
• डॉक्स - प्रलेखन से संबंधित सब कुछ
• शैली - सही टाइपो, स्वरूपण ठीक करें
• रीफैक्टर - रीफैक्टरिंग एप्लीकेशन कोड
• परीक्षण - परीक्षण से संबंधित सब कुछ
• कोर - नियमित कोड रखरखाव

एप्लिकेशन लिखते समय हमेशा इन प्रकारों को आसानी से नहीं पहचाना जा सकता है (उदाहरण के लिए, रिफलेक्टर और कोर), इसलिए आप अपने आप ही आ सकते हैं।

एक स्कोप निर्दिष्ट करें

प्रतिबद्ध के प्रकार के तुरंत बाद, बिना किसी रिक्त स्थान के, कोष्ठक में इंगित करें कि जिस क्षेत्र में हमारी प्रतिबद्धता लागू होती है। उसके बाद, हम अपनी मानक प्रतिबद्धता लिखते हैं।

उदाहरण के लिए, एक मॉड्यूल गुंजाइश हो सकती है:

 refactor(audio-controls) use common library for all controls 

या फ़ाइल गुंजाइश:

 chore(Gruntfile.js) add watch task 

यह सब किस लिए है?

जैसा कि मैंने लेख की शुरुआत में कहा था कि समय और तंत्रिकाओं को बचाने के लिए! निम्नलिखित कार्यों को सरल बनाकर:

• परिवर्तनों की सूची की स्वचालित पीढ़ी (CHANGELOG.md और पसंद)। यहां तक ​​कि अगर यह पूरी तरह से नहीं बनता है, तो मामूली संशोधनों के लिए कम से कम कुछ शुरुआती बिंदु होंगे।
• ऐसी जगह की तलाश करते समय अनुचित कमिट्स को अनदेखा करना जहां सब कुछ टूट गया (उदाहरण के लिए, git bisect का उपयोग करके), यह मानता है कि प्रलेखन, परीक्षण, कोड शैली, आदि में सुधार करें। एकदम से छोड़ दिया जा सकता है। यदि आपका ऑडियो-नियंत्रण मॉड्यूल टूट गया है, तो आप केवल उन संदेशों को देखेंगे जहां इस मॉड्यूल को गुंजाइश में निर्दिष्ट किया गया है।
• परियोजना का सिर्फ एक अधिक समृद्ध और समझने योग्य इतिहास।

निष्कर्ष

मुझे आशा है कि आप अभी तक ऊब नहीं हैं। कृपया अपनी परियोजनाओं में एक अच्छी प्रतिबद्ध नामकरण शैली का उपयोग करने का प्रयास करें। अन्य लोग इसके लिए आपके बहुत आभारी होंगे।

वह सब है। यदि आपके पास अपनी परियोजनाओं से नामकरण के दिलचस्प उदाहरण हैं, तो मुझे टिप्पणियों में उन्हें देखकर खुशी होगी। आप पाठ में सभी त्रुटियों को निजी संदेशों में भेज सकते हैं।

एक अच्छा कोडिंग है!