विलय के बजाय पुल अनुरोधों का उपयोग क्यों करें

Question

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

Comments

पुल अनुरोधों से परियोजना प्रबंधक को यह तय करने की अनुमति मिलती है कि वे चाहते हैं कि शाखा का मास्टर में विलय हो या नहीं।

— रॉबर्ट हार्वे

व्यवहार में, यदि सभी डेवलपर्स के पास मास्टर तक पहुंच है, तो क्या इससे कोई फर्क पड़ता है?

— हंस

@Goose कोड की समीक्षा?

— नानी

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

— रॉबर्ट हार्वे

क्योंकि यह डीवीसी का तरीका है कि आप एक साधारण कदम में कभी भी 3 या 4 जटिल तरीकों से नहीं कर सकते

— मेसन व्हीलर

Answer 1

चेक और शेष राशि के लिए पुल अनुरोध प्रदान करते हैं, भले ही कोई भी मास्टर को धक्का दे सकता है।

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

यदि पुल खींचने वाला व्यक्ति सिस्टम की वास्तुकला से परिचित है, तो वे यह सुनिश्चित कर सकते हैं कि परिवर्तन सिस्टम के वास्तुशिल्प दृष्टि से फिट हैं, खासकर यदि पूरी टीम में दीर्घकालिक दृष्टि नहीं हो सकती है।

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

Answer 2

दोनों शाखाओं में बँटवारे और कांटे + खींचने के अनुरोध के बाद मुझे लगता है कि पुल अनुरोधों का थोड़ा फायदा मिलता है जब आप सभी एक ही टीम या कंपनी में विकास कर रहे होते हैं

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

कहा गया है कि आप एक ही रेपो पर शाखाओं के बीच अनुरोध कर सकते हैं। आपके पास कांटा नहीं है, या अलग-अलग अनुमतियां हैं।

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

Answer 3

कॉनवे के नियम नामक एक अवलोकन है जिसमें कहा गया है:

वे संगठन जो सिस्टम डिज़ाइन करते हैं ... डिज़ाइन का निर्माण करने के लिए विवश हैं जो इन संगठनों के संचार संरचनाओं की प्रतियां हैं।

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

इसी तरह, कॉनवे के नियम से पता चलता है कि यदि आप स्वायत्त जिम्मेदारी के स्वच्छ रूप से अलग किए गए क्षेत्रों और अच्छी तरह से परिभाषित इंटरफेस के साथ एक माइक्रो-आर्किटेक्चर करना चाहते हैं, तो आपके संगठन के संचार चैनलों को उस वास्तुकला को प्रतिबिंबित करना चाहिए जिसे आप प्राप्त करना चाहते हैं। इसका मतलब है कि 5-10 लोगों की छोटी टीमों को किसी भी दिए गए माइक्रो सर्विस के लिए सीधी प्रतिबद्ध पहुंच होनी चाहिए, और उस टीम के बाहर किसी को भी पुल अनुरोध के माध्यम से जाना चाहिए। यह सुनिश्चित करता है कि लोगों को एक microservice के साथ सबसे परिचित परिचित हैं जो इसके बारे में समीक्षा और सलाह दे रहे हैं।

जब आपके पास हर जगह सीधी पहुंच रखने वाले सभी के साथ एक बड़ा संगठन होता है, तो कम से कम प्रतिरोध के आपके संचार चैनल आपको मिट्टी की वास्तुकला की एक बड़ी गेंद का उत्पादन करने के लिए स्थापित कर रहे हैं।

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

Answer 4

कार्ल बेजेलफेल्ट बिल्कुल सही है। मैं जोड़ूंगा: यह गुणवत्ता के बारे में है।

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

यह वास्तव में प्रयास के लायक है।

Comments

आपकी टिप्पणी के लिये धन्यवाद। मुझे यकीन नहीं है कि प्रश्न के उत्तर के रूप में इसे क्यों लागू किया जाए।

— हंस

यह पूर्व-विलय सीआई का उल्लेख करने वाला एकमात्र उत्तर है।

— बसिलेव्स

Answer 5

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