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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

इस पेज पर, 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 कोड सर्च का इस्तेमाल करें. AOSP सोर्स कोड को उसी तरह देखने के लिए, Android कोड खोज का इस्तेमाल किया जा सकता है जिस तरह इसे इस्तेमाल करने पर दिखता है. ज़्यादा जानकारी के लिए, कोड सर्च का इस्तेमाल शुरू करना देखें. 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 एपीआई के दिशा-निर्देशों का पालन करें. Android के एपीआई से जुड़े फ़ैसलों के बारे में जानने के लिए, इन दिशा-निर्देशों का इस्तेमाल करें. प्लैटफ़ॉर्म एपीआई में जोड़े गए एपीआई और उनमें किए गए बदलावों की पुष्टि, Metalava करता है.

4. Android बनाएं.

5. अपने बिल्ड की जांच करें.

बदलाव को स्टेज करना और उसे लागू करना

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

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

   git add -A

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

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

   git commit -s

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

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

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

     ui: Removes deprecated widget
     

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

   • तीसरी लाइन: मुख्य हिस्सा. लंबी जानकारी दें, जो ज़्यादा से ज़्यादा 72 वर्णों पर हार्ड-रैप हो. बताएं कि बदलाव से कौनसी समस्या हल होती है और कैसे. हालांकि, बॉडी का इस्तेमाल करना ज़रूरी नहीं है, लेकिन यह उन लोगों के लिए मददगार होता है जिन्हें बदलाव को फिर से देखना होता है. किसी भी अनुमान या बैकग्राउंड की ऐसी जानकारी को ज़रूर शामिल करें जो किसी दूसरे योगदान देने वाले के लिए इस सुविधा पर काम करते समय अहम हो सकती है.

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

4. बदलावों को सेव करें.

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

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

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

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

   repo upload

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

   लेख पढ़ें

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

2. पहले a और फिर Enter दबाएं.

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

   Upload project frameworks/native/ to remote branch android15-qpr2-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 में, मालिकाना हक के लिए सुझाव दें पर क्लिक करें:

   

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

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

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

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

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

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

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

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

बदलाव में शामिल फ़ाइलों का स्टेटस जानने के लिए, बदलाव में शामिल फ़ाइलों के बगल में मौजूद ये आइकॉन देखें:

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

नीचे दिए गए इलस्ट्रेशन में, बदलाव में फ़ाइलों पर लागू किए गए स्टेटस आइकॉन दिखाए गए हैं:

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

सुझाव/राय/शिकायत को हल करना और बदलाव अपलोड करना

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

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

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 के लिए लगातार इंटिग्रेशन डैशबोर्ड पर जाकर, यह देखा जा सकता है कि आपके सबमिशन ट्री में कब इंटिग्रेट किए गए.