काम पूरा होने के मैसेज
क्लेम्ड कमिट मैसेज वाले मैसेज की समीक्षा करना, पुल के अनुरोधों की समीक्षा करना आसान हो जाता है. साथ ही, रिलीज़ नोट जनरेट करना भी आसान हो जाता है. इस काम में मदद के लिए, Blockly प्रोजेक्ट में कन्वेंशनल कमिट का इस्तेमाल किया जाता है.
हर कमिटमेंट का फ़ॉर्मैट ऐसा होना चाहिए:
<type>: <description>
[optional body]
[optional footer(s)]
ध्यान दें कि ब्लॉकली रिपो में इसे लागू करने में मदद के लिए, तय किया गया लिंटर टूल मौजूद है. अगर आपके पुल के अनुरोध में एक से ज़्यादा प्रतिबद्धता हैं, तो लिंटर शीर्षक की जांच करेगा. अगर उसमें सिर्फ़ एक प्रतिबद्धता है, तो वह उस प्रतिबद्धता की जांच करेगा. बेहतर होगा अगर आपके किए गए काम और पुल के अनुरोध का टाइटल, दोनों इन दिशा-निर्देशों का पालन करते हों.
Type
टाइप खाली नहीं होना चाहिए और सभी छोटे अक्षरों में लिखा जाना चाहिए. नीचे उन समस्याओं की सूची दी गई है जिन्हें स्वीकार किया जाता है.
- घर का काम
- उन काम के लिए जो रूटीन/अपने-आप काम करने वाले टास्क पूरे करते हैं, जैसे कि डिपेंडेंसी अपग्रेड करना.
- बहिष्कार
- उन प्रतिबद्धता के लिए जो फ़ंक्शन को रोक देती हैं.
- feat
- ब्लॉकी में नई सुविधाएं जोड़ने वाले काम के लिए.
- fix
- Blockly में गड़बड़ियां/गड़बड़ियां ठीक करने के लिए.
- दावा वापस लें
- नए वर्शन की रिलीज़ से जुड़ी प्रतिबद्धता के लिए.
अहम बदलाव
अहम बदलाव करने से जुड़ी सुविधाओं की मदद से, काम के टाइप के बाद ! को जोड़ा जाना चाहिए. छोटे बदलाव ऐसे बदलाव होते हैं जिनकी वजह से डेवलपर को अपने ऐप्लिकेशन में Blockly का इस्तेमाल करने में परेशानी हो सकती है. इसकी वजह से, उन्हें अलग से काम करना पड़ता है.
उदाहरण के लिए:
fix!: return type of workspace.paste
ज़रूरी बदलाव, ऊपर दिए गए मान्य टाइप में से कोई भी हो सकते हैं.
ब्यौरा
विवरण खाली नहीं होना चाहिए और इसमें 256 से कम वर्ण होने चाहिए.
मुख्य हिस्सा
शरीर की जानकारी देना ज़रूरी नहीं है. अगर यह दिया गया है, तो ब्यौरे और ब्यौरे के बीच एक खाली लाइन होनी चाहिए. इसे कम से कम 256 वर्णों में बांटा जाना चाहिए.
ध्यान दें कि आम तौर पर, इस तरह की जानकारी को सीधे तौर पर अनुरोध करने के बजाय, अपने अनुरोध के ब्यौरे में शामिल करें.
फ़ुटर
फ़ुटर का इस्तेमाल करना ज़रूरी नहीं है. अगर यह जानकारी दी गई है, तो कोड और मुख्य भाग के बीच एक खाली लाइन होनी चाहिए. इसे 256 वर्णों से ज़्यादा की लाइन में नहीं होना चाहिए.
नॉन-कंवेंशनल कमिट को ठीक करना
अगर आपने बदलाव करते समय कंज़र्वेटिव कमिट का इस्तेमाल नहीं किया है, तो मैसेज को ठीक करने के दो विकल्प होते हैं. यह इस बात पर निर्भर करता है कि आपने कितने प्रतिशत बदलाव किए हैं:
अगर पुल के अनुरोध में एक से ज़्यादा बार अनुरोध किए गए हैं, तो ज़रूरी शर्तों के मुताबिक पुल अनुरोध के शीर्षक में बदलाव करें. पुल के अनुरोध को मर्ज करने पर, आपके अन्य किए गए लेन-देन बदले जाएंगे, ताकि टाइटल, तय किया गया मैसेज बन जाए.
अगर पुल के अनुरोध में एक बार में ही Google को बदलाव करने की सहमति दी गई है, तो
git commit --amendका इस्तेमाल करके अपने तय किए गए मैसेज में बदलाव करें. इसके बाद, अपने बदलावों को Blockly के अपने फ़ोर्क में ज़बरदस्ती डालें. ऐसा करने से, इस ब्रांच से जुड़े सभी ओपन पुल अनुरोधों को अपने-आप अपडेट कर दिया जाएगा.git push --force origin my-branch.