परिचितों के नाम पर अव्यवस्था। एक परिचित तस्वीर?

निश्चित रूप से आप git-flow को जानते हैं। यह गिट में ब्रांचिंग सम्मेलनों का एक बड़ा सेट है। यह अच्छी तरह से प्रलेखित और व्यापक रूप से वितरित है। आमतौर पर हम सही ब्रांचिंग से परिचित होते हैं और इसके बारे में बहुत सारी बातें करते हैं, लेकिन, दुर्भाग्य से, हम नामकरण के मुद्दे पर बहुत कम ध्यान देते हैं, यही वजह है कि Git में संदेशों को अक्सर अनजाने में लिखा जाता है।

मेरा नाम यर्ज़ान तश्बेनबातोव है, मैं यैंडेक्स.मार्केट टीमों में से एक में काम करता हूं। और आज मैं हैबर के पाठकों को बताऊंगा कि हम एक टीम में सार्थक कमिट बनाने के लिए किन उपकरणों का उपयोग करते हैं। मैं आपको इस विषय पर चर्चा में शामिल होने के लिए आमंत्रित करता हूं।

नामकरण पर समझौते की कमी के कारण गिट में इतिहास के साथ काम करना मुश्किल हो जाता है। यह हमारी टीम पर था। सभी के लिए सामान्य नियमों का उपयोग करने और स्वचालन को लागू करने से पहले, विशिष्ट कमिट इस प्रकार हैं:

SECRETMRKT-700:     , . SECRETMRKT-701, SECRETMRKT-702:     ...

सबसे पहले, प्रत्येक डेवलपर ने संदेश लिखा जैसे वह चाहता था: किसी ने कार्य का वर्णन किया, किसी ने किए गए परिवर्तनों को सूचीबद्ध किया, किसी ने एक यादृच्छिक वाक्यांश जनरेटर का उपयोग किया। सब कुछ बाधाओं पर था। दूसरे, कार्य संख्याएं जो कमिट में मौजूद थीं, अक्सर उपयोगी पाठ को छोटा कर देती हैं। इस सब ने गिट में इतिहास के साथ प्रभावी ढंग से काम करना मुश्किल बना दिया।

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

 refactor(tutorial):      feat(products):      fix(products):

कहानी पढ़ना और बदलाव को आसान बनाना। हमने कार्य संख्याओं को निर्दिष्ट करने से इनकार नहीं किया, परम्परागत कमिट्स कन्वेंशन के अनुसार सब कुछ बड़े करीने से कमिट में चला गया था।

इसके बाद, मैं आपको दिखाता हूं कि Git में समान आदेश कैसे प्राप्त किया जाए।

बेस्ट प्रैक्टिस, सिफारिशें, और नामकरण के लिए सामान्य समाधान

यदि आप यह समझने की कोशिश करते हैं कि उद्योग में किन प्रथाओं का उपयोग किया जाता है, तो आप निम्नलिखित विकल्प पा सकते हैं:

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

हमें कमिट में अधिक आदेश की आवश्यकता है!

परम्परागत कॉमिट पद्धति अन्य मानकों से अलग है और कई कारणों से करीबी परीक्षा की हकदार है:

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

इस मानक के लिए प्रतिबद्ध का एक उदाहरण:

 fix(products):             -     .  : SECRETMRKT-578, SECRETMRKT-602

परम्परागत कमिट के मुख्य बिंदु

डेवलपर को निम्नलिखित प्रतिबद्ध संरचना का पालन करना चाहिए:
<प्रकार> (<गुंजाइश>): <विषय>

<Body>

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

अधिवेशन में सूचीबद्ध नियमों के अलावा, हम निम्नलिखित लोकप्रिय सिफारिशों का उपयोग करते हैं:

प्रतिबद्ध के शरीर में हम लिखते हैं कि क्या बदला गया है और क्यों ।

हम निम्नलिखित प्रकारों का उपयोग करते हैं:

निर्माण	एक परियोजना बनाएं या बाहरी निर्भरता बदलें
ci	CI कॉन्फ़िगरेशन और स्क्रिप्टिंग
डॉक्स	प्रलेखन अद्यतन
करतब	नई कार्यक्षमता जोड़ना
ठीक	बग ठीक करना
पर्फ़	प्रदर्शन में सुधार
refactor	बग को ठीक किए या नई सुविधाओं को जोड़े बिना कोड का संपादन
वापस लाएं	पिछले कमिट्स में रोलबैक
शैली	कोड शैली संपादन (टैब, संकेत, अवधि, अल्पविराम, आदि)
कसौटी	टेस्ट जोड़ना

हम अनिवार्य मनोदशा में वर्णन लिखते हैं , जैसे कि खुद गिट।
मर्ज शाखा 'फिक्स / SECRETMRKT-749-fix-typos-in-title'
विराम चिह्नों के साथ प्रतिबद्ध विवरण अपलोड न करें।

पारंपरिक कमिट मानक जिसका उपयोग लार्ना योगदानकर्ताओं द्वारा किया जाता है

बस कमिट के सही नाम पर कैसे स्विच करें?

स्वचालन और सुविधा को जोड़ने की आवश्यकता है। इस समस्या को हल करने के लिए, हमें दो टूल चाहिए: रिपॉजिटरी को पुश करने से पहले जांच करने के लिए कॉन्फ़िगर किया गया कमिट जेनरेटर और कमिट।

नागरिकों की उपयोगिता निर्धारित करें

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

वैश्विक रूप से कमिटमेंट यूटिलिटी स्थापित करें (आपको व्यवस्थापक अधिकारों की आवश्यकता हो सकती है)।
```
 npm i -g commitizen 
```
अगला, cz- अनुकूलन एडेप्टर स्थापित करें। नागरिक उपयोगिता द्वारा उपयोग किए गए प्रश्नों के साथ टेम्पलेट को कॉन्फ़िगर करने की आवश्यकता है।
```
 npm i -D cz-customizable 
```

आइए हम कमिटिजन बनाते हैं। फ़ाइल को cz- कस्टमाइज़ करने के लिए आवश्यक है। बनाई गई फ़ाइल को ./config/git निर्देशिका में रखें। मैं कॉन्फ़िगरेशन फ़ाइलों के साथ प्रोजेक्ट रूट को लिट न करने और इसके लिए तैयार फ़ोल्डर में फ़ाइलों को समूहित करने का प्रयास करने की सलाह देता हूं। सामग्री:

कमिटमेंट दिखाओ। js

 "use strict"; module.exports = { //         types: [ { value: "build", name: "build:      " }, { value: "ci", name: "ci:  CI    " }, { value: "docs", name: "docs:  " }, { value: "feat", name: "feat:   " }, { value: "fix", name: "fix:  " }, { value: "perf", name: "perf:     " }, { value: "refactor", name: "refactor:         " }, { value: "revert", name: "revert:    " }, { value: "style", name: "style:    (, , ,   ..)" }, { value: "test", name: "test:  " } ], // .    ,    scopes: [ { name: "components" }, { name: "tutorial" }, { name: "catalog" }, { name: "product" } ], //         (  'fix') /* scopeOverrides: { fix: [ {name: 'style'}, {name: 'e2eTest'}, {name: 'unitTest'} ] }, */ //    messages: { type: "   ?", scope: "\n ,    ():", //   allowCustomScopes  true customScope: "  :", subject: "     :\n", body: '   ().  "|"   :\n', breaking: " BREAKING CHANGES ():\n", footer: "    (,   ). : SECRETMRKT-700, SECRETMRKT-800:\n", confirmCommit: "   ?" }, //    allowCustomScopes: true, //   Breaking Changes allowBreakingChanges: false, //     footerPrefix: " :", // limit subject length subjectLimit: 72 };

पैकेज में cz- अनुकूलन और पहले से बनाई गई कॉन्फ़िगरेशन फ़ाइल के लिए लिंक जोड़ें। संदेश:
Package.json का हिस्सा दिखाएं
```
 { "config": { "commitizen": { "path": "node_modules/cz-customizable" }, "cz-customizable": { "config": "config/git/commitizen.js" } }, } 
```
चलिए रिजल्ट चेक करते हैं। टर्मिनल में निम्न कमांड टाइप करें:
```
 git cz 
```

कमिटमेंट विज़ार्ड पहले कमिट के प्रकार, क्षेत्र के बारे में जानकारी एकत्र करेगा, फिर क्रमबद्ध रूप से उस पाठ का अनुरोध करेगा जो विवरण में, पाद लेख में और आपकी सहमति के बाद, एक कमिट बनाएगा।

कॉन्फ़िगर किए गए नागरिक उपयोगिता और उससे जुड़े cz-cusomizable एडेप्टर के उदाहरण को देखना सुनिश्चित करें

कर्कश और प्रतिबद्धताओं का उपयोग करें

परियोजना में कर्कश और कमिटमेंट स्थापित करें:
```
 npm i -D husky @commitlint/cli 
```
कर्कश के साथ, हम एक प्रतिबद्ध जांच जोड़ेंगे। ऐसा करने के लिए, package.json में, स्क्रिप्ट्स के तुरंत बाद, निम्नलिखित हुक को जोड़ दें और उसमें कमिटमेंट के लिए एक लिंक इंगित करें। js फ़ाइल:
Package.json का हिस्सा दिखाएं
```
 { "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "husky": { "hooks": { "commit-msg": "commitlint -E HUSKY_GIT_PARAMS -g './config/git/commitlint.js'" } }, "devDependencies": { "@commitlint/cli": "^7.2.1", "husky": "^1.1.3", } 
```

लिंटर को सही ढंग से काम करने के लिए आवश्यक कमेटी बनाएं। बनाई गई फ़ाइल को ./config/git निर्देशिका में रखें। फ़ाइल सामग्री:

कमिटमेंट दिखाएं। js

 //     @commitlint/config-conventional module.exports = { rules: { //        "body-leading-blank": [2, "always"], //         "footer-leading-blank": [2, "always"], //    72  "header-max-length": [2, "always", 72], //       "scope-case": [2, "always", "lower-case"], //      "subject-empty": [2, "never"], //     '.' "subject-full-stop": [2, "never", "."], //       "type-case": [2, "always", "lower-case"], //      "type-empty": [2, "never"], //      "type-enum": [ 2, "always", [ "build", "ci", "docs", "feat", "fix", "perf", "refactor", "revert", "style", "test" ] ] } };

वह सब है। अब रिपॉजिटरी में भेजने से पहले सभी कमिट की जाँच की जाएगी :)

कॉन्फ़िगर किए गए कमेंट उपयोगिता के उदाहरण को देखना सुनिश्चित करें

तो क्या नागरिक या कमिटमेंट चुनना है?

वह दोनों, और दूसरा! संयोजन के रूप में, वे उत्कृष्ट परिणाम लाते हैं: पहला उत्पन्न करता है, दूसरा उन्हें चेक करता है।

मानक अनिवार्य के उपयोग की सिफारिश क्यों करते हैं?

यह एक बेहद दिलचस्प सवाल है। एक प्रतिबद्ध एक कोड परिवर्तन है; एक प्रतिबद्ध में एक संदेश इस कोड को बदलने के लिए निर्देश के रूप में माना जा सकता है। डेवलपर के लिए ये सभी विशिष्ट निर्देश बनाएं, बदलें, जोड़ें, अपडेट करें, ठीक करें।

वैसे, Git संस्करण प्रणाली में ही आवश्यक है:

 [[imperative-mood]] Describe your changes in imperative mood, eg "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behavior.

किसी भी सम्मेलनों से क्यों चिपके रहे? क्या यह समय के लायक है? लाभ क्या है?

इसके लायक। सामान्य तौर पर, मैंने देखा कि हम कोड आधार में किए गए परिवर्तनों को विस्तार देने के लिए अधिक इच्छुक हो गए हैं। प्रतिबद्ध के शरीर में, हम विस्तार से वर्णन करते हैं कि हमें इन या उन समाधानों का उपयोग क्यों करना पड़ा। इतिहास को समझना उद्देश्यपूर्ण रूप से आसान हो गया है। इसके अलावा, हमारा उत्पाद विकसित हो रहा है, और हमें टीम में पुनःपूर्ति की उम्मीद है। मुझे यकीन है कि मानक और स्वचालन की शुरुआत के लिए धन्यवाद, शुरुआती लोगों के लिए विकास प्रक्रिया में एकीकृत करना आसान होगा।

कोशिश करें और परिणाम साझा करें।

उपयोगी लिंक:

इस लेख के सभी कोड के साथ एक भंडार ।
पारंपरिक कमिट मानक।
कमिट कमिट को मान्य करने का एक उपकरण है।
सही संचार के ऑनलाइन विन्यासकर्ता ।
नामकरण पर अच्छा सुझाव है।

सार्थक कैसे उत्पन्न करें। पारंपरिक रूप से लागू होने वाले मानक