सीखने के सभी रास्ते समझें देखें करें बनाएँ किसी प्रोजेक्ट में एक योगदान दें यह पाठ किस बारे में है ऐसा issue चुनें जिसे आप अपने यहाँ दोहरा सकें, सबसे छोटा बदलाव जाँच समेत भेजें, और समीक्षा के दौर का जवाब दें।
जिस प्रोजेक्ट को आप इस्तेमाल करते हैं, उसमें एक काम खुला है: एक पन्ना भोजपुरी में उतारना। आपका रविवार खाली है। पहले क्या?
A उसका fork बनाएँ, आज रात पन्ना उतार दें, और PR खुल जाने के बाद issue पर लिख दें। B CONTRIBUTING पढ़ें, गड़बड़ी अपने यहाँ दोहराकर देखें, और फ़ाइल छूने से पहले issue पर लिख दें कि आप इसे ले रहे हैं। C CONTRIBUTING पढ़ लें, फिर सीधे पन्ने पर लग जाएँ, पन्ना कोई चलाकर देखने की चीज़ तो है नहीं।
याद जाँचें यह काम क्यों ज़रूरी है गिटहब का अपना पन्ना बताता है कि fork से बदलाव भेजने में छह कदम लगते हैं — fork यानी किसी प्रोजेक्ट की वह नकल जो आपके अपने खाते में बनती है — और उनमें से पाँच कदम कुछ लिखने से पहले ही पूरे हो जाते हैं। हर प्रोजेक्ट की अपनी CONTRIBUTING फ़ाइल बताती है कि कौन-से issue नए लोगों के लिए खुले हैं और PR में क्या-क्या होना चाहिए — issue यानी वह दर्ज की गई गड़बड़ी या माँग, और PR यानी वह पन्ना जहाँ आपका बदलाव प्रोजेक्ट में जोड़ने के लिए रखा जाता है। एक बड़े खुले प्रोजेक्ट का अपना पन्ना साफ़ लिखता है: अगर सुधार एक पंक्ति में हो सकता है, तो उसे एक ही पंक्ति रखिए।
आप एक खुले issue को CONTRIBUTING पढ़ने से लेकर प्रोजेक्ट में merge हो जाने तक ले जा सकते हैं।
गिटहब का अपना पन्ना बताता है कि fork से बदलाव भेजने में छह कदम लगते हैं — fork यानी किसी प्रोजेक्ट की वह नकल जो आपके अपने खाते में बनती है — और उनमें से पाँच कदम कुछ लिखने से पहले ही पूरे हो जाते हैं। हर प्रोजेक्ट की अपनी CONTRIBUTING फ़ाइल बताती है कि कौन-से issue नए लोगों के लिए खुले हैं और PR में क्या-क्या होना चाहिए — issue यानी वह दर्ज की गई गड़बड़ी या माँग, और PR यानी वह पन्ना जहाँ आपका बदलाव प्रोजेक्ट में जोड़ने के लिए रखा जाता है। एक बड़े खुले प्रोजेक्ट का अपना पन्ना साफ़ लिखता है: अगर सुधार एक पंक्ति में हो सकता है, तो उसे एक ही पंक्ति रखिए।
CONTRIBUTING पढ़ें, गड़बड़ी अपने यहाँ दोहराकर देखें, और फ़ाइल छूने से पहले issue पर लिख दें कि आप इसे ले रहे हैं। सबसे छोटा बदलाव भेजें जो गड़बड़ी ठीक कर दे, और साथ में एक ऐसी जाँच जो उस बदलाव के बिना फेल हो। PR में लिखें कि क्या बदला और क्यों; समीक्षा में आई टिप्पणी काम बताती है, मना नहीं करती। काम प्रोजेक्ट की issue सूची में सबके लिए खुला एक काम है: एक पन्ना अपनी भाषा में उतारना।
कमज़ोर तरीका एक ही रात में चार पन्ने उतारना और सबको एक ही PR में डाल देना। कोई issue लिया ही नहीं, प्रोजेक्ट की फ़ाइल एक PR में एक ही पन्ना माँगती है, और तीन हफ़्ते कोई उसे देखता तक नहीं।
बेहतर तरीका CONTRIBUTING पढ़ना, issue पर लिखकर एक पन्ना अपने नाम करना, और fork की एक branch में काम करना — branch यानी बदलाव रखने की अलग पटरी। commit के संदेश में, यानी बदलाव सहेजते समय लिखी पंक्ति में, पन्ने का नाम और issue का नंबर है। PR बताता है: कौन-सा पन्ना, पुराने शब्दों से पढ़ने वाला कैसे भटकता था, और पन्ना ठीक बनता है यह कैसे जाँचा। जाँचने वाला दो शब्द बदलवाता है, और अगले दिन वह merge हो जाता है।
बेहतर तरीका क्यों काम करता है लिखा दोनों ने लगभग बराबर। प्रोजेक्ट की अपनी फ़ाइल एक ने मानी, इसलिए उस रात का merge हुआ नतीजा भी एक ही के पास है।
बदली हुई स्थिति आज़माएँ चाचा कहते हैं कि दुकान की छपी हुई दाम-सूची में फ़ोन नंबर गलत है, दोबारा छपने से पहले ठीक कर दो। आप क्या बदलेंगे?
अब खुद बनाकर देखें किसी खुले प्रोजेक्ट में एक असली योगदान दें। बताएँ: कौन-सा issue, कौन-सी फ़ाइल बदली, कौन-सी जाँच चलाई, आपके PR में क्या लिखा था, और समीक्षा के दौर में क्या माँगा गया।
जाँच के काम के लिए कोडिंग: 10 में से पाठ 9 आगे ऐसी समीक्षा लिखें जिस पर काम हो सके भाग 3 के आख़िर में आपके काम का नमूना बनता है, जिसे आप भेज सकते हैं
मूल या आधिकारिक स्रोत पढ़ें: GitHub Docs · Creating a pull request from a fork