इस पेज पर, Android Open Source Project (AOSP) में कोड में किए गए बदलावों को सबमिट करने की पूरी प्रोसेस के बारे में बताया गया है. इसमें समीक्षा का अनुरोध करने और अपने बदलावों को ट्रैक करने का तरीका भी शामिल है.
AOSP, Gerrit पर निर्भर करता है. यह वेब पर काम करने वाला कोड रिव्यू सिस्टम है. इसका इस्तेमाल उन प्रोजेक्ट के लिए किया जाता है जो Git का इस्तेमाल करते हैं.
योगदान देने वाले के लाइसेंस के कानूनी समझौतों पर हस्ताक्षर करना
AOSP के लिए कोड में कोई भी बदलाव करने से पहले, आपको योगदान देने वाले के लिए लाइसेंस से जुड़े कानूनी समझौते और हेडर पढ़ने होंगे. साथ ही, इनमें से किसी एक कानूनी समझौते पर हस्ताक्षर करना होगा:
- अगर आपको सिर्फ़ अपने लिए योगदान देना है, तो योगदान देने वाले के लाइसेंस के लिए कानूनी समझौते पर हस्ताक्षर करें.
- अगर आप किसी कंपनी के कर्मचारी हैं, तो पक्का करें कि आपकी कंपनी ने कॉर्पोरेट कॉन्ट्रिब्यूटर लाइसेंस समझौते पर हस्ताक्षर किया हो. इससे आपको कंपनी की ओर से योगदान करने की अनुमति मिलती है.
कोई ब्रांच शुरू करना
कोड में किए जाने वाले हर बदलाव के लिए, यह तरीका अपनाएं:
Git की संबंधित रिपॉज़िटरी में नई ब्रांच शुरू करें. ब्रांच, ओरिजनल फ़ाइलों की कॉपी नहीं होती. यह किसी खास कमिट का पॉइंटर होता है. इससे लोकल ब्रांच बनाना और उनके बीच स्विच करना आसान हो जाता है. ब्रांच का इस्तेमाल करके, एक-दूसरे में हुए बदलावों की पहचान की जा सकती है. ब्रांच शुरू करने के लिए, यह निर्देश चलाएं:
repo start BRANCH_NAME
एक ही रिपॉज़िटरी में, एक ही समय पर कई इंडिपेंडेंट ब्रांच शुरू की जा सकती हैं. ब्रांच BRANCH_NAME आपके वर्कस्पेस के लिए लोकल है. इसे न तो Gerrit में शामिल किया गया है और न ही फ़ाइनल सोर्स ट्री में. ब्रांच, उस प्रोजेक्ट के हिसाब से भी तय होती हैं जिसमें आप काम कर रहे हैं. इसलिए, अगर आपको एक ही बदलाव के तहत अलग-अलग प्रोजेक्ट में फ़ाइलें बदलनी हैं, तो आपको हर उस प्रोजेक्ट में एक ब्रांच की ज़रूरत होगी जहां आपको फ़ाइलें बदलनी हैं.
(ज़रूरी नहीं) पुष्टि करें कि ब्रांच बन गई है:
repo status .
आपको अपनी नई ब्रांच दिखेगी. उदाहरण के लिए:
project frameworks/native/ branch mynewbranch
बदलाव करना और उसकी जांच करना
बदलाव करने और उसकी जांच करने के लिए, यह तरीका अपनाएं:
यह पक्का करने के लिए कि आप सबसे नए कोडबेस के साथ काम कर रहे हैं, पूरे कोडबेस को सिंक करें:
repo sync
अगर सिंक करने के दौरान कोई समस्या आती है, तो सिंक करने से जुड़ी समस्याएं हल करना लेख में दिए गए चरण 2 से 4 देखें.
वह कोड ढूंढें जिसमें बदलाव करना है. कोड ढूंढने के लिए, Android Code Search का इस्तेमाल करें. Android कोड सर्च का इस्तेमाल करके, AOSP का सोर्स कोड देखा जा सकता है. यह कोड, AOSP का इस्तेमाल करते समय दिखता है. ज़्यादा जानकारी के लिए, Code Search का इस्तेमाल शुरू करना लेख पढ़ें. Android Code Search में, AOSP की नई रिलीज़ ब्रांच में मौजूद पूरा कोड देखने के लिए,
https://cs.android.com/android/platform/superproject/
पर जाएं.सोर्स फ़ाइलों में बदलाव करना या उन्हें जोड़ना. किए गए किसी भी बदलाव के लिए:
यह तय करें कि आपको सुविधा लॉन्च करने के फ़्लैग का इस्तेमाल करना है या नहीं. अगर हां, तो उन्हें अपने नए कोड के लिए लागू करें.
लाइसेंस हेडर शामिल करें में दिए गए सबसे सही तरीके अपनाएं.
Java कोड के लिए, योगदान देने वालों के लिए AOSP Java कोड स्टाइल का पालन करें.
AOSP के कुछ हिस्सों को Kotlin (
.kt
) में लिखा गया है. साथ ही, Kotlin में लिखे गए प्लैटफ़ॉर्म के हिस्सों में Kotlin का इस्तेमाल किया जा सकता है. Android में Kotlin के बारे में ज़्यादा जानने के लिए, Android डेवलपर की Kotlin स्टाइल गाइड और Kotlin-Java इंटरऑप गाइड देखें. Kotlin के बारे में ज़्यादा जानकारी के लिए, Kotlin लैंग्वेज साइट देखें.एपीआई लिखते समय, Android API के दिशा-निर्देशों का पालन करें. Android के एपीआई से जुड़े फ़ैसलों के पीछे का कॉन्टेक्स्ट जानने के लिए, इन दिशा-निर्देशों का इस्तेमाल करें. प्लैटफ़ॉर्म एपीआई में किए गए बदलावों और जोड़े गए एपीआई की पुष्टि Metalava करता है.
बदलाव को स्टेज करना और कमिट करना
कमिट, Git में वर्शन कंट्रोल की बुनियादी इकाई होती है. इसमें पूरे प्रोजेक्ट के लिए, डायरेक्ट्री स्ट्रक्चर और फ़ाइल के कॉन्टेंट का स्नैपशॉट शामिल होता है. बदलाव को सेव करने के लिए, यह तरीका अपनाएं:
डिफ़ॉल्ट रूप से, Git आपके किए गए बदलावों को रजिस्टर करता है, लेकिन उन्हें ट्रैक नहीं करता. Git को अपने बदलावों को ट्रैक करने का निर्देश देने के लिए, आपको उन बदलावों को मार्क करना होगा या उन्हें कमिट में शामिल करने के लिए स्टेज करना होगा. बदलाव को स्टेज करने के लिए, यह निर्देश चलाएं:
git add -A
इस कमांड से, किसी भी फ़ाइल में किए गए बदलावों को ट्रैक किया जाता है.
स्टेजिंग एरिया में मौजूद फ़ाइलों को लें और उन्हें अपने लोकल डेटाबेस में सेव करें या कमिट करें:
git commit -s
डिफ़ॉल्ट रूप से, टेक्स्ट एडिटर खुलता है और आपसे कमिट मैसेज देने के लिए कहा जाता है.
इस फ़ॉर्मैट में कमिट मैसेज दें:
लाइन 1: हेडलाइन. बदलाव के बारे में एक लाइन में खास जानकारी दें. इसमें ज़्यादा से ज़्यादा 50 वर्ण होने चाहिए. आपने जिस हिस्से में बदलाव किया है उसके बारे में बताने के लिए, प्रीफ़िक्स का इस्तेमाल करें. इसके बाद, इस कमिट में किए गए बदलाव के बारे में बताएं. उदाहरण के लिए, यहां दिए गए उदाहरण में यूज़र इंटरफ़ेस में किए गए बदलाव के बारे में बताया गया है:
ui: Removes deprecated widget
लाइन 2: खाली लाइन. हेडलाइन के बाद एक लाइन खाली छोड़ें.
लाइन 3: मुख्य हिस्सा. ज़्यादा से ज़्यादा 72 वर्णों की लंबी जानकारी दें. बताएं कि बदलाव से कौनसी समस्या हल होती है और कैसे. हालांकि, बॉडी जोड़ना ज़रूरी नहीं है, लेकिन इससे उन लोगों को मदद मिलती है जिन्हें बदलाव के बारे में दोबारा जानना होता है. इस बात का ध्यान रखें कि आपने कोई भी अनुमान या बैकग्राउंड की जानकारी शामिल की हो. यह जानकारी तब अहम हो सकती है, जब कोई अन्य योगदानकर्ता इस सुविधा पर काम कर रहा हो.
अच्छे कमिट ब्यौरे (उदाहरणों के साथ) के बारे में ब्लॉग पढ़ने के लिए, Git कमिट मैसेज लिखने का तरीका देखें.
कमिट सेव करें.
बदलाव का यूनीक आईडी, आपका नाम, और ईमेल पता आपके कमिट मैसेज में अपने-आप जुड़ जाता है. ये जानकारी repo init
के दौरान दी गई थी.
बदलाव को समीक्षा के लिए अपलोड करें
Git के अपने निजी इतिहास में बदलाव करने के बाद, उसे Gerrit पर अपलोड करें:
अपने सभी प्रोजेक्ट में किए गए सभी कमिट अपलोड करने के लिए, यह कमांड चलाएं:
repo upload
अपलोड किए गए डेटा में, सभी प्रोजेक्ट में किए गए सभी बदलाव शामिल होते हैं.
लेख पढ़ेंआपको हुक स्क्रिप्ट चलाने के लिए कहा जाता है.
पहले a और फिर Enter दबाएं.
आपको अपलोड करने की अनुमति देने के लिए कहा जाएगा:
Upload project frameworks/native/ to remote branch android16-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)?
अपलोड करने की अनुमति देने के लिए, y और फिर Enter दबाएं.
आपको remote: SUCCESS
जैसा मैसेज मिलेगा.
समीक्षा का अनुरोध करें
अपलोड हो जाने के बाद, Repo आपको Gerrit में किए गए बदलावों का लिंक देता है. समीक्षा सर्वर पर अपने बदलाव देखने, टिप्पणियां जोड़ने या अपने बदलाव की समीक्षा करने के लिए खास समीक्षकों से अनुरोध करने के लिए, लिंक पर क्लिक करें. कोड में किए गए सभी बदलावों की समीक्षा, कोड के सही मालिकों को करनी चाहिए.
समीक्षा का अनुरोध करने के लिए:
Gerrit में, SUGGEST OWNERS पर क्लिक करें:
पहली इमेज. Gerrit में मालिकों को लिंक करने का सुझाव देना.
आपको समीक्षक डायलॉग दिखेगा. इस डायलॉग में, कोड के उन मालिकों की सूची होती है जो आपके बदलाव की समीक्षा कर सकते हैं.
समीक्षा में किसी कोड के मालिक को जोड़ने के लिए, उस पर क्लिक करें.
भेजें बटन चालू हो जाता है.
(ज़रूरी नहीं) उस व्यक्ति का ईमेल पता डालें जिसे आपको बदलाव की समीक्षा करने के लिए कहना है.
बदलाव को समीक्षा के लिए भेजने के लिए, भेजें पर क्लिक करें.
कोड के मालिक, आपके कोड में किए गए बदलावों की समीक्षा करते हैं. अगर वे बदलाव स्वीकार कर लिए जाते हैं, तो वे बदलाव को चुनकर उसे इंटरनल डेवलपमेंट ब्रांच में मर्ज कर देते हैं.
बदलाव की स्थिति का पता लगाना
बदलाव में शामिल फ़ाइलों का स्टेटस जानने के लिए, बदलाव में शामिल फ़ाइलों के बगल में मौजूद इन आइकॉन को देखें:
- (सही का निशान आइकॉन): कोड के मालिक ने मंज़ूरी दी है
- (क्रॉस आइकॉन): कोड के मालिक ने मंज़ूरी नहीं दी है
- (घड़ी का आइकॉन): कोड के मालिक से अनुमति मिलना बाकी है
नीचे दिए गए डायग्राम में, बदलाव में मौजूद फ़ाइलों पर लागू किए गए स्टेटस आइकॉन दिखाए गए हैं:
दूसरी इमेज. उन फ़ाइलों का उदाहरण जिनमें कोड के मालिक की मंज़ूरी दिखाने वाले आइकॉन मौजूद हैं.
सुझाव को स्वीकार करें और बदलाव के लिए दूसरा अनुरोध अपलोड करें
अगर समीक्षक आपके अपडेट में बदलाव करने का अनुरोध करता है, तो Git में अपने कमिट में बदलाव किया जा सकता है. इससे एक ही बदलाव पर नया पैचसेट बन जाता है.
सुझाव/राय/शिकायत को हल करने और बदलाव को ठीक करने के लिए:
बदलाव करना और उसकी जांच करना में दिए गए दूसरे से चौथे चरण तक का तरीका अपनाएं.
बदलाव को ठीक करने के लिए, ये कमांड चलाएं:
git add -A git commit --amend
बदलाव को अपलोड करने पर, यह Gerrit और आपके लोकल Git के इतिहास, दोनों में ओरिजनल बदलाव की जगह ले लेता है.
सिंक करने से जुड़ी समस्याएं हल करना
अगर सोर्स ट्री में ऐसे बदलाव सबमिट किए जाते हैं जो आपके बदलावों से मेल नहीं खाते, तो आपको एक मैसेज मिलेगा. कॉन्फ़्लिक्ट ठीक करने के लिए:
पक्का करें कि आपके पास सबसे नया कोड हो:
repo sync .
repo sync
कमांड, सोर्स सर्वर से अपडेट फ़ेच करती है. इसके बाद, यह आपकेHEAD
को नए रिमोटHEAD
पर अपने-आप रीबेस करने की कोशिश करती है.अगर अपने-आप रीबेस होने की प्रोसेस पूरी नहीं होती है, तो मैन्युअल तरीके से रीबेस करें:
repo rebase .
मर्ज करने से जुड़ी गड़बड़ियां ठीक करें. अगर आपको मर्ज करने से जुड़ी समस्याओं को हल करने का कोई तरीका नहीं पता है, तो फ़ाइलों के बीच की समस्याओं को मैन्युअल तरीके से ठीक करने के लिए,
git mergetool
का इस्तेमाल करें.फ़ाइलों में मौजूद टकराव ठीक करने के बाद, नए कमिट लागू करने के लिए यह निर्देश चलाएं:
git rebase --continue
बदलाव सबमिट करें
समीक्षा और पुष्टि की प्रक्रिया पूरी होने के बाद, कोड का मालिक आपके लिए कोड सबमिट करता है. ऐसा उस ब्रांच पर किया जाता है जिस पर बदलाव की समीक्षा की गई थी या किसी इंटरनल ब्रांच में किया जाता है.
सबमिट किया गया आपका डेटा मर्ज होने के बाद, Android Continuous Integration डैशबोर्ड पर जाकर यह देखा जा सकता है कि आपका डेटा ट्री में कब इंटिग्रेट किया गया है.