अंदर-बाहर करो

एक संस्करण नियंत्रण प्रणाली के अंदर काम करने की क्षमता एक कौशल है जो हर प्रोग्रामर को चाहिए। अक्सर यह लग सकता है कि Git में खुदाई करना और इसके इंटर्नल को समझना समय की एक अतिरिक्त बर्बादी है और बुनियादी कार्यों को आदेशों के एक मूल सेट के माध्यम से हल किया जा सकता है।

AppsCast टीम, निश्चित रूप से, और अधिक सीखना चाहती थी, और Git की सभी विशेषताओं के व्यावहारिक अनुप्रयोग पर सलाह के लिए, लोगों ने स्क्वायर से येगोर आंद्रेयेविच की ओर रुख किया।



डेनियल पोपोव : सभी को नमस्कार। आज, स्क्वायर से येगोर आंद्रेयेविच हमारे साथ जुड़े।

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

डेनियल पोपोव : एंड्रॉइड डेवलपर्स के वातावरण में, स्क्वायर को अपने ओपन-सोर्स प्रोजेक्ट्स के लिए जाना जाता है जो उद्योग के मानक बन गए हैं: ओक्हेट्प, पिकासो, रेट्रोफिट। यह तार्किक है कि ऐसे उपकरण सभी के लिए खुले हैं, आप Git के साथ बहुत काम करते हैं। हम इस बारे में बात करना चाहेंगे।

Git क्या है

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

गिट एक सरलीकृत फ़ाइल प्रणाली है, जिसके शीर्ष पर संस्करण नियंत्रण के साथ काम करने के लिए संचालन का एक सेट है।

Git आपको फ़ाइलों को एक विशिष्ट प्रारूप में सहेजने की अनुमति देता है। हर बार जब आप कोई फ़ाइल लिखते हैं, तो Git आपकी वस्तु - हैश की कुंजी देता है।

डेनियल पोपोव : कई लोगों ने देखा कि रिपॉजिटरी में एक जादू छिपी हुई निर्देशिका है। इसकी आवश्यकता क्यों है? क्या मैं इसे हटा या नाम बदल सकता हूं?

ईगोर एंड्रीविच : गैट इनिट कमांड के माध्यम से एक रिपॉजिटरी बनाना संभव है। यह .it निर्देशिका बनाता है जो Git फ़ाइलों को नियंत्रित करने के लिए उपयोग करता है। .Git आपके प्रोजेक्ट में जो कुछ भी करता है, उसे केवल एक संपीड़ित प्रारूप में संग्रहीत करता है। इसलिए, आप इस निर्देशिका से रिपॉजिटरी को पुनर्स्थापित कर सकते हैं।

अलेक्सई कुद्र्यावत्सेव : यह पता चला है कि आपका प्रोजेक्ट फ़ोल्डर विस्तारित गिट फ़ोल्डर के संस्करणों में से एक है?

Egor Andreevich : आप किस शाखा पर हैं, इसके आधार पर, git एक ऐसी परियोजना को पुनर्स्थापित करता है, जिसके साथ आप काम कर सकते हैं।

अलेक्सई कुद्र्यावत्सेव : फ़ोल्डर के अंदर क्या है?

Egor Andreevich : Git विशिष्ट फ़ोल्डर और फ़ाइलें बनाता है। सबसे महत्वपूर्ण फ़ोल्डर .it / ऑब्जेक्ट्स है, जहाँ सभी ऑब्जेक्ट संग्रहीत हैं। सबसे सरल वस्तु बूँद है, अनिवार्य रूप से एक फ़ाइल के समान है, लेकिन एक प्रारूप में जो समझ में आता है। जब आप किसी पाठ फ़ाइल को रिपॉजिटरी में सहेजना चाहते हैं, तो Git इसे संपीड़ित करता है, इसे संग्रहीत करता है, डेटा जोड़ता है और एक बूँद बनाता है।

निर्देशिकाएं हैं - ये सबफ़ोल्डर के साथ फ़ोल्डर हैं, अर्थात। Git में एक ट्री ऑब्जेक्ट प्रकार होता है जिसमें अन्य पेड़ों के लिए बूँद के संदर्भ होते हैं।

मूल रूप से, एक पेड़ एक स्नैपशॉट है जो एक निश्चित बिंदु पर आपकी निर्देशिका की स्थिति का वर्णन करता है।

एक कमिट बनाते समय, वर्किंग डायरेक्टरी का एक लिंक तय होता है - ट्री।

एक कमेटी एक पेड़ से जुड़ी एक जानकारी है, जिसने इसे बनाया है: ईमेल, नाम, निर्माण का समय, माता-पिता (माता-पिता की शाखा) से लिंक और संदेश। Git भी कंप्रेस करता है और ऑब्जेक्ट डायरेक्टरी को लिखता है।

यह देखने के लिए कि यह सब कैसे काम करता है, आपको कमांड लाइन से उपनिर्देशिकाओं को सूचीबद्ध करने की आवश्यकता है।

गिट के साथ काम करने के लाभ

डेनियल पोपोव : Git कैसे काम करता है? एक्शन एल्गोरिदम इतना जटिल क्यों है?

Egor Andreevich : यदि आप Git की तुलना Subversion (SVN) से करते हैं, तो पहली प्रणाली में कई कार्य हैं जिन्हें आपको समझने की आवश्यकता है। मैं मंचन क्षेत्र के साथ शुरू करूँगा, जिसे गिट की सीमा नहीं माना जाना चाहिए, बल्कि विशेषताएं भी होनी चाहिए।

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

अलेक्सेई कुद्र्यावत्सेव : अन्य संस्करण नियंत्रण प्रणालियों से कैसे अलग है?

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

एसवीएन की एक केंद्रीय भंडार और स्थानीय प्रतियां हैं। इसका मतलब है कि कोई भी डेवलपर अकेले केंद्रीय भंडार को तोड़ सकता है।

गिट में, यह नहीं होगा। यदि केंद्रीय सर्वर रिपॉजिटरी डेटा खो देता है, तो इसे किसी भी स्थानीय कॉपी से पुनर्स्थापित किया जा सकता है। गिट को अलग तरीके से डिज़ाइन किया गया है, और यह गति के लाभ प्रदान करता है।

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

ईगोर एंड्रीविच : एसवीएन में, एक शाखा पिछली शाखा की एक पूरी प्रति है। Git में कोई शाखा भौतिक प्रतिनिधित्व नहीं है। यह एक विशेष विकास लाइन में अंतिम प्रतिबद्ध के लिए एक कड़ी है। जब Git ऑब्जेक्ट्स को बचाता है, तो एक कमिट बनाते समय, यह कमिट के बारे में विशिष्ट जानकारी के साथ एक फाइल बनाता है। Git एक प्रतीकात्मक फ़ाइल बनाता है - किसी अन्य फ़ाइल के लिंक के साथ सिमिलिंक। जब आपके पास कई शाखाएं होती हैं, तो आप रिपॉजिटरी में अलग-अलग कमिट्स का उल्लेख करते हैं। एक शाखा के इतिहास को ट्रैक करने के लिए, आपको माता-पिता की ओर वापस लिंक का उपयोग करके प्रत्येक प्रतिबद्ध से जाने की आवश्यकता है।

मरजिम शाखाएँ

डेनियल पोपोव : दो शाखाओं को एक में मर्ज करने के दो तरीके हैं - यह मर्ज और रीबेस है। आप उनका उपयोग कैसे करते हैं?

ईगोर एंड्रीविच : प्रत्येक विधि के अपने फायदे और नुकसान हैं। मर्ज सबसे आसान विकल्प है। उदाहरण के लिए, दो शाखाएं हैं: मास्टर और उसमें से चयनित सुविधा।

मर्ज के लिए, आप तेजी से आगे का उपयोग कर सकते हैं। यह तब संभव है जब फीचर शाखा में काम शुरू किया गया था, मास्टर में कोई नया काम नहीं किया गया था। यानी, फीचर में पहला कमिट मास्टर में आखिरी कमिटमेंट है।

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

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

मर्ज कमिटमेंट के बाद, आप कहानी को देख सकते हैं और देख सकते हैं कि यह द्विभाजित है। यदि आप एक उपकरण का उपयोग करते हैं जो रेखांकन प्रदान करता है, तो नेत्रहीन यह एक क्रिसमस ट्री की तरह दिखाई देगा। यह गिट को नहीं तोड़ता है, लेकिन एक डेवलपर के लिए ऐसी कहानी देखना मुश्किल है।

एक अन्य उपकरण रिबास है । वैचारिक रूप से, आप फीचर शाखा से सभी परिवर्तन लेते हैं और उन्हें मास्टर शाखा पर फ्लिप करते हैं। पहली विशेषता कमेटी नवीनतम मास्टर कमेट के शीर्ष पर नई कमिट बन जाती है।

एक पकड़ है - Git परिवर्तन नहीं कर सकता है। इसमें एक कमिटमेंट था और हम इसे केवल मास्टर के ऊपर नहीं लपेट सकते, क्योंकि प्रत्येक कमिट में टाइम स्टैम्प होता है।

रिबास के मामले में, गिट फीचर में सभी कमिट्स को पढ़ता है, अस्थायी रूप से इसे बचाता है, और फिर मास्टर में उसी क्रम में इसे फिर से बनाता है। रिबास के बाद, प्रारंभिक कमिट गायब हो जाते हैं, और मास्टर के शीर्ष पर एक ही सामग्री के साथ नए कमिट दिखाई देते हैं। समस्याएं हैं। जब आप उस शाखा को रिबेट करने का प्रयास करते हैं, जिसके साथ अन्य लोग काम करते हैं, तो आप भंडार को तोड़ सकते हैं। उदाहरण के लिए, यदि किसी ने अपनी शाखा की शुरुआत एक ऐसी प्रतिबद्धता से की है, जो कि फीचर में थी, और आपने उस कमिट को नष्ट और पुनः बनाया। स्थानीय शाखाओं के लिए रिबेस अधिक उपयुक्त है।

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

ईगोर एंड्रीविच : हम इस शब्द के प्रत्यक्ष अर्थ में सुविधा शाखाओं का उपयोग नहीं करते हैं। हर बार जब हम एक बदलाव करते हैं, एक नई शाखा बनाते हैं, उसमें काम करते हैं और तुरंत मास्टर में डालते हैं। लंबे समय तक चलने वाली शाखाएं नहीं हैं।

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

डेनियल पोपोव : आप एक मास्टर आइडल फीचर को मर्ज करने से डरते नहीं हैं, क्योंकि किसी कार्य को प्रति घंटे के अंतराल में विघटित करना अक्सर अवास्तविक होता है?

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

डेनियल पोपोव : अक्सर, नए लोगों को गिट को बताया जाता है कि रिबेस के बाद आपको बल के साथ धक्का देने की आवश्यकता होती है। कहाँ से है?

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

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

डेनियल पोपोव : अभी भी इंटरैक्टिव रिबेस की अवधारणा है, और कई लोग इससे डरते हैं।

ईगोर एंड्रीविच : भयानक कुछ भी नहीं है। इस तथ्य के कारण कि रीट के दौरान गिट ने कहानी को फिर से बनाया है, इसे फेंकने से पहले अस्थायी रूप से संग्रहीत करता है। जब इसका अस्थायी भंडारण होता है, तो यह कमिट के साथ कुछ भी कर सकता है।

इंटरएक्टिव मोड में रीबेस मान लेता है कि रिबेट से पहले गिट एक टेक्स्ट एडिटर की एक खिड़की को बाहर फेंक देता है जिसमें आप निर्दिष्ट कर सकते हैं कि प्रत्येक व्यक्ति के साथ क्या किया जाना चाहिए। यह पाठ की कई पंक्तियों की तरह दिखता है, जहां प्रत्येक पंक्ति शाखा में आने वाले कमिट्स में से एक है। प्रत्येक प्रतिबद्ध से पहले, उस ऑपरेशन का एक संकेत है जो प्रदर्शन करने के लायक है। सबसे सरल डिफ़ॉल्ट ऑपरेशन पिक है , अर्थात रिबास में लेने और शामिल करने के लिए। सबसे आम स्क्वैश है , फिर गिट इस बदलाव से बदलाव करेंगे और इसे पिछले एक से बदलाव के साथ विलय कर देंगे।

अक्सर ऐसा ही नजारा होता है। आपने स्थानीय रूप से अपनी शाखा में काम किया और बचत के लिए कमिट बनाए। परिणाम कमिट्स का एक लंबा इतिहास है, जो आपके लिए दिलचस्प है, लेकिन उसी तरह इसे मुख्य इतिहास में नहीं डाला जाना चाहिए। फिर आप सामान्य प्रतिबद्ध के लिए नाम बदलने के लिए स्क्वैश देते हैं।

टीमों की सूची लंबी है। आप कमिट को फेंक सकते हैं - ड्रॉप कर सकते हैं और यह गायब हो जाता है, आप कमिट मैसेज आदि को बदल सकते हैं।

अलेक्सेई कुद्रेवत्सेव : जब आपके पास इंटरैक्टिव रिबेस में संघर्ष होता है, तो आप नरक के सभी हलकों से गुजरते हैं।

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

व्यावहारिक गिट आवेदन

डेनियल पोपोव : चलो अभ्यास करने के लिए आगे बढ़ते हैं। साक्षात्कार में, मैं अक्सर पूछता हूं: "आपके पास एक हजार कमिट हैं। पहले पर सब ठीक है, हजारवां परीक्षण टूट गया। गीता की मदद से जो बदलाव आया, वह कैसे मिल सकता है? ”

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

चलो दिलचस्प एक के साथ शुरू करते हैं। गिट बिसेक्ट एक ऐसी स्थिति पर लागू होता है जहां आपको प्रतिगमन होता है - यह कार्यात्मक था, यह काम करता था, लेकिन यह अचानक बंद हो गया। यह पता लगाने के लिए कि कार्यक्षमता कब टूट गई है, आप सैद्धांतिक रूप से यादृच्छिक रूप से एप्लिकेशन के पिछले संस्करण में वापस आ सकते हैं, कोड को देख सकते हैं, लेकिन एक उपकरण है जो आपको समस्या को संरचित दृष्टिकोण की अनुमति देगा।

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

आपने सत्र शुरू किया, अंतराल अंतराल में से एक में स्विच करता है, यह रिपोर्ट करता है। एक हजार के मामले में, कई पुनरावृत्तियों नहीं होंगे।

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

दोष एक सरल उपकरण है जो इसके नाम के आधार पर आपको एक कार्यात्मक विफलता के "अपराधी" को खोजने की अनुमति देता है। इस नकारात्मक परिभाषा के कारण, दोष समुदाय में कई इसे पसंद नहीं करते हैं।

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

डेनियल पोपोव : वैसे, एंड्रॉइड स्टूडियो में इसे एनोटेट कहा जाता था। दोष के नकारात्मक अर्थ को हटा दिया गया है।

अलेक्सई कुद्र्यावत्सेव : बिल्कुल, एक्सकोड में उन्होंने इसका नाम बदलकर लेखक कर दिया।

ईगोर एंड्रीविच : मैंने यह भी पढ़ा कि इस उत्कृष्ट कोड को लिखने वाले को खोजने के लिए एक उपयोगिता की प्रशंसा है।

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

एगोर एंड्रीविच : हां, मैं बहुत कम ही बिज़ेक्ट का सहारा लेता हूं, लेकिन मैं नियमित रूप से एनोटेट का उपयोग करता हूं। हालाँकि कभी-कभी यह समझना असंभव है कि इसे कोड लाइन से क्यों चेक किया गया है, यह लेखक की क्या इच्छा है, यह पूरी तरह से स्पष्ट है।

स्टैक्ड पीआर के साथ कैसे काम करें?

डेनियल पोपोव : मैंने सुना है कि स्क्वायर स्टैक्ड पुल अनुरोधों (पीआरएस) का उपयोग करता है।

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

यहीं से समस्या पैदा होती है। आप एक ऐसी सुविधा पर काम कर रहे हैं जिसमें कोड आधार में बड़ी संख्या में बदलाव की आवश्यकता होगी। आप क्या कर सकते हैं? आप इसे एक पुल अनुरोध में डाल सकते हैं, लेकिन फिर यह बहुत बड़ा होगा। आप धीरे-धीरे एक पुल अनुरोध बनाकर काम कर सकते हैं, लेकिन फिर समस्या यह होगी कि आपने एक शाखा बनाई, कुछ बदलाव जोड़े और एक पुल अनुरोध सबमिट किया, जो मास्टर में वापस आ गया और जो कोड आपके पास अनुरोध का था वह मास्टर में उपलब्ध नहीं है। मर्ज नहीं होगा। यदि आप इन फ़ाइलों में परिवर्तन पर निर्भर हैं, तो काम करना जारी रखना मुश्किल है क्योंकि ऐसा कोई कोड नहीं है।

हम इसके आसपास कैसे पहुंचते हैं? हमने पहला पुल अनुरोध बनाने के बाद, हम काम करना जारी रखते हैं, मौजूदा शाखा से एक नई शाखा बनाते हैं, जिसका उपयोग हमने पुल अनुरोध से पहले किया था। प्रत्येक शाखा गुरु से नहीं, बल्कि पिछली शाखा से आती है। जब हम कार्यक्षमता के इस टुकड़े पर काम खत्म करते हैं, तो हम एक और पुल अनुरोध सबमिट करते हैं और फिर से संकेत देते हैं कि विलय के साथ यह मास्टर में विलय नहीं करता है, लेकिन पिछली शाखा में। यह पुल अनुरोधों की ऐसी श्रृंखला को चालू करता है - स्टैक्ड पीआरएस। जब कोई व्यक्ति संशोधित करता है, तो वह उन परिवर्तनों को देखता है जो केवल इस सुविधा द्वारा किए गए थे, लेकिन पिछले वाले नहीं।

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

डेनियल पोपोव : मैं सही ढंग से समझता हूं कि अंत में कुछ अंतिम पुल अनुरोध होंगे जिसमें सभी छोटे पुल अनुरोध शामिल होंगे। आप इस धागे को बिना देखे डालें?

ईगोर एंड्रीविच : मर्ज स्टैक किए गए स्रोत से आता है: पहला, बहुत पहले पुल अनुरोध मास्टर में विलय हो जाता है, अगले में, शाखा से मास्टर में आधार परिवर्तन होता है और, तदनुसार, गिट गणना करता है कि मास्टर में पहले से ही कुछ बदलाव हैं, कम स्नैपशॉट।

अलेक्सेई कुद्रेवत्सेव : क्या आपके पास रेसिंग की स्थिति है जब पहली शाखा पहले से ही जमी हुई है, और उसके बाद ही दूसरे को पहले में रोक दिया है क्योंकि यह मास्टर करने के लिए लक्ष्य नहीं बदला है?

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

अलेक्सेई कुद्र्यावत्सेव : लेकिन सीआई के बारे में क्या जाँच हुई कि कुछ भी नहीं टूटा है?

एगोर एंड्रीविच : हम ऐसा नहीं करते हैं। CI शाखा पर चलता है, जो पुल अनुरोध के लिए आधार है, और जाँच के बाद, हम आधार बदलते हैं। तकनीकी रूप से, यह नहीं बदलता है, क्योंकि आप भी परिवर्तनों की संख्या को लक्षित करते हैं।

डेनियल पोपोव : क्या आप सीधे मास्टर में धक्का देते हैं या आप विकसित होते हैं? और जब आप जारी करते हैं तो स्पष्ट रूप से यह संकेत मिलता है कि किस से संग्रह करना है?

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

अलेक्सेई कुद्रेवत्सेव : जहां गिट को पढ़ाने के लिए, क्या पढ़ना है?

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

हम आगामी सेंट एप्सकॉन्फ़ में Git के बारे में बात नहीं करने जा रहे हैं। लेकिन दूसरी ओर, हमने एक प्रयोग पर फैसला किया और घटनात्मक सम्मेलन कार्यक्रम में परिचयात्मक रिपोर्टों को जोड़ा, जिसमें संबंधित विकास उद्योगों के वक्ताओं ने एक मोबाइल डेवलपर के क्षितिज का विस्तार करने के लिए ज्ञान साझा किया। हम आपको सलाह देते हैं कि डेटाबेस के बारे में Avito से निकोलाई गोलोव की प्रस्तुति पर ध्यान दें : कैसे गलती न करें और सही डेटाबेस चुनें, विकास के लिए कैसे तैयार करें और 2019 में क्या प्रासंगिक है।

एप्कास्ट प्रत्येक दो सप्ताह में बुधवार को जारी करता है, और यदि आप पाठ संस्करण के लिए ऑडियो संस्करण पसंद करते हैं, तो साउंडक्लाउड में हमारी सदस्यता लें, जैसे हमारी चैट में विषयों पर चर्चा करें।