गिट (गिट फ्लो) के लिए सामान्य वर्कफ़्लो फीचर शाखाओं का उपयोग करता है, जहां प्रत्येक नई सुविधा के लिए एक अलग शाखा बनाई जाती है। डेवलपर्स इन पृथक शाखाओं पर नई कार्यक्षमता लागू करते हैं और फिर अपने परिवर्तनों को वापस   या   शाखा में मर्ज कर देते हैं। main master  उस कार्यप्रवाह के लाभ स्पष्ट हैं: क्यूए वातावरण में एक अलग शाखा को आसानी से तैनात और परीक्षण किया जा सकता है, और यदि महत्वपूर्ण बग का पता लगाया जाता है, तो यह   शाखा में विलय नहीं होगा। मुद्दों को ठीक किया जा सकता है और उसी शाखा में कोड में सुधार किया जा सकता है। main  इस बीच, मुख्य शाखा लगातार तैनात रहती है और उन मुद्दों से सुरक्षित रहती है।  दुर्भाग्य से, इस रणनीति का एक महत्वपूर्ण नकारात्मक पहलू है - मर्ज संघर्ष। लंबे समय तक जीवित शाखाओं के साथ, जो किसी बिंदु पर अपरिहार्य हैं, इन संघर्षों को हल करना बहुत मुश्किल हो सकता है कि शाखा से पूरी तरह से छुटकारा पाना और खरोंच से शुरू करना आसान हो जाता है।  साथ ही, जब कई विरोध हों, तो मर्ज का परिणाम अप्रत्याशित हो सकता है।  हालांकि, यह एकमात्र संभव रणनीति नहीं है, और यह लेख ऊपर सूचीबद्ध नुकसानों के बिना नई उत्पाद सुविधाओं को प्रबंधित करने के वैकल्पिक तरीके को कवर करेगा।  मर्ज विरोध क्यों होते हैं?  गिट डिजाइन के अनुसार, विलय के दौरान विलय विवाद तब होता है जब शाखाओं में एक ही फाइल लाइन में अलग-अलग सामग्री होती है।  इसे समझाने के लिए, आइए एक ऐसे परिदृश्य पर विचार करें जहां दो टीमें एक ही सेवा के लिए अपडेट लागू कर रही हैं। टीम A क्रेडिट कार्ड समर्थन को एकीकृत कर रही है, जबकि टीम B उपयोगकर्ता प्रोफ़ाइल पृष्ठ में सुधार कर रही है। ऐसा लगता है कि इन सुविधाओं का एक दूसरे से कोई लेना-देना नहीं है।  हालाँकि, यह पता चला है कि भुगतान-संबंधित कोड पहले प्रोफ़ाइल पृष्ठ कोड के समान स्थान पर स्थित था। इसलिए दोनों टीमों ने अपना कोड अलग-अलग शाखाओं में निकाला और एकीकरण को फिर से लिखा।  अब सवाल यह है कि अपने परिवर्तनों को   शाखा में विलय करने वाला पहला कौन होगा और यह दिखावा करेगा कि समस्या उनके पक्ष में नहीं है जबकि दूसरी टीम परिणामी संघर्ष को हल करने की कोशिश करती है?  main  ट्रंक-आधारित विकास  कुल मिलाकर, विलय विवादों से बचना असंभव है, लेकिन हम निश्चित रूप से निम्नलिखित प्रसिद्ध नियम का उपयोग करके उन्हें हल करना आसान बना सकते हैं:  यदि कोई क्रिया कठिन और डरावनी है, तो उसे अधिक बार करें  गिट शर्तों में, इसका मतलब यह होगा कि हमें जितनी बार संभव हो विलय करने की आवश्यकता है (आदर्श रूप से प्रत्येक प्रतिबद्धता पर)। और निश्चित रूप से, उस मामले में संघर्ष अधिक बार होंगे, लेकिन उनका समाधान करना बहुत आसान होगा।  इसे ट्रंक-आधारित विकास कहा जाता है और इसका अर्थ है परिवर्तनों को सीधे   शाखा में धकेलना और अनावश्यक होने पर शाखाओं का उपयोग करने से बचना। main  ऊपर दिए गए उदाहरण में, यदि दोनों टीमें नियमित रूप से अपने परिवर्तनों को   शाखा में धकेलती हैं, तो वे तुरंत नोटिस करेंगे कि वे उसी फ़ाइल को संशोधित करने का प्रयास कर रहे हैं। main  इससे भी अधिक, वे मुद्दों को पूरी तरह टाल सकते थे। उन अद्यतनों पर विचार करते हुए पहली टीम ने पहले ही फ़ाइल को संशोधित कर लिया था, उसके बाद दूसरी टीम ने अपने बदलाव करना शुरू कर दिया होगा।   एक चौकस पाठक आश्चर्यचकित हो सकता है: सब कुछ बहुत अच्छा लगता है, लेकिन हम परीक्षण कैसे करें? प्रति फीचर शाखाएं रिलीज से पहले अलगाव में पूरी नई कार्यक्षमता का परीक्षण करने की अनुमति देती हैं; यदि हम परिवर्तनों को लगातार   शाखा में एकीकृत करते हैं, तो उसके लिए कोई अवसर नहीं होगा। main  पेश है फीचर फ्लैग्स  फीचर फ्लैग, या फीचर टॉगल, एक साधारण डायनेमिक फ्लैग है जो रनटाइम में विशेष फीचर को टॉगल करने की अनुमति देता है। आम तौर पर, फीचर फ्लैग उपयोगकर्ताओं के विशिष्ट समूहों, जैसे क्यूए इंजीनियरों, कर्मचारियों, विशिष्ट ग्राहकों आदि के लिए सुविधाओं को सक्षम या अक्षम करने की अनुमति देते हैं।   फ़ीचर फ़्लैग के कई अतिरिक्त लाभ हैं:  जोखिम मुक्त तैनाती  सीधे उत्पादन में अधिक विश्वसनीय परीक्षण  आवश्यकता पड़ने पर परिवर्तनों को तुरंत रोल बैक करें।  फ़ीचर फ़्लैग का उपयोग करने से   शाखा में परिवर्तन को सुरक्षित किया जा सकता है। जबकि फीचर फ़्लैग बंद है, परिवर्तन किसी को भी प्रभावित नहीं करते हैं। main  यह तकनीक सीधे   शाखा के साथ काम करने या अल्पकालिक शाखाएँ बनाने की अनुमति देती है। तो, विलय विवाद बहुत दुर्लभ हो जाते हैं और जल्दी से हल हो जाते हैं। main  निष्कर्ष  संक्षेप में, फीचर फ्लैग के साथ संयुक्त ट्रंक-आधारित विकास एक उत्कृष्ट तकनीक है जो फीचर शाखाओं में विरोधाभासी परिवर्तनों से प्रेरित कई समस्याओं से बचने में मदद करती है।  हालांकि, हमेशा की तरह, कोई एक आकार-फिट-सभी नहीं है। यह कम संख्या में टीमों के लिए काम करता है जो एक ही रिपॉजिटरी में काम कर रहे हैं - इस संख्या को बढ़ाने के लिए आमतौर पर कुछ समायोजन की आवश्यकता होती है।  इसके अलावा, दोनों विधियों का उपयोग करना हमेशा संभव होता है: विशिष्ट स्थिति और कार्य के आधार पर फीचर शाखाओं या फीचर फ्लैग का उपयोग करें।

Read My Stories

यह ऑडियो कहानी की मूल भाषा में निर्मित है!

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

About Author

टिप्पणियाँ

लेबल

इस लेख में चित्रित किया गया था

Related Stories

अपने वर्कफ़्लो को 10 गुना बेहतर कैसे बनाएं: 17 ज़रूरी ऐप्स

उपयोगकर्ता-केंद्रित क्रिप्टो उत्पाद बनाना: ग्राहक प्रतिक्रिया का महत्व

10 Reasons Why Publishing on HackerNoon Will Skyrocket Your Reach and Impact

फ्लोकी का वल्लाह भारत के श्रीलंका दौरे के लिए सहयोगी प्रायोजक के रूप में शामिल हुआ

अपने वर्कफ़्लो को 10 गुना बेहतर कैसे बनाएं: 17 ज़रूरी ऐप्स

उपयोगकर्ता-केंद्रित क्रिप्टो उत्पाद बनाना: ग्राहक प्रतिक्रिया का महत्व

10 Reasons Why Publishing on HackerNoon Will Skyrocket Your Reach and Impact

फ्लोकी का वल्लाह भारत के श्रीलंका दौरे के लिए सहयोगी प्रायोजक के रूप में शामिल हुआ

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps