क्या फ़ीचर शाखाएँ जाने का अंतिम तरीका हैं?

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

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

इस बीच, मुख्य शाखा लगातार तैनात रहती है और उन मुद्दों से सुरक्षित रहती है।

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

साथ ही, जब कई विरोध हों, तो मर्ज का परिणाम अप्रत्याशित हो सकता है।

हालांकि, यह एकमात्र संभव रणनीति नहीं है, और यह लेख ऊपर सूचीबद्ध नुकसानों के बिना नई उत्पाद सुविधाओं को प्रबंधित करने के वैकल्पिक तरीके को कवर करेगा।

मर्ज विरोध क्यों होते हैं?

गिट डिजाइन के अनुसार, विलय के दौरान विलय विवाद तब होता है जब शाखाओं में एक ही फाइल लाइन में अलग-अलग सामग्री होती है।

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

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

अब सवाल यह है कि अपने परिवर्तनों को main शाखा में विलय करने वाला पहला कौन होगा और यह दिखावा करेगा कि समस्या उनके पक्ष में नहीं है जबकि दूसरी टीम परिणामी संघर्ष को हल करने की कोशिश करती है?

ट्रंक-आधारित विकास

कुल मिलाकर, विलय विवादों से बचना असंभव है, लेकिन हम निश्चित रूप से निम्नलिखित प्रसिद्ध नियम का उपयोग करके उन्हें हल करना आसान बना सकते हैं:

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

इसे ट्रंक-आधारित विकास कहा जाता है और इसका अर्थ है परिवर्तनों को सीधे main शाखा में धकेलना और अनावश्यक होने पर शाखाओं का उपयोग करने से बचना।

ऊपर दिए गए उदाहरण में, यदि दोनों टीमें नियमित रूप से अपने परिवर्तनों को main शाखा में धकेलती हैं, तो वे तुरंत नोटिस करेंगे कि वे उसी फ़ाइल को संशोधित करने का प्रयास कर रहे हैं।

इससे भी अधिक, वे मुद्दों को पूरी तरह टाल सकते थे। उन अद्यतनों पर विचार करते हुए पहली टीम ने पहले ही फ़ाइल को संशोधित कर लिया था, उसके बाद दूसरी टीम ने अपने बदलाव करना शुरू कर दिया होगा।

एक चौकस पाठक आश्चर्यचकित हो सकता है: सब कुछ बहुत अच्छा लगता है, लेकिन हम परीक्षण कैसे करें? प्रति फीचर शाखाएं रिलीज से पहले अलगाव में पूरी नई कार्यक्षमता का परीक्षण करने की अनुमति देती हैं; यदि हम परिवर्तनों को लगातार main शाखा में एकीकृत करते हैं, तो उसके लिए कोई अवसर नहीं होगा।

पेश है फीचर फ्लैग्स

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

फ़ीचर फ़्लैग के कई अतिरिक्त लाभ हैं:

• जोखिम मुक्त तैनाती

• सीधे उत्पादन में अधिक विश्वसनीय परीक्षण

• आवश्यकता पड़ने पर परिवर्तनों को तुरंत रोल बैक करें।

फ़ीचर फ़्लैग का उपयोग करने से main शाखा में परिवर्तन को सुरक्षित किया जा सकता है। जबकि फीचर फ़्लैग बंद है, परिवर्तन किसी को भी प्रभावित नहीं करते हैं।

यह तकनीक सीधे main शाखा के साथ काम करने या अल्पकालिक शाखाएँ बनाने की अनुमति देती है। तो, विलय विवाद बहुत दुर्लभ हो जाते हैं और जल्दी से हल हो जाते हैं।

निष्कर्ष

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

हालांकि, हमेशा की तरह, कोई एक आकार-फिट-सभी नहीं है। यह कम संख्या में टीमों के लिए काम करता है जो एक ही रिपॉजिटरी में काम कर रहे हैं - इस संख्या को बढ़ाने के लिए आमतौर पर कुछ समायोजन की आवश्यकता होती है।

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