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

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

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

योगदान देने वाले के लाइसेंस के कानूनी समझौतों पर हस्ताक्षर करना

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

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

ध्यान दें: Android के इस्तेमाल किए जाने वाले अपस्ट्रीम प्रोजेक्ट में बदलाव करने के लिए, आपको सीधे उस प्रोजेक्ट में बदलाव करने होंगे. ज़्यादा जानकारी के लिए, अपस्ट्रीम प्रोजेक्ट में योगदान देना लेख पढ़ें.

कोई शाखा शुरू करना

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

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

   repo start BRANCH_NAME
   

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

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

   repo status .
   

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

   project frameworks/native/                      branch mynewbranch
   

   ध्यान दें: सभी शाखाओं की सूची पाने के लिए, repo branches का इस्तेमाल भी किया जा सकता है. इसमें मौजूदा शाखा (अगर कोई है) के आगे तारे का निशान (*) दिखेगा.

बदलाव करना और उसकी जांच करना

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

1. यह पक्का करने के लिए कि आप सबसे नए कोडबेस के साथ काम कर रहे हैं, पूरे कोडबेस को सिंक करें:

   repo sync
   

   ध्यान दें: सिर्फ़ मौजूदा प्रोजेक्ट को सिंक करने के लिए, repo sync कमांड में बिंदु (.) जोड़ें: repo sync .. मौजूदा प्रोजेक्ट को सिंक करना, पूरी रिपॉज़िटरी को सिंक करने से ज़्यादा तेज़ होता है.

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

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

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
   

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

   ध्यान दें: अगर आपको सिर्फ़ किसी फ़ाइल में किए गए बदलावों को ट्रैक करना है, तो git add filename का इस्तेमाल करें.
   ध्यान दें: फ़ाइलों में किए गए बदलावों को ट्रैक करने के अलावा, git add का इस्तेमाल अन्य कार्रवाइयां करने के लिए भी किया जा सकता है. जैसे, फ़ाइल में बदलाव करना और उसे मिटाना.

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

   git commit -s
   

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

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

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

     ui: Removes deprecated widget
     

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

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

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

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

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

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

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

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

   repo upload
   

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

   ध्यान दें: सिर्फ़ मौजूदा प्रोजेक्ट में बदलाव अपलोड करने के लिए, repo upload कमांड में बिंदु (.) जोड़ें: repo upload ..
   ध्यान दें: अगर आपको किसी ऐसे बदलाव पर काम करना है जिसके लिए कई प्रोजेक्ट की फ़ाइलों में बदलाव करना ज़रूरी है, तो बदलावों को एक साथ जोड़ने के लिए Gerrit में किसी विषय का इस्तेमाल करें. भले ही, आपने repo upload या repo upload . का इस्तेमाल किया हो. Gerrit टॉपिक से यह पक्का होता है कि बदलावों को सबमिट करने से पहले जांचने और अपने-आप मर्ज होने की सुविधा के लिए, एक साथ रखा जाए. ज़्यादा जानकारी के लिए, विषय का इस्तेमाल करना
   लेख पढ़ें

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

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

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

   Upload project frameworks/native/ to remote branch main:
   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 में किए गए बदलावों का लिंक देता है. समीक्षा सर्वर पर अपने बदलाव देखने, टिप्पणियां जोड़ने या अपने बदलाव के लिए समीक्षकों से अनुरोध करने के लिए, लिंक पर क्लिक करें. कोड में किए गए सभी बदलावों की समीक्षा, कोड के मालिकों को करनी चाहिए.

ध्यान दें: AOSP में शामिल रिलीज़ कॉन्फ़िगरेशन, Google तय करता है. Google, कॉन्फ़िगरेशन की सुविधा के रिलीज़ फ़्लैग को अपडेट करने या बदलने के लिए, योगदान स्वीकार नहीं करता. इसके बजाय, AOSP के फ़ॉर्क में डिफ़ॉल्ट फ़्लैग वैल्यू के साथ-साथ, अपनी पसंद के मुताबिक रिलीज़ कॉन्फ़िगरेशन तय किए जा सकते हैं. रिलीज़ कॉन्फ़िगरेशन के बारे में ज़्यादा जानकारी के लिए, सुविधा लॉन्च करने के फ़्लैग की वैल्यू सेट करना लेख पढ़ें.

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

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

   

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

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

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

   ध्यान दें: यह समझने के लिए कि मालिकाना हक तय करने का तरीका क्या है, find-owners बैकएंड देखें.

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

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

4. (ज़रूरी नहीं) अनुमतियां मिलने के बाद, बदलाव अपने-आप सबमिट हो जाए, इसके लिए अपने-आप सबमिट करें के बगल में मौजूद +1 पर क्लिक करें. इस बटन पर क्लिक न करने पर, Google के किसी कर्मचारी को आपके बदलाव को सबमिट करना होगा.

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

कोड के मालिक, कोड में किए गए बदलावों की समीक्षा करते हैं. साथ ही, वे आपको सुझाव देते हैं, ताकि आप उन बदलावों को ठीक कर सकें या उन्हें स्वीकार कर सकें.

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

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

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

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

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

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

अगर समीक्षक आपके अपडेट में बदलाव करने का अनुरोध करता है, तो आपके पास 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
   

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

सबमिशन की समीक्षा और पुष्टि की प्रक्रिया पूरी होने के बाद, Google की समीक्षा करने वाले व्यक्ति को आपके लिए कोड सबमिट करना होगा. अन्य उपयोगकर्ता, अपने-अपने लोकल क्लाइंट में अपडेट लाने के लिए repo sync चला सकते हैं.

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