प्रोजेक्ट से प्रोजेक्ट तक, हम देखते हैं कि हमारा कोड समान कार्य करता है और लगभग समान दिखता है। यह हमें आश्चर्यचकित करता है - क्या हम एक ही चीज को दोबारा लिखकर अतिरिक्त काम नहीं कर रहे हैं? हम पिछली परियोजनाओं से कक्षाएं कॉपी करना शुरू करते हैं और फिर भी समझते हैं कि हम कुछ गलत कर रहे हैं और सही हैं - बस एक परियोजना से एक परियोजना के लिए कक्षाएं कॉपी कर रहे हैं, हम आसानी से कुछ खो सकते हैं / बदल सकते हैं / और यदि हमारी टीम कुछ और ले जाती है एक साथ परियोजनाएं, फिर उधार कक्षाओं में त्रुटि का पता लगाने के लिए सभी परियोजनाओं में मैन्युअल परिवर्तन की आवश्यकता होगी। इस रेक पर कदम रखते हुए, हम तय करते हैं कि हमें एक समान कोड की आवश्यकता है जिसे हमारी सभी परियोजनाओं पर साझा किया जाएगा और इसमें कोई भी परिवर्तन आसानी से खींच लिया जाएगा। हाँ, हम पुन: प्रयोज्य घटकों के अपने पुस्तकालय का निर्माण कर रहे हैं! आप अपने पुस्तकालय को व्यवस्थित करने के विभिन्न तरीकों के बारे में जानेंगे, बिल्ली के नीचे आने वाले सभी पेशेवरों और विपक्षों के बारे में :)

हमारे सामान्य कोड आधार को व्यवस्थित करने के कई तरीके हैं:

1. Android लाइब्रेरी (aar / jar)
2. गिट उपमॉडल
3. गिट उपट्टी

Android लाइब्रेरी (aar / jar)

हमारे आवेदन के लिए कोई भी पुस्तकालय केवल एक निश्चित तरीके से आयोजित की जाने वाली कक्षाओं का एक बहुत कुछ है। हर बार जब हम build.gradle में कुछ रेट्रोफिट या डैगर को जोड़ते हैं , तो हम लाइब्रेरी को प्रकाशित करने वाले प्लेटफार्मों में से एक से अनार / जार संग्रह के रूप में पुस्तकालय को लोड करते हैं। सबसे लोकप्रिय पुस्तकालय प्रकाशन प्लेटफॉर्म JCenter और MavenCentral हैं। पुस्तकालय के डेवलपर्स नए संस्करण पर अपने भंडार में काम करते हैं, और जब संस्करण दुनिया में बाहर जाने के लिए तैयार हो जाता है, तो वे इसे एक प्लेटफॉर्म पर प्रकाशित करते हैं और कहते हैं "अरे, हमने अपने शीर्ष पुस्तकालय का एक नया संस्करण जारी किया!"। उन सभी के लिए जो डेवलपर्स के लिए किया जाता है जो अपनी परियोजनाओं में इस दायित्व का उपयोग करते हैं, बिल्ड.ग्रेड में संस्करण को बदलना और नई सुविधाओं का आनंद लेना है। क्या यह सुविधाजनक है? गलत शब्द!

लेकिन यह दृष्टिकोण कितना सुविधाजनक है यदि हमारी लाइब्रेरी विकसित हो रही है और हर दिन हमारी टीम की विभिन्न परियोजनाओं के विभिन्न डेवलपर्स द्वारा नई सुविधाओं के साथ अपडेट किया गया है? आइए देखें कि यह व्यवहार में कैसा दिखता है।

हम अपने पुस्तकालय का भंडार बनाते हैं, वहां कुछ सुविधाएँ जोड़ते हैं, इसे डीबग करते हैं, और इसे अपनी टीम के साथ साझा करने के लिए तैयार हैं। फिर हम JCenter, MavenCentral, Bintray, Jitpack.io जैसे शब्दों के बारे में जानेंगे ... ये सभी पुस्तकालयों के प्रकाशन के लिए मंच हैं। अब एंड्रॉइड प्रोजेक्ट्स का मुख्य प्लेटफॉर्म JCenter है। यदि आप एक परियोजना बनाते हैं, तो आप देखेंगे कि रिपॉजिटरी में बिल्ड.ग्रेडल (प्रोजेक्ट स्तर) में, जेसीटीआर निर्दिष्ट है

repositories { google() jcenter() } 

यही है, अगर डेवलपर आपकी लाइब्रेरी को कनेक्ट करना चाहता है, तो यह उसके लिए बिल्ड.ग्रेड मॉड्यूल स्तर से कनेक्ट करने के लिए पर्याप्त होगा।

मेरे लिए लाइब्रेरी प्रकाशित करने का सबसे आसान तरीका लगता है Jitpack.io, कुछ चरणों और आपकी लाइब्रेरी का उपयोग करने के लिए तैयार है।

लाइब्रेरी पर टीम के काम को कैसे व्यवस्थित करें

यदि हमने एक लाइब्रेरी बनाई और उसे रिपॉजिटरी में अपलोड कर दिया, तो हमारी बाकी टीम के पास केवल प्राप्त जार / aar आर्काइव है। पूरी टीम के लिए किसी भी काम करने में सक्षम होने के लिए - प्रत्येक डेवलपर को पुस्तकालय के भंडार का बचाव करना चाहिए और उसमें बदलाव करना चाहिए।

वर्ज़निंग

पुस्तकालयों का विकास और उपयोग करते समय, किसी को संस्करण के रूप में इस तरह की अवधारणा से निपटना पड़ता है। यही है, लाइब्रेरी में उन परिवर्तनों का सेट जिन्हें हम प्रकाशित करना चाहते हैं, उन्हें संस्करण द्वारा तय किया जाना चाहिए। यह समझने में मदद मिलेगी कि लाइब्रेरी को एक नए संस्करण में अपडेट करते समय, यह समझने के लिए कि गंभीर / ब्रेकिंग परिवर्तन कैसे किए गए हैं, अपनाया संस्करण योजना के लिए धन्यवाद।

परियोजना में पुस्तकालय की जाँच करना

यह सत्यापित करने के लिए कि किए गए परिवर्तन हम क्या करते हैं - परियोजना में लिखित कोड के व्यवहार की जांच करना आवश्यक है। हम पुस्तकालय के संस्करण को बढ़ाते हैं और ... यहां इस दृष्टिकोण की बाधाओं में से एक है। हमारी लाइब्रेरी और प्रोजेक्ट अलग-अलग रिपॉजिटरी में हैं, जिसका मतलब है कि हमें प्रोजेक्ट में सिर्फ लाइब्रेरी क्लास नहीं मिल सकती है। नया पुस्तकालय कोड देखने के लिए हमारे पास 2 विकल्प हैं:

1. नमूना लाइब्रेरी प्रोजेक्ट में एक मॉड्यूल बनाएं जिसमें कोड लिखा जाएगा जो लाइब्रेरी की कार्यक्षमता की जांच करता है। विकल्प सरल है, लेकिन 2 minuses हैं: 1. हम अतिरिक्त कोड लिखते हैं; 2. परीक्षण मॉड्यूल का वातावरण वास्तविक परियोजना से अलग है जिसमें हम पुस्तकालय का उपयोग करेंगे, और यदि हम गलतियां करते हैं, तो यह तब पॉप अप होगा जब हमें परियोजना का नया संस्करण मिलेगा।
2. स्थानीय mavenLocal रिपॉजिटरी में परिवर्तन पोस्ट करें। इस दृष्टिकोण के लिए धन्यवाद, आप परियोजना में एक नया कोड प्राप्त कर सकते हैं, लेकिन यह पूरी टीम के लिए प्रकाशित नहीं किया जाएगा (लेकिन आपको सेटअप के साथ थोड़ा सा छेड़छाड़ करने की आवश्यकता है)।

गिट उपमॉडल

पिछले दृष्टिकोण में, हमने प्रोजेक्ट में विकास / डिबगिंग चरण में नया कोड प्राप्त करने में कठिनाई का सामना किया, क्योंकि लाइब्रेरी और प्रोजेक्ट कोड विभिन्न रिपॉजिटरी और स्टूडियो प्रोजेक्ट में हैं। Git सबमॉड्यूल दृष्टिकोण में अलग-अलग रिपॉजिटरी का उपयोग भी शामिल है, लेकिन मुख्य प्रोजेक्ट को लाइब्रेरी का उपयोग कर मॉड्यूल के रूप में प्राप्त करने की अनुमति देता है। इसका मतलब यह है कि परियोजना में पुस्तकालय कोड उपलब्ध होगा और परियोजना में सभी परिवर्तन तुरंत उपलब्ध होंगे!

यह कैसे काम करता है

सबमॉड्यूल्स आपको एक Git रिपॉजिटरी को दूसरे Git रिपॉजिटरी के उपनिर्देशिका के रूप में शामिल करने की अनुमति देता है। यह इस भंडार के लिए एक और रिपॉजिटरी को क्लोन करने के लिए संभव बनाता है, इस रिपॉजिटरी के लिए अलग से कमिट्स को संग्रहीत करता है।

सीधे शब्दों में कहें, हमारे पास 2 रिपॉजिटरी हैं: एक परियोजना और एक पुस्तकालय। परियोजना भंडार पुस्तकालय कोड और पुस्तकालय भंडार की स्थिति के लिए एक लिंक संग्रहीत करता है। इसलिए Git समझता है कि परियोजना के लिए पुस्तकालय के किस राज्य (संस्करण) की आवश्यकता है।

Git Submodule यहां कैसे काम करता है, इसके बारे में और पढ़ें ।

टीमवर्क कैसे व्यवस्थित करें

Git Submodule दृष्टिकोण में, लाइब्रेरी पर टीम वर्क निम्नानुसार आयोजित किया जाता है:

1. जब एक नया प्रोजेक्ट बनाते हैं या किसी मौजूदा प्रोजेक्ट के लिए लाइब्रेरी को कनेक्ट करते हैं, तो प्रोजेक्ट के नाम के साथ मास्टर से एक नई गिट ब्रांच बनाई जाती है।
2. जब लाइब्रेरी को कुछ कार्यक्षमता के साथ फिर से भरने का समय आता है, तो कार्य के लिए एक शाखा (परियोजना शाखा से) बनाई जाती है और वहां परिवर्तन किए जाते हैं।
3. एक समीक्षा की जा रही है, पूल को परियोजना शाखा में डाला जा रहा है। जब संस्करण को जारी करने के लिए पर्याप्त परिवर्तन टाइप किए जाते हैं, तो लाइब्रेरी के मास्टर शाखा में परियोजना शाखा के विलय पर एक पूल बनाया जाता है।
4. पूल द्वारा लाइब्रेरी के लिए ज़िम्मेदार टीम द्वारा समीक्षा पारित करने और मास्टर शाखा में डालने के बाद, शेष प्रोजेक्ट टीमों को लाइब्रेरी अपडेट के बारे में सूचित किया जाएगा जो दिखाई दिया है और अपडेट पर निर्णय करेगा।

वर्ज़निंग

जब पूल को मास्टर में डाला गया था, और टीमों को लाइब्रेरी अपडेट के बारे में सूचित किया गया है, तो उन्हें इस बात की जानकारी नहीं है कि नए संस्करण में परिवर्तन कितने वैश्विक हैं। आखिरकार, Git Submodule के साथ दृष्टिकोण को किसी भी संस्करण योजना की आवश्यकता नहीं है। लेकिन वर्जनिंग स्कीम शुरू करने से यह समस्या आसानी से हल हो जाती है। सभी आवश्यक है कि एक संस्करण लिखना है और मास्टर शाखा में पूल अनुरोध के विवरण में क्या बदलाव और जोड़ा गया है। तब डेवलपर्स समझेंगे कि वे अब वास्तव में लाइब्रेरी के नए संस्करण में कैसे अपग्रेड कर सकते हैं। यह बहुत अच्छा लगता है, लेकिन सवाल यह है:

हां, स्टूडियो को यह नहीं पता है कि सबमॉडल द्वारा जुड़े लिब को अलग से कैसे प्रतिबद्ध किया जाए। मैं इस समस्या को हल करने के लिए SourceTree का उपयोग करता हूं। यह एप्लिकेशन विंडोज और मैक के लिए है, और लिनक्स के लिए GitKraken है।

गिट उपट्टी

Git सबटाइटल Git Submodule का एक उन्नत संस्करण है। गिट सबट्री में उन्होंने उन समस्याओं को हल करने की कोशिश की, जो डेवलपर्स ने गिट सबमॉड्यूल के साथ काम करते समय सामना किया, हब पर एक अच्छा लेख है जो उपकरणों के बीच अंतर का वर्णन करता है। हालांकि वे अलग तरह से काम करते हैं, लेकिन वे एक समस्या को हल करते हैं।

निष्कर्ष

कई प्रोजेक्ट्स में शामिल टीम के लिए कॉमन कोड बेस बनाने की समस्या को हल करने के लिए Git Submodule / सबट्री टूल महान हैं। एक महत्वपूर्ण लाभ यह है कि लाइब्रेरी में बदलाव करने के बाद प्रोजेक्ट पर नए कोड का तत्काल सत्यापन किया जाता है। इसमें, JCenter या MavenCentral को एक पुस्तकालय प्रकाशित करने का मानक दृष्टिकोण हीन है। यदि आप अपनी टीम के लिए गिट सबमॉड्यूल / सबट्री लेने का निर्णय लेते हैं, तो संस्करण योजना के बारे में पहले से सोचें, और संस्करण को नियंत्रित करने के लिए नियम / प्लगइन्स बनाएं।

सभी के लिए महान पुन: उपयोग!