स्टैक्ड पीआर के साथ कोड समीक्षा पर पुनर्विचार यह पोस्ट शिफ्ट-लेफ्ट सिद्धांतों की पड़ताल करती है और सुझाव देती है कि स्टैक्ड पीआर तेजी से उपयोगी हो जाएंगे। पीयर कोड समीक्षा प्रक्रिया सॉफ्टवेयर विकास का एक अनिवार्य हिस्सा है। यह सॉफ्टवेयर की गुणवत्ता बनाए रखने में मदद करता है और मानकों, परियोजना आवश्यकताओं, शैली दिशानिर्देशों के पालन को बढ़ावा देता है और सीखने और ज्ञान हस्तांतरण की सुविधा प्रदान करता है। कोड समीक्षा प्रभावशीलता जबकि पर्याप्त रूप से छोटे कोड परिवर्तनों की समीक्षा के लिए प्रभावशीलता अधिक है, परिवर्तन के आकार में वृद्धि के साथ यह तेजी से गिरती है। प्रभावी होने के लिए मानसिक फोकस के आवश्यक स्तर को बनाए रखने के लिए, बड़ी कोड समीक्षाएँ थका देने वाली होती हैं। आमतौर पर, समीक्षा की अवधि जितनी लंबी होती जाती है, समग्र समीक्षा उतनी ही कम प्रभावी होती जाती है: तो हम पुल अनुरोधों (पीआर) के आकार को सीमित क्यों नहीं कर सकते? जबकि कई परिवर्तन छोटे से शुरू हो सकते हैं, अचानक दो-पंक्ति का एक छोटा सा परिवर्तन 500-पंक्ति रिफैक्टर में विकसित हो सकता है जिसमें समीक्षकों के साथ कई आगे-पीछे की बातचीत शामिल है। कुछ इंजीनियरिंग टीमें लंबे समय तक चलने वाली फीचर शाखाएं भी बनाए रखती हैं क्योंकि वे काम करना जारी रखती हैं, जिससे समीक्षा करना कठिन हो जाता है। तो, हम सही संतुलन कैसे बनायें? सरल। स्टैक्ड पीआर का प्रयोग करें. स्टैक्ड पीआर क्या हैं? स्टैक्ड पुल अनुरोध छोटे, पुनरावृत्तीय परिवर्तन करते हैं और एक ही पुल अनुरोध में बड़े मोनोलिथ परिवर्तनों को बंडल करने के बजाय एक दूसरे के ऊपर स्टैक्ड होते हैं। स्टैक में प्रत्येक पीआर केवल एक तार्किक परिवर्तन पर ध्यान केंद्रित करता है, जिससे समीक्षा प्रक्रिया अधिक प्रबंधनीय और कम समय लेने वाली हो जाती है। हमने पिछले साल एक पोस्ट भी लिखी थी जिसमें बताया गया था कि कैसे यह मदद फाइलों या सुविधाओं के आधार पर चीजों को तोड़ने के बजाय प्रतिनिधित्व करती है। एक कथा के रूप में कोड परिवर्तनों का स्टैक्ड पीआर क्यों? अधिक प्रभावी कोड समीक्षाओं की संस्कृति के निर्माण के अलावा, स्टैक्ड पीआर के कुछ अन्य लाभ भी हैं: प्रारंभिक कोड समीक्षा प्रतिक्रिया कल्पना कीजिए कि आप एक बड़ी सुविधा लागू कर रहे हैं। संपूर्ण सुविधा बनाने और फिर कोड समीक्षा का अनुरोध करने के बजाय, प्रारंभिक रूपरेखा तैयार करने और उसे प्रतिक्रिया के लिए तुरंत प्रस्तुत करने पर विचार करें। यह संभवतः आपके डिज़ाइन पर शीघ्र प्रतिक्रिया प्राप्त करके आपके अनगिनत घंटे बचा सकता है। तेज़ सीआई फीडबैक चक्र स्टैक्ड पीआर अभ्यास का समर्थन करते हैं क्योंकि परिवर्तनों को लगातार एकीकृत और परीक्षण किया जाता है, जो समस्याओं का शीघ्र पता लगाने और सुधार की अनुमति देता है। शिफ्ट-लेफ्ट परिवर्तनों को टुकड़ों और टुकड़ों में मिला दिया जाता है, किसी भी मुद्दे को जल्दी पकड़ लिया जाता है बनाम एक विशाल परिवर्तन को इस उम्मीद में विलय कर दिया जाता है कि इससे उत्पाद में कमी नहीं आएगी! ज्ञान बांटना कोड समीक्षाएँ भावी पीढ़ी के लिए भी अद्भुत हैं। आपके कोड परिवर्तन किसी सुविधा को लागू करने के पीछे आपकी विचार प्रक्रिया को बता रहे हैं, इसलिए, परिवर्तनों का टूटना अधिक प्रभावी ज्ञान हस्तांतरण बनाता है। टीम के सदस्यों के लिए परिवर्तनों को समझना आसान है, जो भविष्य के लिए बेहतर ज्ञान साझा करने को बढ़ावा देता है। अनब्लॉक रहना कोड की समीक्षा और अनुमोदन की प्रतीक्षा करना एक निराशाजनक प्रक्रिया हो सकती है। स्टैक्ड पीआर के साथ, डेवलपर्स पिछले पीआर को मंजूरी देने के लिए समीक्षकों की प्रतीक्षा किए बिना एक फीचर के कई हिस्सों पर काम कर सकते हैं क्या चालबाजी है? तो, अधिक डेवलपर कोड समीक्षा के लिए स्टैक्ड पीआर का उपयोग क्यों नहीं करते? हालाँकि यह स्टैक्ड पीआर वर्कफ़्लो कोड समीक्षाओं को प्रबंधनीय और डेवलपर्स को उत्पादक बनाए रखने की दोनों वांछित प्रथाओं को संबोधित करता है, दुर्भाग्य से, यह Git या GitHub द्वारा मूल रूप से बहुत अच्छी तरह से समर्थित नहीं है। परिणामस्वरूप, इंजीनियरों को इस स्टैकिंग तकनीक को मौजूदा Git और GitHub प्लेटफार्मों में शामिल करने में सक्षम बनाने के लिए ओपन-सोर्स समुदाय में विकसित किए गए हैं। लेकिन पीआर को ढेर करना कहानी का केवल एक हिस्सा है। कई उपकरण अद्यतन करने जैसे ही हमें कोड समीक्षा फीडबैक मिलता है और हम स्टैक के हिस्से में बदलाव करते हैं, हमें अब सभी बाद की शाखाओं में विवादों को फिर से आधार बनाना और हल करना होगा। चलिए एक उदाहरण लेते हैं. कल्पना करें कि आप एक ऐसे बदलाव पर काम कर रहे हैं जिसके लिए स्कीमा परिवर्तन, बैकएंड परिवर्तन और फ्रंटएंड परिवर्तन की आवश्यकता है। इसके साथ, अब आप पहले समीक्षा के लिए एक सरल स्कीमा परिवर्तन भेज सकते हैं, और जब इसकी समीक्षा की जा रही हो, तो आप बैकएंड और फ्रंटएंड पर काम करना शुरू कर सकते हैं। स्टैक्ड पीआर का उपयोग करके, इन सभी 3 परिवर्तनों की 3 अलग-अलग समीक्षाओं द्वारा समीक्षा की जा सकती है। इस मामले में, आपके पास एक स्टैक हो सकता है जो इस तरह दिखता है जहां , और एक दूसरे के ऊपर खड़ी 3 शाखाओं का प्रतिनिधित्व करते हैं। demo/schema demo/backend demo/frontend अब तक, यह समझ में आता है, लेकिन क्या होगा यदि आपको स्कीमा परिवर्तन पर कुछ कोड समीक्षा टिप्पणियाँ मिलती हैं जिसके लिए एक नई प्रतिबद्धता बनाने की आवश्यकता होती है? अचानक आपका प्रतिबद्ध इतिहास इस तरह दिखता है: अब, आपको बाद की सभी शाखाओं को मैन्युअल रूप से रीबेस करना होगा और हर चरण में विवादों को हल करना होगा। कल्पना करें कि यदि आपके पास 10 खड़ी शाखाएँ हैं जहाँ आपको 10 बार संघर्षों को हल करना पड़ सकता है। विलय लेकिन इतना ही नहीं, पीआर को स्टैक में मर्ज करना एक वास्तविक दुःस्वप्न हो सकता है। पीआर को मर्ज करने के लिए आपके पास 3 विकल्प , और हैं। आइए यह समझने का प्रयास करें कि प्रत्येक में पर्दे के पीछे क्या होता है। squash merge rebase कमिट के मामले में, Git पीआर के सभी मौजूदा कमिटों से परिवर्तन लेता है और उन्हें एक ही कमिट में फिर से लिखता है। इस मामले में, वे परिवर्तन कहां से आए इसका कोई इतिहास नहीं रखा गया है। squash कमिट एक विशेष प्रकार की Git कमिट है जिसे दो या दो से अधिक कमिट के संयोजन द्वारा दर्शाया जाता है। तो, यह कमिट के समान ही काम करता है लेकिन यह अपने माता-पिता के बारे में जानकारी भी प्राप्त करता है। एक सामान्य परिदृश्य में, एक मर्ज कमिट के दो माता-पिता होते हैं: बेस ब्रांच पर अंतिम कमिट (जहां पीआर मर्ज किया गया है), और फीचर ब्रांच पर शीर्ष कमिट जिसे मर्ज किया गया था। merge squash यद्यपि यह दृष्टिकोण प्रतिबद्ध इतिहास को अधिक संदर्भ देता है, यह अनजाने में एक बनाता है जो अवांछनीय हो सकता है। गैर-रेखीय गिट-इतिहास अंत में, और मर्ज के मामले में, Git बेस ब्रांच पर कमिट्स को फिर से लिखेगा। तो, कमिट विकल्प के समान, यह मूल कमिट से जुड़े किसी भी इतिहास को खो देगा। rebase squash आमतौर पर, यदि आप पीआर को स्टैक करते समय कमिट रणनीति का उपयोग कर रहे हैं, तो आपका जीवन थोड़ा आसान होगा, लेकिन अधिकांश टीमें गिट-इतिहास को साफ रखने के लिए उस रणनीति का उपयोग करने से हतोत्साहित करती हैं। इसका मतलब है कि आप संभवतः या मर्ज का उपयोग कर रहे हैं। merge squash rebase और यह बाद की सभी असंबद्ध स्टैक्ड शाखाओं के लिए एक मर्ज संघर्ष पैदा करता है। उपरोक्त उदाहरण में, मान लें कि हम पहली शाखा मेनलाइन में मर्ज कर देते हैं। यह एक नया कमिट बनाएगा जिसमें और के परिवर्तन शामिल होंगे। demo/schema D1 A1 A2 चूँकि Git को नहीं पता कि कहाँ से आया है, और अभी भी पर आधारित है, इसलिए मेनलाइन के शीर्ष पर रीबेस करने का प्रयास मर्ज टकराव पैदा करेगा। D1 demo/backend A2 demo/backend इसी तरह, दोबारा बेस करने के बाद दोबारा बेस करने से भी वही समस्याएं पैदा होंगी। इसलिए यदि आपके पास दस खड़ी शाखाएँ हैं और आप स्क्वैश ने उनमें से एक को मिला दिया है, तो आपको इन संघर्षों को नौ बार हल करना होगा। demo/frontend demo/backend हम अभी भी केवल सतह को खरोंच रहे हैं; हैं जैसे कि कमिट को पुन: व्यवस्थित करना, विभाजित करना, मोड़ना और शाखाओं का नाम बदलना, जो स्टैक्ड पीआर से निपटने के दौरान प्रबंधन के लिए भारी ओवरहेड बना सकते हैं। कई अन्य उपयोग के मामले इसीलिए हमने एविएटर के हिस्से के रूप में स्टैक्ड पीआरएस प्रबंधन का निर्माण किया। एविएटर सीएलआई अलग क्यों है? एविएटर को एक संवर्द्धन परत के रूप में सोचें जो आपके मौजूदा टूलींग के शीर्ष पर स्थित है। उन्नत डेवलपर अनुभव प्रदान करने के लिए एविएटर GitHub, Slack, Chrome और Git CLI से जुड़ता है। एविएटर सीएलआई बाकी सभी चीजों के साथ सहजता से काम करता है! सीएलआई सिर्फ गिट के शीर्ष पर एक परत नहीं है बल्कि गिटहब में स्टैक के संदर्भ को भी समझता है। आइए एक उदाहरण पर विचार करें. एक ढेर बनाना स्टैक बनाना काफी सरल है। इस मामले को छोड़कर, हम यह सुनिश्चित करने के लिए कि स्टैक को ट्रैक किया गया है, शाखाएं बनाने के लिए सीएलआई का उपयोग करते हैं। उदाहरण के लिए, अपनी स्कीमा शाखा और संबंधित पीआर बनाने के लिए, नीचे दिए गए चरणों का पालन करें। av av stack branch demo/schema # make schema changes git commit -a -m "[demo] schema changes" av pr create चूँकि एविएटर आपके GitHub से भी जुड़ा है, इससे आपके लिए स्टैक की कल्पना करना आसान हो जाता है। या यदि आप इसे टर्मिनल से विज़ुअलाइज़ करना चाहते हैं, तो आप अभी भी सीएलआई कमांड के साथ ऐसा कर सकते हैं: स्टैक को अद्यतन करना स्टैक का उपयोग करना अब आसान हो गया है। आप किसी भी शाखा में नए कमिट जोड़ सकते हैं, और सभी शाखाओं को सिंक्रनाइज़ करने के लिए स्टैक में कहीं से भी चला सकते हैं। एविएटर स्वचालित रूप से आपके लिए सभी शाखाओं को पुनः आधार बनाता है, और यदि कोई वास्तविक मर्ज संघर्ष है, तो आपको बस इसे एक बार हल करना होगा। av stack sync स्टैक का विलय यह वह जगह है जहां एविएटर उपकरण आसानी से किसी भी मौजूदा टूलींग से अलग दिखते हैं। एविएटर में, हमने बड़े पैमाने पर हजारों परिवर्तनों को ऑटो-मर्ज करने का प्रबंधन करने के लिए सबसे उन्नत मर्जक्यू में से एक का निर्माण किया है। एविएटर सीएलआई और स्टैक्ड पीआर के साथ सहज एकीकरण का समर्थन करता है। इसलिए पीआर के आंशिक या पूर्ण स्टैक को मर्ज करने के लिए, आप उन्हें सीएलआई का उपयोग करके या गिटहब: पर एक टिप्पणी पोस्ट करके एविएटर मर्जक्यू को सौंप सकते हैं। av pr queue /aviator stack merge एविएटर स्वचालित रूप से क्रम में सभी कतारबद्ध स्टैक को मान्य करने, अपडेट करने और ऑटो-मर्ज करने का काम संभालता है। अब जब पीआर मर्ज हो जाते हैं, तो आप इस बार सभी पीआर को अपडेट करने और सभी मर्ज किए गए पीआर को साफ करने के लिए चला सकते हैं। av stack sync --trunk शिफ्ट-लेफ्ट ही भविष्य है परिवर्तनों को छोटे भागों में विभाजित करने की आवश्यकता के कारण स्टैक्ड पीआर शुरू में अधिक काम की तरह लग सकते हैं। हालाँकि, कोड समीक्षा दक्षता में वृद्धि, तेज़ फीडबैक लूप और बेहतर सीखने के अवसर निश्चित रूप से इस ओवरहेड से अधिक होंगे। जैसे-जैसे हम शिफ्ट-लेफ्ट सिद्धांतों को अपनाना जारी रखेंगे, स्टैक्ड पीआर तेजी से उपयोगी होते जाएंगे। एविएटर सीएलआई बहुत कम परेशानी के साथ स्टैक्ड पीआर को प्रबंधित करने का एक शानदार तरीका प्रदान करता है। सीएलआई है और पूरी तरह से मुफ़्त है। हम चाहेंगे कि आप इसे आज़माएँ और अपनी प्रतिक्रिया हमारे पर साझा करें। ओपन-सोर्स चर्चा बोर्ड एविएटर में, हम डेवलपर्स को तेज़ और बेहतर निर्माण करने के लिए सशक्त बनाने के लिए पहले सिद्धांतों से डेवलपर उत्पादकता उपकरण बना रहे हैं।
