कोड में किए गए बदलाव सबमिट करना

इस पेज पर, Android Open Source Project (AOSP) में कोड में बदलाव सबमिट करने की पूरी प्रोसेस के बारे में बताया गया है. इसमें समीक्षा का अनुरोध करने और अपने बदलावों को ट्रैक करने का तरीका भी शामिल है.

AOSP, Gerrit पर काम करता है. यह Git का इस्तेमाल करने वाले प्रोजेक्ट के लिए, वेब पर काम करने वाला कोड रिव्यू सिस्टम है.

योगदानकर्ता के लाइसेंस से जुड़े समझौतों पर हस्ताक्षर करना

AOSP के लिए कोड में कोई भी बदलाव करने से पहले, आपको योगदानकर्ता के लाइसेंस से जुड़े समझौते और हेडर पढ़ने होंगे. साथ ही, इनमें से किसी एक समझौते पर हस्ताक्षर करना होगा:

• अगर आप सिर्फ़ अपने लिए योगदान कर रहे हैं, तो योगदानकर्ता के लाइसेंस से जुड़े समझौते पर हस्ताक्षर करें.
• अगर आप किसी कंपनी के लिए काम करने वाले कर्मचारी हैं, तो पक्का करें कि आपकी कंपनी ने कॉर्पोरेट योगदानकर्ता के लाइसेंस से जुड़े समझौते पर हस्ताक्षर किया हो. इससे आपको कंपनी की ओर से योगदान करने की अनुमति मिलती है.

कोई ब्रांच शुरू करना

कोड में हर बदलाव के लिए, यह तरीका अपनाएं:

1. काम के Git डेटाबेस में एक नई ब्रांच शुरू करें. कोई ब्रांच, ओरिजनल फ़ाइलों की कॉपी नहीं होती. यह किसी खास कमिट की ओर इशारा करती है. इससे लोकल ब्रांच बनाना और उनके बीच स्विच करना आसान हो जाता है. ब्रांच का इस्तेमाल करके, एक-दूसरे से अलग बदलावों की पहचान की जा सकती है. कोई ब्रांच शुरू करने के लिए, यह कमांड चलाएं:

   repo start BRANCH_NAME

   एक ही डेटाबेस में, एक ही समय पर कई अलग-अलग ब्रांच शुरू की जा सकती हैं. BRANCH_NAME ब्रांच, आपके वर्कस्पेस के लिए लोकल है. यह Gerrit या सोर्स ट्री के फ़ाइनल वर्शन में शामिल नहीं है. ब्रांच, उस प्रोजेक्ट के लिए भी खास होती हैं जिसमें आप काम कर रहे हैं. इसलिए, अगर आपको एक ही बदलाव के तहत अलग-अलग प्रोजेक्ट में मौजूद फ़ाइलों में बदलाव करना है, तो आपको हर उस प्रोजेक्ट में एक ब्रांच की ज़रूरत होगी जिसमें आपको फ़ाइलें बदलनी हैं.

2. (ज़रूरी नहीं) पुष्टि करें कि ब्रांच बन गई है या नहीं:

   repo status .

   आपको अपनी नई ब्रांच दिखेगी. उदाहरण के लिए:

   project frameworks/native/                      branch mynewbranch

बदलाव करना और उसे टेस्ट करना

बदलाव करने और उसे टेस्ट करने के लिए, यह तरीका अपनाएं:

1. पक्का करें कि आप कोडबेस के सबसे नए वर्शन पर काम कर रहे हों. इसके लिए, पूरे कोडबेस को सिंक करें:

   repo sync

   सिंक करने के दौरान, अगर आपको कोई समस्या आती है, तो सिंक करने से जुड़ी समस्याओं को हल करना लेख में दूसरा से चौथा चरण देखें.

2. बदलाव करने के लिए कोड ढूंढें. कोड ढूंढने के लिए, Android Code Search का इस्तेमाल करें. Android Code Search का इस्तेमाल करके, AOSP का सोर्स कोड देखा जा सकता है. यह कोड, AOSP का इस्तेमाल करते समय दिखने वाले कोड जैसा ही होता है. ज़्यादा जानकारी के लिए, Code Search का इस्तेमाल शुरू करना लेख पढ़ें. Android Code Search में, AOSP के रिलीज़ की सबसे नई ब्रांच में मौजूद सभी कोड देखने के लिए, https://cs.android.com/android/platform/superproject/ पर जाएं.

3. सोर्स फ़ाइलों में बदलाव करें या उन्हें जोड़ें. किए गए किसी भी बदलाव के लिए:

   • तय करें कि आपको फ़ीचर लॉन्च फ़्लैग का इस्तेमाल करना है या नहीं. अगर करना है, तो अपने नए कोड के लिए उन्हें लागू करें.

   • लाइसेंस हेडर शामिल करना लेख में बताए गए सबसे सही तरीके अपनाएं.

   • Java कोड के लिए, योगदानकर्ताओं के लिए AOSP Java कोड स्टाइल का पालन करें.

   • AOSP के कुछ हिस्से Kotlin (.kt) में लिखे गए हैं. साथ ही, प्लैटफ़ॉर्म के उन हिस्सों में Kotlin का इस्तेमाल किया जा सकता है जो पहले से Kotlin में लिखे गए हैं. Android में Kotlin के बारे में ज़्यादा जानकारी के लिए, Android डेवलपर Kotlin स्टाइल गाइड और Kotlin-Java इंटरऑप गाइड देखें. Kotlin के बारे में ज़्यादा जानकारी के लिए, Kotlin लैंग्वेज की साइट देखें.

   • एपीआई लिखते समय, Android API की गाइडलाइन का पालन करें. इन गाइडलाइन का इस्तेमाल करके, Android के एपीआई से जुड़े फ़ैसलों के पीछे की वजह जानें. प्लैटफ़ॉर्म एपीआई में किए गए बदलावों और उन्हें जोड़ने की पुष्टि, Metalava करता है.

4. Android बनाएं.

5. अपने बिल्ड को टेस्ट करें.

बदलाव को स्टेज करना और कमिट करना

कमिट, Git में बदलावों को कंट्रोल करने की बुनियादी इकाई है. इसमें पूरे प्रोजेक्ट के लिए, डायरेक्ट्री स्ट्रक्चर और फ़ाइल के कॉन्टेंट का स्नैपशॉट शामिल होता है. अपने बदलाव को कमिट करने के लिए, यह तरीका अपनाएं:

1. डिफ़ॉल्ट रूप से, Git आपके किए गए बदलावों को रजिस्टर करता है, लेकिन उन्हें ट्रैक नहीं करता. Git को अपने बदलावों को ट्रैक करने के लिए, आपको उन बदलावों को कमिट में शामिल करने के लिए मार्क या स्टेज करना होगा. बदलाव को स्टेज करने के लिए, यह कमांड चलाएं:

   git add -A

   यह कमांड, आपके किए गए किसी भी बदलाव को ट्रैक करता है.

2. स्टेजिंग एरिया में मौजूद फ़ाइलों को लें और उन्हें कमिट करें या अपने लोकल डेटाबेस में सेव करें:

   git commit -s

   डिफ़ॉल्ट रूप से, एक टेक्स्ट एडिटर खुलता है और आपसे कमिट मैसेज देने के लिए कहा जाता है.

3. इस फ़ॉर्मैट में कमिट मैसेज दें:

   • पहली लाइन: हेडलाइन. बदलाव की एक लाइन में खास जानकारी दें. इसमें ज़्यादा से ज़्यादा 50 वर्ण हो सकते हैं. बदलाव किए गए हिस्से के बारे में बताने के लिए, प्रीफ़िक्स का इस्तेमाल करें. इसके बाद, इस कमिट में किए गए बदलाव की जानकारी दें. जैसे, यहां दिए गए उदाहरण में, यूज़र इंटरफ़ेस में किए गए बदलाव के बारे में बताया गया है:

     ui: Removes deprecated widget
     

   • दूसरी लाइन: खाली लाइन. हेडलाइन के बाद एक खाली लाइन छोड़ें.

   • तीसरी लाइन: बॉडी. ज़्यादा जानकारी दें. इसमें ज़्यादा से ज़्यादा 72 वर्ण हो सकते हैं. बताएं कि बदलाव से कौनसी समस्या हल होती है और कैसे. हालांकि, बॉडी देना ज़रूरी नहीं है. फिर भी, यह उन लोगों के लिए मददगार होती है जिन्हें बदलाव के बारे में जानकारी चाहिए. किसी भी तरह की मान्यताओं या बैकग्राउंड की जानकारी का एक संक्षिप्त नोट ज़रूर शामिल करें. यह जानकारी तब ज़रूरी हो सकती है, जब कोई दूसरा योगदान देने वाला व्यक्ति इस फ़ीचर पर काम कर रहा हो.

   कमिट की अच्छी जानकारी (उदाहरणों के साथ) के बारे में ब्लॉग पढ़ने के लिए, Git कमिट मैसेज कैसे लिखें लेख पढ़ें.

4. कमिट सेव करें.

repo init के दौरान दिया गया, बदलाव का यूनीक आईडी, आपका नाम, और ईमेल पता, आपके कमिट मैसेज में अपने-आप जुड़ जाता है.

समीक्षा के लिए बदलाव अपलोड करना

अपनी निजी Git हिस्ट्री में बदलाव कमिट करने के बाद, उसे Gerrit पर अपलोड करें:

1. अपने सभी प्रोजेक्ट में किए गए सभी कमिट अपलोड करने के लिए, यह कमांड चलाएं:

   repo upload

   अपलोड में, सभी प्रोजेक्ट में किए गए सभी बदलाव शामिल होते हैं.

   लेख पढ़ें

   आपको हुक स्क्रिप्ट चलाने के लिए कहा जाता है.

2. a दबाएं और फिर Enter दबाएं.

   आपको अपलोड की अनुमति देने के लिए कहा जाता है:

   Upload project frameworks/native/ to remote branch android17-release:
   branch BRANCH_NAME ( 1 commit, Wed Aug 7 09:32:33 2019 -0700):
          ff46b36d android codelab change
   to https://android-review.googlesource.com/ (y/N)?
   

3. अपलोड की अनुमति देने के लिए, y दबाएं और फिर Enter दबाएं.

आपको remote: SUCCESS जैसा मैसेज मिलेगा.

समीक्षा का अनुरोध करना

अपलोड हो जाने के बाद, Repo आपको Gerrit में किए गए बदलावों का लिंक देता है. समीक्षा सर्वर पर अपने बदलाव देखने, टिप्पणियां जोड़ने या अपने बदलाव की समीक्षा करने के लिए खास समीक्षकों का अनुरोध करने के लिए, लिंक पर क्लिक करें. कोड में किए गए सभी बदलावों की समीक्षा, कोड के सही मालिकों को करनी चाहिए.

समीक्षा का अनुरोध करने के लिए:

1. Gerrit में, OWNERS के लिए सुझाव दें पर क्लिक करें:

   

   पहली इमेज. Gerrit में, मालिकों के लिए सुझाव दें लिंक.

   समीक्षक का डायलॉग दिखता है. इस डायलॉग में, कोड के उन मालिकों की सूची होती है जो आपके बदलाव की समीक्षा कर सकते हैं.

2. अपनी समीक्षा में किसी कोड के मालिक को जोड़ने के लिए, उस पर क्लिक करें.

   भेजें बटन चालू हो जाता है.

3. (ज़रूरी नहीं) किसी ऐसे व्यक्ति का ईमेल पता डालें जिससे आपको अपने बदलाव की समीक्षा करानी है.

4. समीक्षा के लिए बदलाव भेजने के लिए, भेजें पर क्लिक करें.

कोड के मालिक, आपके कोड में किए गए बदलावों की समीक्षा करते हैं. अगर वे बदलाव स्वीकार कर लिए जाते हैं, तो वे बदलावों को चेरीपिक करते हैं और उन्हें इंटरनल डेवलपमेंट ब्रांच में मर्ज कर देते हैं.

बदलाव की स्थिति तय करना

अपने बदलाव में मौजूद फ़ाइलों की स्थिति तय करने के लिए, बदलाव में मौजूद फ़ाइलों के बगल में मौजूद इन आइकॉन को देखें:

• done (सही का निशान वाला आइकॉन): कोड के मालिक ने अनुमति दे दी है
• clear (क्रॉस का निशान वाला आइकॉन): कोड के मालिक ने अनुमति नहीं दी है
• access_time (घड़ी का आइकॉन): कोड के मालिक की अनुमति बाकी है

नीचे दी गई इमेज में, बदलाव में मौजूद फ़ाइलों पर लागू किए गए स्थिति के ये आइकॉन दिखाए गए हैं:

दूसरी इमेज. कोड के मालिक की अनुमति दिखाने वाले आइकॉन वाली फ़ाइलों का उदाहरण.

सुझावों के मुताबिक बदलाव करना और बदलाव की जगह दूसरा वर्शन अपलोड करना

अगर कोई समीक्षक, आपके अपडेट में बदलाव करने का अनुरोध करता है, तो Git में अपने कमिट में बदलाव किया जा सकता है. इससे, उसी बदलाव के लिए एक नया पैचसेट बनता है.

repo start EXISTING_BRANCH_NAME

सुझावों के मुताबिक बदलाव करने और अपने बदलाव में सुधार करने के लिए:

1. बदलाव करना और उसे टेस्ट करना लेख में दूसरा से चौथा चरण देखें.

2. अपने बदलाव में सुधार करने के लिए, यह कमांड चलाएं:

   git add -A
   git commit --amend

3. अपना बदलाव अपलोड करें.

बदलाव में सुधार करने के बाद, उसे अपलोड करने पर, वह Gerrit और आपके लोकल Git हिस्ट्री, दोनों में ओरिजनल बदलाव की जगह ले लेता है.

सिंक करने से जुड़ी समस्याओं को हल करना

अगर सोर्स ट्री में ऐसे अन्य बदलाव सबमिट किए जाते हैं जो आपके बदलावों से टकराते हैं, तो आपको एक मैसेज मिलता है. इसमें बताया जाता है कि आपके बदलावों में समस्याएं हैं. समस्याओं को हल करने के लिए:

1. पक्का करें कि आप कोड के सबसे नए वर्शन पर काम कर रहे हों:

   repo sync .

   repo sync कमांड, सोर्स सर्वर से अपडेट फ़ेच करता है. इसके बाद, यह आपके HEAD को नए रिमोट HEAD पर अपने-आप रीबेस करने की कोशिश करता है.

2. अगर रीबेस अपने-आप नहीं होता है, तो मैन्युअल तरीके से रीबेस करें:

   repo rebase .

3. मर्ज करने से जुड़ी समस्याओं को हल करें. अगर आपके पास मर्ज करने से जुड़ी समस्याओं को हल करने का कोई पसंदीदा तरीका नहीं है, तो फ़ाइलों के बीच की समस्याओं को मैन्युअल तरीके से ठीक करने के लिए, का इस्तेमाल किया जा सकता है.git mergetool

4. समस्याओं वाली फ़ाइलों को ठीक करने के बाद, नए कमिट लागू करने के लिए यह कमांड चलाएं:

   git rebase --continue

बदलाव सबमिट करना

समीक्षा और पुष्टि की प्रोसेस पूरी होने के बाद, कोड का मालिक आपके लिए कोड सबमिट करता है. यह कोड, उस ब्रांच पर सबमिट किया जाता है जिस पर बदलाव की समीक्षा की गई थी या किसी इंटरनल ब्रांच पर सबमिट किया जाता है.

आपका सबमिशन मर्ज होने के बाद, Android Continuous Integration डैशबोर्ड पर जाकर यह देखा जा सकता है कि आपके सबमिशन, ट्री में कब इंटिग्रेट किए गए हैं.