ब्रांचिंग (संस्करण नियंत्रण): Difference between revisions

From Vigyanwiki
(Created page with "वर्जन कंट्रोल और सॉफ्टवेयर कॉन्फ़िगरेशन प्रबंधन में ब्रांचिंग,...")
 
(text)
Line 1: Line 1:
वर्जन कंट्रोल और [[सॉफ्टवेयर कॉन्फ़िगरेशन प्रबंधन]] में ब्रांचिंग, वर्जन कंट्रोल (जैसे [[सोर्स कोड]] फाइल या [[ निर्देशिका वृक्ष ]]) के तहत किसी ऑब्जेक्ट का दोहराव है। इसके बाद प्रत्येक वस्तु को अलग-अलग और समानांतर में संशोधित किया जा सकता है ताकि वस्तुएं अलग-अलग हो जाएं। इस संदर्भ में वस्तुओं को शाखाएँ कहा जाता है। [[संस्करण नियंत्रण]] प्रणाली के उपयोगकर्ता किसी भी शाखा की शाखा बना सकते हैं।
वर्जन कंट्रोल और [[सॉफ्टवेयर कॉन्फ़िगरेशन प्रबंधन|सॉफ्टवेयर कॉन्फ़िगरेशन मैनेजमेंट]] में '''ब्रांचिंग''', वर्जन कंट्रोल (जैसे [[सोर्स कोड]] फाइल या [[ निर्देशिका वृक्ष |डायरेक्टरी ट्री]]) के अंतर्गत किसी वस्तु का दोहराव है। इसके बाद प्रत्येक वस्तु को अलग-अलग और समानांतर में संशोधित किया जा सकता है ताकि वस्तुएं अलग-अलग हो जाएं। इस संदर्भ में वस्तुओं को शाखाएँ कहा जाता है। [[संस्करण नियंत्रण]] प्रणाली के उपयोगकर्ता किसी भी शाखा की शाखा बना सकते हैं।


शाखाओं को 'पेड़', 'धारा' या 'कोडलाइन' के रूप में भी जाना जाता है। मूल शाखा को कभी-कभी ''मूल शाखा'', ''अपस्ट्रीम शाखा'' (या केवल ''अपस्ट्रीम'' कहा जाता है, खासकर अगर शाखाओं को विभिन्न संगठनों या व्यक्तियों द्वारा बनाए रखा जाता है), या 'बैकिंग स्ट्रीम' '।
शाखाओं को 'ट्री', 'स्ट्रीम्स' या 'कोडलाइन' के रूप में भी जाना जाता है। मूल शाखा को कभी-कभी ''मूल शाखा'', ''अपस्ट्रीम शाखा'' (या केवल अपस्ट्रीम कहा जाता है, विशेष रूप से अगर शाखाओं को विभिन्न संगठनों या व्यक्तियों द्वारा बनाए रखा जाता है), या 'बैकिंग स्ट्रीम'।


''चाइल्ड ब्रांचेस'' वे शाखाएं हैं जिनके पैरेंट होते हैं; माता-पिता के बिना एक शाखा को ट्रंक या 'मेनलाइन' कहा जाता है।<ref>{{cite book |url= http://www.scmpatterns.com/book|title= Software Configuration Management Patterns: Effective Teamwork, Practical Integration |first1 =Steve |last1 =Berczuk | first2 =Brad | last2 = Appleton | ISBN = 0-20174117-2|year=2003|publisher=[[Addison-Wesley]]|access-date= 2007-05-24}}</ref> ट्रंक को कभी-कभी हेड के रूप में संदर्भित किया जाता है, लेकिन उचित रूप से सिर शाखा को नहीं, बल्कि किसी शाखा पर सबसे हालिया प्रतिबद्धता के लिए संदर्भित करता है, और दोनों ट्रंक और प्रत्येक नामित शाखा का अपना सिर होता है। ट्रंक आमतौर पर उस परियोजना का आधार माना जाता है जिस पर विकास होता है। यदि विकासकर्ता विशेष रूप से ट्रंक पर काम कर रहे हैं, तो इसमें हमेशा परियोजना का नवीनतम State of_the_art|अत्याधुनिक संस्करण शामिल होता है, लेकिन इसलिए यह सबसे अस्थिर संस्करण भी हो सकता है। एक अन्य दृष्टिकोण ट्रंक से एक शाखा को विभाजित करना है, उस शाखा में परिवर्तनों को लागू करना और जब शाखा स्थिर और काम कर रही हो तो परिवर्तनों को वापस ट्रंक में मर्ज कर दें। विकास मोड और [[कमिट (डेटा प्रबंधन)]] नीति के आधार पर ट्रंक में सबसे स्थिर या सबसे कम स्थिर या कुछ-बीच का संस्करण हो सकता है। ट्रंक के लिए अन्य शब्दों में बेसलाइन, मेनलाइन और मास्टर शामिल हैं, हालांकि कुछ मामलों में इनका उपयोग समान लेकिन अलग अर्थों में किया जाता है - देखें {{section link|version control|Common terminology}}. अक्सर मुख्य डेवलपर का काम ट्रंक में होता है और स्थिर संस्करण शाखित होते हैं, और कभी-कभी बग-फिक्स को शाखाओं से ट्रंक में मिला दिया जाता है। जब भविष्य के संस्करणों का विकास गैर-ट्रंक शाखाओं में किया जाता है, तो यह आमतौर पर उन परियोजनाओं के लिए किया जाता है जो अक्सर नहीं बदलते हैं, या जहां एक परिवर्तन को ट्रंक में शामिल करने के लिए तैयार होने तक विकसित होने में लंबा समय लगता है।
चाइल्ड ब्रांचेस वे शाखाएं हैं जिनके पैरेंट होते हैं; माता-पिता के बिना एक शाखा को ट्रंक या 'मेनलाइन' कहा जाता है। <ref>{{cite book |url= http://www.scmpatterns.com/book|title= Software Configuration Management Patterns: Effective Teamwork, Practical Integration |first1 =Steve |last1 =Berczuk | first2 =Brad | last2 = Appleton | ISBN = 0-20174117-2|year=2003|publisher=[[Addison-Wesley]]|access-date= 2007-05-24}}</ref> ट्रंक को कभी-कभी हेड के रूप में संदर्भित किया जाता है, लेकिन उचित रूप से हेड शाखा को नहीं, बल्कि किसी शाखा पर सबसे हालिया प्रतिबद्धता के लिए संदर्भित करता है, और दोनों ट्रंक और प्रत्येक नामित शाखा का अपना हेड होता है। ट्रंक सामान्यतः उस परियोजना का आधार माना जाता है जिस पर विकास होता है। यदि विकासकर्ता विशेष रूप से ट्रंक पर काम कर रहे हैं, तो इसमें हमेशा परियोजना का नवीनतम अत्याधुनिक संस्करण सम्मिलित होता है, लेकिन इसलिए यह सबसे अस्थिर संस्करण भी हो सकता है। एक अन्य दृष्टिकोण ट्रंक से एक शाखा को विभाजित करना है, उस शाखा में परिवर्तनों को लागू करना और जब शाखा स्थिर और काम कर रही हो तो परिवर्तनों को वापस ट्रंक में विलय कर दें। विकास प्रणाली और [[कमिट (डेटा प्रबंधन)]] नीति के आधार पर ट्रंक में सबसे स्थिर या सबसे कम स्थिर या कुछ-बीच का संस्करण हो सकता है। ट्रंक के लिए अन्य शब्दों में बेसलाइन, मेनलाइन और मास्टर सम्मिलित हैं, हालांकि कुछ स्तिथियों में इनका उपयोग समान लेकिन अलग अर्थों में किया जाता है - देखें {{section link|संस्करण नियंत्रण|सामान्य शब्दावली}}। प्रायः मुख्य विकासक का काम ट्रंक में होता है और स्थिर संस्करण शाखित होते हैं, और कभी-कभी बग-फिक्स को शाखाओं से ट्रंक में मिला दिया जाता है। जब भविष्य के संस्करणों का विकास गैर-ट्रंक शाखाओं में किया जाता है, तो यह सामान्यतः उन परियोजनाओं के लिए किया जाता है जो प्रायः नहीं बदलते हैं, या जहां एक परिवर्तन को ट्रंक में सम्मिलित करने के लिए तैयार होने तक विकसित होने में लंबा समय लगता है।


कुछ संशोधन नियंत्रण # वितरित संशोधन नियंत्रण में, जैसे [[डार्क्स]], रिपॉजिटरी (संस्करण नियंत्रण) और शाखाओं के बीच कोई भेद नहीं किया गया है; इन प्रणालियों में, रिपॉजिटरी की एक प्रति लाना ब्रांचिंग के बराबर है।
कुछ वितरित संशोधन नियंत्रण में, जैसे [[डार्क्स]], रिपॉजिटरी (संस्करण नियंत्रण) और शाखाओं के बीच कोई भेद नहीं किया गया है; इन प्रणालियों में, रिपॉजिटरी की एक प्रति लाना ब्रांचिंग के बराबर है।


ब्रांचिंग का तात्पर्य बाद में [[विलय (संशोधन नियंत्रण)]] या मूल शाखा में परिवर्तनों को वापस एकीकृत करने की क्षमता से भी है। अक्सर परिवर्तन वापस ट्रंक में विलय कर दिए जाते हैं, भले ही यह मूल शाखा न हो। एक शाखा जिसका विलय करने का इरादा नहीं है (उदाहरण के लिए क्योंकि यह किसी तीसरे पक्ष द्वारा असंगत लाइसेंस के तहत जारी किया गया है, या यह एक अलग उद्देश्य की सेवा करने का प्रयास करता है) को आमतौर पर फोर्क (सॉफ्टवेयर विकास) कहा जाता है।
ब्रांचिंग का तात्पर्य बाद में [[विलय (संशोधन नियंत्रण)]] या मूल शाखा में परिवर्तनों को वापस एकीकृत करने की क्षमता से भी है। प्रायः परिवर्तन वापस ट्रंक में विलय कर दिए जाते हैं, भले ही यह मूल शाखा न हो। एक शाखा जिसका विलय करने का अभीष्ट नहीं है (उदाहरण के लिए क्योंकि यह किसी तीसरे पक्ष द्वारा असंगत लाइसेंस के अंतर्गत जारी किया गया है, या यह एक अलग उद्देश्य की सेवा करने का प्रयास करता है) को सामान्यतः फोर्क (सॉफ्टवेयर विकास) कहा जाता है।


== ब्रांचिंग के लिए प्रेरणा ==
== ब्रांचिंग के लिए प्रेरणा ==
शाखाएँ सॉफ्टवेयर के कुछ हिस्सों को समानांतर में विकसित करने की अनुमति देती हैं।<ref>{{cite web | url=http://www.hillside.net/plop/plop98/final_submissions/P37.pdf | first1 =Brad | last1 = Appleton | first2 = Stephen | last2 = Berczuk | first3 = Ralph | last3 = Cabrera | first4 = Robert | last4 = Orenstein | title=Streamed Lines: Branching Patterns for Parallel Software Development | date=1998-02-08 | publisher= Hillside | format = [[PDF]] | access-date =2009-08-12}}</ref> बड़ी परियोजनाओं को भरने के लिए कई भूमिकाओं की आवश्यकता होती है, जिसमें डेवलपर्स, बिल्ड मैनेजर और सॉफ्टवेयर गुणवत्ता आश्वासन कर्मी शामिल हैं। इसके अलावा, विभिन्न ऑपरेटिंग सिस्टम प्लेटफॉर्म पर कई रिलीज को बनाए रखना पड़ सकता है। शाखाएँ योगदानकर्ताओं को कोडबेस को अस्थिर किए बिना परिवर्तनों को अलग करने की अनुमति देती हैं, उदाहरण के लिए, बग के लिए [[पैच (कंप्यूटिंग)]], नई सुविधा (सॉफ़्टवेयर डिज़ाइन),<ref>{{cite web | url=http://www.lostechies.com/blogs/derickbailey/archive/2009/07/15/branch-per-feature-source-control-part-1-why.aspx | first =Derick | last = Bailey | work =Branch-Per-Feature Source Control | title = Part 1: Why | date=2009-07-15 | publisher= Los techies | access-date=2009-08-12}}</ref> और [[सॉफ्टवेयर वर्जनिंग]] [[ प्रणाली एकीकरण ]]। परीक्षण के बाद ये परिवर्तन बाद में विलय (संशोधन नियंत्रण) (पुनः सिंक्रनाइज़) हो सकते हैं।
शाखाएँ सॉफ्टवेयर के कुछ हिस्सों को समानांतर में विकसित करने की अनुमति देती हैं। <ref>{{cite web | url=http://www.hillside.net/plop/plop98/final_submissions/P37.pdf | first1 =Brad | last1 = Appleton | first2 = Stephen | last2 = Berczuk | first3 = Ralph | last3 = Cabrera | first4 = Robert | last4 = Orenstein | title=Streamed Lines: Branching Patterns for Parallel Software Development | date=1998-02-08 | publisher= Hillside | format = [[PDF]] | access-date =2009-08-12}}</ref> बड़ी परियोजनाओं को भरने के लिए कई भूमिकाओं की आवश्यकता होती है, जिसमें डेवलपर्स, बिल्ड मैनेजर और सॉफ्टवेयर गुणवत्ता आश्वासन कर्मी सम्मिलित हैं। इसके अतिरिक्त, विभिन्न ऑपरेटिंग सिस्टम प्लेटफॉर्म पर कई रिलीज को बनाए रखना पड़ सकता है। शाखाएँ योगदानकर्ताओं को कोडबेस को अस्थिर किए बिना परिवर्तनों को अलग करने की अनुमति देती हैं, उदाहरण के लिए, बग के लिए [[पैच (कंप्यूटिंग)]], नवीन फीचर (सॉफ़्टवेयर अभिकल्पना),<ref>{{cite web | url=http://www.lostechies.com/blogs/derickbailey/archive/2009/07/15/branch-per-feature-source-control-part-1-why.aspx | first =Derick | last = Bailey | work =Branch-Per-Feature Source Control | title = Part 1: Why | date=2009-07-15 | publisher= Los techies | access-date=2009-08-12}}</ref> और [[सॉफ्टवेयर वर्जनिंग]] [[ प्रणाली एकीकरण | प्रणाली एकीकरण]] है। परीक्षण के बाद ये परिवर्तन बाद में विलय (संशोधन नियंत्रण) (पुनः समकालित) हो सकते हैं।


== विकास शाखा ==<!-- This section is linked from [[Development]] -->
== डेवलपमेंट ब्रांच ==
एक विकास शाखा या सॉफ्टवेयर के एक हिस्से का विकास वृक्ष एक ऐसा संस्करण है जो सॉफ्टवेयर विकास के अंतर्गत है, और अभी तक आधिकारिक तौर पर [[सॉफ्टवेयर रिलीज]] नहीं किया गया है। [[ओपन-सोर्स मॉडल]] समुदाय में, रिलीज़ की धारणा आम तौर पर रूपक है, क्योंकि कोई भी आमतौर पर किसी वांछित संस्करण की जांच कर सकता है, चाहे वह विकास शाखा में हो या नहीं। अक्सर, जो संस्करण अंततः अगला प्रमुख संस्करण बन जाएगा, उसे विकास शाखा कहा जाता है। हालाँकि, एक निश्चित समय में अक्सर सॉफ्टवेयर के एक से अधिक अनुवर्ती संस्करण विकास के अधीन होते हैं।
एक डेवलपमेंट ब्रांच या सॉफ्टवेयर के एक हिस्से का डेवलपमेंट ट्री एक ऐसा संस्करण है जो सॉफ्टवेयर विकास के अंतर्गत है, और अभी तक आधिकारिक तौर पर [[सॉफ्टवेयर रिलीज]] नहीं किया गया है। [[ओपन-सोर्स मॉडल|ओपन-सोर्स प्रतिरूप]] समुदाय में, रिलीज़ की धारणा सामान्य रूप से रूपक है, क्योंकि कोई भी सामान्यतः किसी वांछित संस्करण की जांच कर सकता है, चाहे वह विकास शाखा में हो या नहीं। प्रायः, जो संस्करण अंततः अगला प्रमुख संस्करण बन जाएगा, उसे विकास शाखा कहा जाता है। हालाँकि, एक निश्चित समय में प्रायः सॉफ्टवेयर के एक से अधिक अनुवर्ती संस्करण विकास के अधीन होते हैं।


कुछ पुनरीक्षण नियंत्रण प्रणालियों में मुख्य विकास शाखा के लिए विशिष्ट शब्दावली होती है। उदाहरण के लिए, [[समवर्ती संस्करण प्रणाली]] में, इसे मुख्य शाखा कहा जाता है। [[गिट]] डिफ़ॉल्ट रूप से मास्टर का उपयोग करता है, हालांकि गिटहब<ref>{{Cite web|url=https://www.techrepublic.com/article/github-to-replace-master-with-main-starting-in-october-what-developers-need-to-know/|title=GitHub to replace master with main starting in October: What developers need to do now|last=Wallen|first=Jack|date=2020-09-22|website=TechRepublic|access-date=2022-04-24}}</ref><ref>{{Cite web|url=https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main|title=GitHub ने अपनी मास्टर ब्रांच का नाम बदलकर main क्यों कर दिया|last=Heinze|first=Carolyn|date=2020-11-24|website=TheServerSide|access-date=2022-04-24}}</ref> और [[GitLab]] ने जॉर्ज फ्लॉयड की हत्या की मुख्य प्रतिक्रियाओं पर स्विच किया। एक अधिक सामान्य शब्द ट्रंक है।
कुछ पुनरीक्षण नियंत्रण प्रणालियों में मुख्य विकास शाखा के लिए विशिष्ट शब्दावली होती है। उदाहरण के लिए, [[समवर्ती संस्करण प्रणाली]] में, इसे मुख्य शाखा कहा जाता है। [[गिट]] डिफ़ॉल्ट रूप से मास्टर का उपयोग करता है, हालांकि गिटहब <ref>{{Cite web|url=https://www.techrepublic.com/article/github-to-replace-master-with-main-starting-in-october-what-developers-need-to-know/|title=GitHub to replace master with main starting in October: What developers need to do now|last=Wallen|first=Jack|date=2020-09-22|website=TechRepublic|access-date=2022-04-24}}</ref><ref>{{Cite web|url=https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main|title=GitHub ने अपनी मास्टर ब्रांच का नाम बदलकर main क्यों कर दिया|last=Heinze|first=Carolyn|date=2020-11-24|website=TheServerSide|access-date=2022-04-24}}</ref> और [[GitLab|गिटलैब]] ने जॉर्ज फ्लॉयड की हत्या की मुख्य प्रतिक्रियाओं पर स्थानांतरण किया। एक अधिक सामान्य शब्द ट्रंक है।


== छाया या जादू की शाखाएँ ==
== शैडो या मैजिक ब्रांचेज ==
[[सीवीएसएनटी]] में, एक शैडो या मैजिक ब्रांच अपस्ट्रीम ब्रांच में किए गए बदलावों को शैडो करती है, जिससे छोटे बदलावों को बनाए रखना आसान हो जाता है (सीवीसी एक ओपन-सोर्स पैकेज बिल्डिंग सिस्टम है{{Citation needed |date=November 2010}} [[rPath]] द्वारा उत्पादित पैकेजों के लिए संशोधन-नियंत्रण प्रणाली को शामिल करना।)
[[सीवीएसएनटी]] में, एक शैडो या मैजिक ब्रांच अपस्ट्रीम ब्रांच में किए गए बदलावों को शैडो करती है, जिससे छोटे बदलावों को बनाए रखना आसान हो जाता है (सीवीसी एक ओपन-सोर्स पैकेज बिल्डिंग सिस्टम है [[rPath]] द्वारा उत्पादित पैकेजों के लिए संशोधन-नियंत्रण प्रणाली को सम्मिलित करता है।)


== रिपोजिटरी क्लोन ==
== रिपोजिटरी क्लोन ==


वितरित पुनरीक्षण नियंत्रण में, शाखाओं के साथ संपूर्ण रिपॉजिटरी को कॉपी किया जा सकता है और आगे काम किया जा सकता है। [[मोनोटोन (सॉफ्टवेयर)]] (एमटीएन), मर्कुरियल (एचजी) और [[गिट (सॉफ्टवेयर)]] इसे क्लोन कहते हैं; बाज़ार (सॉफ्टवेयर) इसे शाखा कहते हैं।{{citation needed|date=October 2019}}
वितरित पुनरीक्षण नियंत्रण में, शाखाओं के साथ संपूर्ण रिपॉजिटरी का अनुकरण किया जा सकता है और आगे काम किया जा सकता है। [[मोनोटोन (सॉफ्टवेयर)]] (एमटीएन), मर्कुरियल (एचजी) और [[गिट (सॉफ्टवेयर)]] इसे क्लोन कहते हैं; बाज़ार (सॉफ्टवेयर) इसे शाखा कहते हैं।


== यह भी देखें ==
== यह भी देखें ==

Revision as of 10:06, 28 June 2023

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

शाखाओं को 'ट्री', 'स्ट्रीम्स' या 'कोडलाइन' के रूप में भी जाना जाता है। मूल शाखा को कभी-कभी मूल शाखा, अपस्ट्रीम शाखा (या केवल अपस्ट्रीम कहा जाता है, विशेष रूप से अगर शाखाओं को विभिन्न संगठनों या व्यक्तियों द्वारा बनाए रखा जाता है), या 'बैकिंग स्ट्रीम'।

चाइल्ड ब्रांचेस वे शाखाएं हैं जिनके पैरेंट होते हैं; माता-पिता के बिना एक शाखा को ट्रंक या 'मेनलाइन' कहा जाता है। [1] ट्रंक को कभी-कभी हेड के रूप में संदर्भित किया जाता है, लेकिन उचित रूप से हेड शाखा को नहीं, बल्कि किसी शाखा पर सबसे हालिया प्रतिबद्धता के लिए संदर्भित करता है, और दोनों ट्रंक और प्रत्येक नामित शाखा का अपना हेड होता है। ट्रंक सामान्यतः उस परियोजना का आधार माना जाता है जिस पर विकास होता है। यदि विकासकर्ता विशेष रूप से ट्रंक पर काम कर रहे हैं, तो इसमें हमेशा परियोजना का नवीनतम अत्याधुनिक संस्करण सम्मिलित होता है, लेकिन इसलिए यह सबसे अस्थिर संस्करण भी हो सकता है। एक अन्य दृष्टिकोण ट्रंक से एक शाखा को विभाजित करना है, उस शाखा में परिवर्तनों को लागू करना और जब शाखा स्थिर और काम कर रही हो तो परिवर्तनों को वापस ट्रंक में विलय कर दें। विकास प्रणाली और कमिट (डेटा प्रबंधन) नीति के आधार पर ट्रंक में सबसे स्थिर या सबसे कम स्थिर या कुछ-बीच का संस्करण हो सकता है। ट्रंक के लिए अन्य शब्दों में बेसलाइन, मेनलाइन और मास्टर सम्मिलित हैं, हालांकि कुछ स्तिथियों में इनका उपयोग समान लेकिन अलग अर्थों में किया जाता है - देखें संस्करण नियंत्रण § सामान्य शब्दावली। प्रायः मुख्य विकासक का काम ट्रंक में होता है और स्थिर संस्करण शाखित होते हैं, और कभी-कभी बग-फिक्स को शाखाओं से ट्रंक में मिला दिया जाता है। जब भविष्य के संस्करणों का विकास गैर-ट्रंक शाखाओं में किया जाता है, तो यह सामान्यतः उन परियोजनाओं के लिए किया जाता है जो प्रायः नहीं बदलते हैं, या जहां एक परिवर्तन को ट्रंक में सम्मिलित करने के लिए तैयार होने तक विकसित होने में लंबा समय लगता है।

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

ब्रांचिंग का तात्पर्य बाद में विलय (संशोधन नियंत्रण) या मूल शाखा में परिवर्तनों को वापस एकीकृत करने की क्षमता से भी है। प्रायः परिवर्तन वापस ट्रंक में विलय कर दिए जाते हैं, भले ही यह मूल शाखा न हो। एक शाखा जिसका विलय करने का अभीष्ट नहीं है (उदाहरण के लिए क्योंकि यह किसी तीसरे पक्ष द्वारा असंगत लाइसेंस के अंतर्गत जारी किया गया है, या यह एक अलग उद्देश्य की सेवा करने का प्रयास करता है) को सामान्यतः फोर्क (सॉफ्टवेयर विकास) कहा जाता है।

ब्रांचिंग के लिए प्रेरणा

शाखाएँ सॉफ्टवेयर के कुछ हिस्सों को समानांतर में विकसित करने की अनुमति देती हैं। [2] बड़ी परियोजनाओं को भरने के लिए कई भूमिकाओं की आवश्यकता होती है, जिसमें डेवलपर्स, बिल्ड मैनेजर और सॉफ्टवेयर गुणवत्ता आश्वासन कर्मी सम्मिलित हैं। इसके अतिरिक्त, विभिन्न ऑपरेटिंग सिस्टम प्लेटफॉर्म पर कई रिलीज को बनाए रखना पड़ सकता है। शाखाएँ योगदानकर्ताओं को कोडबेस को अस्थिर किए बिना परिवर्तनों को अलग करने की अनुमति देती हैं, उदाहरण के लिए, बग के लिए पैच (कंप्यूटिंग), नवीन फीचर (सॉफ़्टवेयर अभिकल्पना),[3] और सॉफ्टवेयर वर्जनिंग प्रणाली एकीकरण है। परीक्षण के बाद ये परिवर्तन बाद में विलय (संशोधन नियंत्रण) (पुनः समकालित) हो सकते हैं।

डेवलपमेंट ब्रांच

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

कुछ पुनरीक्षण नियंत्रण प्रणालियों में मुख्य विकास शाखा के लिए विशिष्ट शब्दावली होती है। उदाहरण के लिए, समवर्ती संस्करण प्रणाली में, इसे मुख्य शाखा कहा जाता है। गिट डिफ़ॉल्ट रूप से मास्टर का उपयोग करता है, हालांकि गिटहब [4][5] और गिटलैब ने जॉर्ज फ्लॉयड की हत्या की मुख्य प्रतिक्रियाओं पर स्थानांतरण किया। एक अधिक सामान्य शब्द ट्रंक है।

शैडो या मैजिक ब्रांचेज

सीवीएसएनटी में, एक शैडो या मैजिक ब्रांच अपस्ट्रीम ब्रांच में किए गए बदलावों को शैडो करती है, जिससे छोटे बदलावों को बनाए रखना आसान हो जाता है (सीवीसी एक ओपन-सोर्स पैकेज बिल्डिंग सिस्टम है rPath द्वारा उत्पादित पैकेजों के लिए संशोधन-नियंत्रण प्रणाली को सम्मिलित करता है।)

रिपोजिटरी क्लोन

वितरित पुनरीक्षण नियंत्रण में, शाखाओं के साथ संपूर्ण रिपॉजिटरी का अनुकरण किया जा सकता है और आगे काम किया जा सकता है। मोनोटोन (सॉफ्टवेयर) (एमटीएन), मर्कुरियल (एचजी) और गिट (सॉफ्टवेयर) इसे क्लोन कहते हैं; बाज़ार (सॉफ्टवेयर) इसे शाखा कहते हैं।

यह भी देखें

संदर्भ

  1. ↑ Berczuk, Steve; Appleton, Brad (2003). Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Addison-Wesley. ISBN 0-20174117-2. Retrieved 2007-05-24.
  2. ↑ Appleton, Brad; Berczuk, Stephen; Cabrera, Ralph; Orenstein, Robert (1998-02-08). "Streamed Lines: Branching Patterns for Parallel Software Development" (PDF). Hillside. Retrieved 2009-08-12.
  3. ↑ Bailey, Derick (2009-07-15). "Part 1: Why". Branch-Per-Feature Source Control. Los techies. Retrieved 2009-08-12.
  4. ↑ Wallen, Jack (2020-09-22). "GitHub to replace master with main starting in October: What developers need to do now". TechRepublic. Retrieved 2022-04-24.
  5. ↑ Heinze, Carolyn (2020-11-24). "GitHub ने अपनी मास्टर ब्रांच का नाम बदलकर main क्यों कर दिया". TheServerSide. Retrieved 2022-04-24.
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=ब्रांचिंग_(संस्करण_नियंत्रण)&oldid=200138’