किसी रिपॉज़िटरी के लिए, पुश अनुरोध ज़रूरी होते हैं. ये सभी चीज़ों को स्वस्थ और बेहतर बनाए रखते हैं. इस पेज पर, पूरी जानकारी देने वाले और आसानी से समीक्षा किए जा सकने वाले पीआर बनाने का तरीका बताया गया है. इससे आपके पीआर को मर्ज किए जाने की संभावना बढ़ जाती है.
यहां बताया गया है कि सबसे अच्छा पीआर बनाने के लिए, आपको क्या करना चाहिए.
बातचीत करें
कोड लिखने से पहले, कोर टीम से बातचीत करना मददगार होता है, ताकि उन्हें पता चल सके कि आपकी दिलचस्पी किसमें है.
अगर आपकी दिलचस्पी किसी समस्या में है, तो उस समस्या पर टिप्पणी करें और बताएं कि आप उस पर काम करने जा रहे हैं. इससे यह पक्का होता है कि एक ही काम पर कई लोग काम न कर रहे हों. हमारी टीम का कोई सदस्य, इसकी पुष्टि करने के लिए जवाब देगा कि यह आपका खाता है.
अगर आपके पास कोई ऐसा आइडिया है जो किसी समस्या से जुड़ा नहीं है, तो कृपया काम शुरू करने से पहले एक समस्या लिखें. इससे टीम को यह तय करने का मौका मिलता है कि बदलाव को लागू करने से पहले, उसे कैसे बेहतर बनाया जा सकता है. इससे आपको लंबे समय तक काम करने से बचने में मदद मिलती है.
सेट अप करना
अगर आपने पहली बार Blockly या blockly-samples में योगदान दिया है, तो डेवलपमेंट सेटअप पेज पर जाएं.
इसे छोटा रखें
हमेशा अपने बदलावों को छोटा और फ़ोकस किया हुआ रखें. हम एक बड़े पीआर के बजाय, कई छोटे पीआर की समीक्षा करना पसंद करते हैं. कुछ अच्छे नियमों के बारे में यहां बताया गया है:
- एक समस्या ठीक करें. एक साथ कई समस्याओं को हल करने की कोशिश न करें.
- दायरे को सीमित करें. आम तौर पर, किसी पीआर को पूरा करने में आठ घंटे से कम समय लगना चाहिए. हालांकि, यह कोडबेस के बारे में आपकी जानकारी पर निर्भर करता है.
- कमिट का इस्तेमाल करना. अगर आपको लगता है कि आपका पीआर थोड़ा बड़ा है, तो बदलावों को लॉजिकल ग्रुप में बांटें. इसके लिए, git कमिट का इस्तेमाल करें.
वीडियो को साफ़-सुथरा रखें
कोड स्टाइल को क्यों ध्यान में रखना चाहिए? हम लंबे समय तक इस काम में बने रहेंगे. एक जैसी स्टाइल से, रखरखाव करना आसान हो जाता है. स्टाइल से पता चलता है कि आपने अपने वैरिएबल को कैसे नाम दिया है. साथ ही, इससे यह भी पता चलता है कि आपने कोड को कैसे व्यवस्थित किया है, टिप्पणियां कैसे लिखी हैं वगैरह. जहां भी हो सके, हम स्टाइल की जांच को ऑटोमेट करने के लिए, eslint जैसे टूल का इस्तेमाल करते हैं.
eslint के अलावा, कृपया इन गाइड का पालन करें:
- Google JavaScript स्टाइल के लिए बनी गाइड.
- काम पूरा होने का मैसेज लिखने के लिए गाइड
- एपीआई की उपलब्धता
- कोडलैब की स्टाइल गाइड
बदलाव की जांच करना
पीआर सबमिट करने से पहले, आपको हमेशा यह जांच करनी चाहिए कि आपके बदलाव काम कर रहे हैं या नहीं. इससे आपको बाद में वापस जाकर, समस्याओं को ठीक करने की ज़रूरत नहीं पड़ेगी. प्रोजेक्ट की अलग-अलग कैटगरी की जांच करने के लिए, यहां कुछ आइडिया दिए गए हैं:
- प्लग इन के लिए: अपने बदलावों को कवर करने वाले ऑटोमेटेड मॉचा टेस्ट लिखें.
- उदाहरण के लिए: दिखाए गए सभी फ़ंक्शन की मैन्युअल तौर पर जांच करें.
- codelabs के लिए: पूरे ट्यूटोरियल को किसी नए खाते में चलाएं और दिए गए किसी भी कोड के उदाहरण की जांच करें.
बातचीत करें
यह पीआर बनाने का आखिरी और सबसे अहम हिस्सा है: खास जानकारी लिखना.
पीआर की अच्छी खासी खास जानकारी देने से, दूसरे डेवलपर आपके बदलावों की समीक्षा कर पाते हैं. इससे, आपके बदलावों को जल्दी स्वीकार किए जाने की संभावना बढ़ जाती है!
खास जानकारी में ये चीज़ें शामिल होनी चाहिए:
- आपका पीआर किस समस्या से जुड़ा है.
- आपके पीआर से क्या बदलाव होता है.
- आपने बदलाव की जांच कैसे की.
- ऐसी कोई भी चीज़ जिसकी समीक्षा आपको समीक्षकों से करवानी है.
- ऐसी कोई भी जानकारी जो आपके हिसाब से समीक्षकों को चाहिए.
अनुरोध करते समय पीआर टेंप्लेट का इस्तेमाल करने पर, आपको कोई समस्या नहीं आएगी. बस, याद रखें कि आपका अनुरोध जितना हो सके उतना छोटा और पूरा हो.
कोडिंग करते रहें!