संस्करण नियंत्रण: Difference between revisions
From Vigyanwiki
No edit summary |
|||
| Line 2: | Line 2: | ||
{{Redirect|स्रोत नियंत्रण|चिकित्सा और पर्यावरण में अन्य उपयोग|स्रोत नियंत्रण (बहुविकल्पी)}} | {{Redirect|स्रोत नियंत्रण|चिकित्सा और पर्यावरण में अन्य उपयोग|स्रोत नियंत्रण (बहुविकल्पी)}} | ||
{{Redirect|संशोधन नियंत्रण प्रणाली|विशिष्ट सॉफ्टवेयर कार्यान्वयन|संशोधन नियंत्रण प्रणाली}} | {{Redirect|संशोधन नियंत्रण प्रणाली|विशिष्ट सॉफ्टवेयर कार्यान्वयन|संशोधन नियंत्रण प्रणाली}} | ||
{{More citations needed |date=April 2011}} [[सॉफ्टवेयर इंजीनियरिंग|सॉफ्टवेयर अभियांत्रिकी]] में, संस्करण नियंत्रण (जिसे पुनरीक्षण नियंत्रण, स्रोत नियंत्रण या स्रोत कोड प्रबंधन के रूप में भी जाना जाता है) [[कंप्यूटर प्रोग्राम]], दस्तावेज़, बड़ी वेब साइट या सूचना के अन्य संग्रह में परिवर्तन के प्रबंधन के लिए जिम्मेदार | {{More citations needed |date=April 2011}} [[सॉफ्टवेयर इंजीनियरिंग|सॉफ्टवेयर अभियांत्रिकी]] में, संस्करण नियंत्रण (जिसे पुनरीक्षण नियंत्रण, स्रोत नियंत्रण या स्रोत कोड प्रबंधन के रूप में भी जाना जाता है) [[कंप्यूटर प्रोग्राम]], दस्तावेज़, बड़ी वेब साइट या सूचना के अन्य संग्रह में परिवर्तन के प्रबंधन के लिए जिम्मेदार प्रणाली का वर्ग है। संस्करण नियंत्रण [[सॉफ्टवेयर कॉन्फ़िगरेशन प्रबंधन]] का घटक है।<ref name="Mercurial">{{cite book|last1=O'Sullivan|first1=Bryan|url=http://hgbook.red-bean.com/read/|title=Mercurial: निश्चित गाइड|date=2009|publisher=O'Reilly Media, Inc.|isbn=9780596555474|location=Sebastopol|access-date=4 September 2015}}</ref> | ||
परिवर्तनों को सामान्यतः संख्या या अक्षर कोड द्वारा पहचाना जाता है, जिसे संशोधन संख्या, संशोधन स्तर या केवल संशोधन कहा जाता है। उदाहरण के लिए, फ़ाइलों का प्रारंभिक सेट संशोधन 1 है। जब पहला परिवर्तन किया जाता है, परिणामी सेट संशोधन 2 होता है, और इसी तरह आगे भी। प्रत्येक संशोधन [[TIMESTAMP|टाईम स्टैम्प]] और परिवर्तन करने वाले व्यक्ति से जुड़ा होता है। संशोधनों की तुलना की जा सकती है, उन्हें पुनर्स्थापित किया जा सकता है, और कुछ प्रकार की फाइलों के साथ विलय किया जा सकता है।<ref>{{Cite book|last=Scott|first=Chacon|url=https://git-scm.com/book/en/v2|title=प्रो गिट दूसरा संस्करण|last2=Straub|first2=Ben|publisher=[[Apress]]|year=2014|location=United States|pages=14|language=en}}</ref> | परिवर्तनों को सामान्यतः संख्या या अक्षर कोड द्वारा पहचाना जाता है, जिसे संशोधन संख्या, संशोधन स्तर या केवल संशोधन कहा जाता है। उदाहरण के लिए, फ़ाइलों का प्रारंभिक सेट संशोधन 1 है। जब पहला परिवर्तन किया जाता है, परिणामी सेट संशोधन 2 होता है, और इसी तरह आगे भी। प्रत्येक संशोधन [[TIMESTAMP|टाईम स्टैम्प]] और परिवर्तन करने वाले व्यक्ति से जुड़ा होता है। संशोधनों की तुलना की जा सकती है, उन्हें पुनर्स्थापित किया जा सकता है, और कुछ प्रकार की फाइलों के साथ विलय किया जा सकता है।<ref>{{Cite book|last=Scott|first=Chacon|url=https://git-scm.com/book/en/v2|title=प्रो गिट दूसरा संस्करण|last2=Straub|first2=Ben|publisher=[[Apress]]|year=2014|location=United States|pages=14|language=en}}</ref> | ||
| Line 8: | Line 8: | ||
संशोधनों को व्यवस्थित और नियंत्रित करने के लिए तार्किक तरीके की आवश्यकता लगभग तब तक रही है जब तक लेखन अस्तित्व में रहा है, लेकिन कंप्यूटिंग का युग शुरू होने पर संशोधन नियंत्रण अधिक महत्वपूर्ण और जटिल हो गया। [[संस्करण (पुस्तक)]] की संख्या और विनिर्देश (तकनीकी मानक) ऐसे उदाहरण हैं जो प्रिंट-ओनली युग के हैं। आज, सबसे सक्षम (साथ ही जटिल) पुनरीक्षण नियंत्रण प्रणालियां वे हैं जिनका उपयोग सॉफ्टवेयर विकास में किया जाता है, जहां लोगों की टीम समवर्ती रूप से समान फ़ाइलों में परिवर्तन कर सकती है। | संशोधनों को व्यवस्थित और नियंत्रित करने के लिए तार्किक तरीके की आवश्यकता लगभग तब तक रही है जब तक लेखन अस्तित्व में रहा है, लेकिन कंप्यूटिंग का युग शुरू होने पर संशोधन नियंत्रण अधिक महत्वपूर्ण और जटिल हो गया। [[संस्करण (पुस्तक)]] की संख्या और विनिर्देश (तकनीकी मानक) ऐसे उदाहरण हैं जो प्रिंट-ओनली युग के हैं। आज, सबसे सक्षम (साथ ही जटिल) पुनरीक्षण नियंत्रण प्रणालियां वे हैं जिनका उपयोग सॉफ्टवेयर विकास में किया जाता है, जहां लोगों की टीम समवर्ती रूप से समान फ़ाइलों में परिवर्तन कर सकती है। | ||
वर्जन कंट्रोल | वर्जन कंट्रोल प्रणाली सामान्यतः स्टैंड-अलोन एप्लिकेशन के रूप में चलाए जाते हैं, लेकिन संशोधन नियंत्रण भी विभिन्न प्रकार के [[सॉफ्टवेयर डेवलपमेंट]] एम्बेड किया जाता है, जैसे [[शब्द संसाधक]] और [[स्प्रेडशीट]], सहयोगी [[ग्रुपवेयर]],<ref>{{Citation |url=https://support.google.com/docs/answer/190843 |title=See what's changed in a file |contribution=[[Google Docs]] |publisher=Google Inc.}}.</ref> और सामग्री प्रबंधन प्रणालियाँ, उदाहरण के लिए, विकिपीडिया की सहायता: पृष्ठ इतिहास। संशोधन नियंत्रण किसी दस्तावेज़ को पिछले संशोधन में वापस लाने में सक्षम बनाता है, जो संपादकों को दूसरे के संपादनों को ट्रैक करने, गलतियों को सुधारने और [[हफ्ता]] में बर्बरता और [[स्पैमिंग]] से बचाव करने की अनुमति देने के लिए महत्वपूर्ण है। | ||
== सिंहावलोकन == | == सिंहावलोकन == | ||
| Line 15: | Line 15: | ||
जैसा कि टीम सॉफ्टवेयर डिजाइन, विकसित और तैनात करती है, ही सॉफ्टवेयर के कई संस्करणों को अलग-अलग साइटों पर तैनात किया जाना [[ट्रंक (सॉफ्टवेयर)]] के डेवलपर्स के लिए अपडेट पर साथ काम करना आम बात है। [[कंप्यूटर बग]] या सॉफ्टवेयर की विशेषताएं अधिकांशतः केवल कुछ संस्करणों में ही सम्मलित होती हैं (क्योंकि कुछ समस्याओं को ठीक करने और कार्यक्रम के विकास के रूप में दूसरों की शुरूआत के कारण)। इसलिए, बगों का पता लगाने और उन्हें ठीक करने के प्रयोजनों के लिए, यह निर्धारित करने के लिए सॉफ़्टवेयर के विभिन्न संस्करणों को पुनः प्राप्त करने और चलाने में सक्षम होना महत्वपूर्ण है कि समस्या किस संस्करण में होती है। सॉफ़्टवेयर के दो संस्करणों को समवर्ती रूप से विकसित करना भी आवश्यक हो सकता है: उदाहरण के लिए, जहाँ संस्करण में बग फिक्स हैं, लेकिन कोई नई सुविधाएँ नहीं हैं ([[ब्रांचिंग (संशोधन नियंत्रण)]]), जबकि दूसरा संस्करण वह है जहाँ नई सुविधाओं पर काम किया जाता है (ट्रंक () सॉफ्टवेयर))। | जैसा कि टीम सॉफ्टवेयर डिजाइन, विकसित और तैनात करती है, ही सॉफ्टवेयर के कई संस्करणों को अलग-अलग साइटों पर तैनात किया जाना [[ट्रंक (सॉफ्टवेयर)]] के डेवलपर्स के लिए अपडेट पर साथ काम करना आम बात है। [[कंप्यूटर बग]] या सॉफ्टवेयर की विशेषताएं अधिकांशतः केवल कुछ संस्करणों में ही सम्मलित होती हैं (क्योंकि कुछ समस्याओं को ठीक करने और कार्यक्रम के विकास के रूप में दूसरों की शुरूआत के कारण)। इसलिए, बगों का पता लगाने और उन्हें ठीक करने के प्रयोजनों के लिए, यह निर्धारित करने के लिए सॉफ़्टवेयर के विभिन्न संस्करणों को पुनः प्राप्त करने और चलाने में सक्षम होना महत्वपूर्ण है कि समस्या किस संस्करण में होती है। सॉफ़्टवेयर के दो संस्करणों को समवर्ती रूप से विकसित करना भी आवश्यक हो सकता है: उदाहरण के लिए, जहाँ संस्करण में बग फिक्स हैं, लेकिन कोई नई सुविधाएँ नहीं हैं ([[ब्रांचिंग (संशोधन नियंत्रण)]]), जबकि दूसरा संस्करण वह है जहाँ नई सुविधाओं पर काम किया जाता है (ट्रंक () सॉफ्टवेयर))। | ||
सबसे सरल स्तर पर, डेवलपर्स प्रोग्राम के विभिन्न संस्करणों की कई प्रतियों को | सबसे सरल स्तर पर, डेवलपर्स प्रोग्राम के विभिन्न संस्करणों की कई प्रतियों को सरलता से रख सकते हैं, और उन्हें उचित रूप से लेबल कर सकते हैं। इस सरल तरीके का उपयोग कई बड़ी सॉफ्टवेयर परियोजनाओं में किया गया है। जबकि यह विधि काम कर सकती है, यह अक्षम है क्योंकि कार्यक्रम की कई समान-समान प्रतियों को बनाए रखना पड़ता है। इसके लिए डेवलपर्स को बहुत अधिक आत्म-अनुशासन की आवश्यकता होती है और अधिकांशतः गलतियाँ होती हैं। चूंकि कोड आधार समान है, इसलिए इसे डेवलपर्स के सेट को पढ़ने-लिखने-निष्पादित करने की अनुमति देने की भी आवश्यकता होती है, और यह अनुमतियों को प्रबंधित करने वाले किसी व्यक्ति के दबाव को जोड़ता है जिससे कि कोड आधार समझौता न हो, जो अधिक जटिलता जोड़ता है। परिणाम स्वरूप, संशोधन नियंत्रण प्रक्रिया के कुछ या सभी को स्वचालित करने के लिए प्रणाली विकसित किए गए हैं। यह सुनिश्चित करता है कि संस्करण नियंत्रण चरणों का अधिकांश प्रबंधन पर्दे के पीछे छिपा हुआ है। | ||
इसके अतिरिक्त, सॉफ्टवेयर विकास, कानूनी और व्यावसायिक अभ्यास, और अन्य वातावरण में, टीम द्वारा संपादित किए जाने वाले एकल दस्तावेज़ या कोड के स्निपेट के लिए यह तेजी से सामान्य हो गया है, जिसके सदस्य भौगोलिक रूप से अलग-अलग हो सकते हैं और अलग-अलग और यहां तक कि इसके विपरीत हो सकते हैं। रूचियाँ। परिष्कृत पुनरीक्षण नियंत्रण जो दस्तावेजों और कोड में परिवर्तनों के स्वामित्व के लिए ट्रैक करता है और ऐसी स्थितियों में अत्यंत सहायक या अपरिहार्य भी हो सकता है। | इसके अतिरिक्त, सॉफ्टवेयर विकास, कानूनी और व्यावसायिक अभ्यास, और अन्य वातावरण में, टीम द्वारा संपादित किए जाने वाले एकल दस्तावेज़ या कोड के स्निपेट के लिए यह तेजी से सामान्य हो गया है, जिसके सदस्य भौगोलिक रूप से अलग-अलग हो सकते हैं और अलग-अलग और यहां तक कि इसके विपरीत हो सकते हैं। रूचियाँ। परिष्कृत पुनरीक्षण नियंत्रण जो दस्तावेजों और कोड में परिवर्तनों के स्वामित्व के लिए ट्रैक करता है और ऐसी स्थितियों में अत्यंत सहायक या अपरिहार्य भी हो सकता है। | ||
पुनरीक्षण नियंत्रण [[विन्यास फाइल]] में परिवर्तनों को भी ट्रैक कर सकता है, जैसे कि सामान्यतः इसमें संग्रहीत <code>/etc</code> या <code>/usr/local/etc</code> यूनिक्स | पुनरीक्षण नियंत्रण [[विन्यास फाइल]] में परिवर्तनों को भी ट्रैक कर सकता है, जैसे कि सामान्यतः इसमें संग्रहीत <code>/etc</code> या <code>/usr/local/etc</code> यूनिक्स प्रणाली पर। यह प्रणाली प्रशासकों को किए गए परिवर्तनों को सरलता से ट्रैक करने का तरीका देता है और आवश्यकता पड़ने पर प्राचीन संस्करणों में वापस जाने का तरीका देता है। | ||
== इतिहास == | == इतिहास == | ||
{{See also|संस्करण नियंत्रण सॉफ्टवेयर की तुलना # इतिहास और अपनाना}} | {{See also|संस्करण नियंत्रण सॉफ्टवेयर की तुलना # इतिहास और अपनाना}} | ||
OS/360 और उत्तराधिकारी के लिए | OS/360 और उत्तराधिकारी के लिए आईबीएम का OS/360 समर्थन कार्यक्रम आईईबीयूपीडीटीई (IEBUPDTE) सॉफ़्टवेयर अपडेट टूल 1962 से पहले का है, यकीनन संस्करण नियंत्रण प्रणाली टूल का अग्रदूत है। स्रोत कोड नियंत्रण के लिए डिज़ाइन किया गया पूर्ण प्रणाली 1972 में शुरू किया गया था, उसी प्रणाली के लिए [[स्रोत कोड नियंत्रण प्रणाली]] (OS/360)। स्रोत कोड नियंत्रण प्रणाली की शुरूआत, 4 दिसंबर, 1975 को प्रकाशित होने के कारण, ऐतिहासिक रूप से निहित है कि यह पहली जानबूझकर संशोधन नियंत्रण प्रणाली थी।<ref>{{cite journal|url=https://basepath.com/aup/talks/SCCS-Slideshow.pdf |journal=IEEE Transactions on Software Engineering |volume=SE-1 |issue=4 |pages=364–370 | title=स्रोत कोड नियंत्रण प्रणाली|year=1975 |doi=10.1109/TSE.1975.6312866 |s2cid=10006076 |last1=Rochkind |first1=Marc J. }}</ref> आरसीएस ने ठीक बाद में पीछा किया,<ref>{{Cite journal|last=Tichy|first=Walter F.|date=1985|title=आरसीएस - संस्करण नियंत्रण के लिए एक प्रणाली|url=http://dx.doi.org/10.1002/spe.4380150703|journal=Software: Practice and Experience|volume=15|issue=7|pages=637–654|doi=10.1002/spe.4380150703|s2cid=2605086|issn=0038-0644}}</ref> इसके नेटवर्क संस्करण [[समवर्ती संस्करण प्रणाली]] के साथ। समवर्ती संस्करण प्रणाली के बाद की अगली पीढ़ी में [[अपाचे तोड़फोड़|अपाचे सर्वर]] का प्रभुत्व था,<ref>{{Citation | last1 = Collins-Sussman | first1 = Ben | last2 = Fitzpatrick | first2 = BW | last3 = Pilato | first3 = CM | title = Version Control with Subversion | publisher = O'Reilly | year = 2004 | url = https://archive.org/details/versioncontrolwi00coll | isbn = 0-596-00448-6 | url-access = registration }}</ref> [[गिट]] जैसे वितरित पुनरीक्षण नियंत्रण उपकरण के उदय के बाद इसका उदाहरण हैं।<ref>{{cite book |last1=Loeliger |first1=Jon |last2=McCullough |first2=Matthew |date=2012 |title=गिट के साथ संस्करण नियंत्रण: सहयोगी सॉफ्टवेयर विकास के लिए शक्तिशाली उपकरण और तकनीकें|url=https://www.google.com/books/edition/Version_Control_with_Git/qIucp61eqAwC |publisher=O'Reilly Media |pages=2–5 |isbn=9781449345044}}</ref> | ||
== संरचना == | == संरचना == | ||
संशोधन नियंत्रण समय के साथ डेटा के सेट में परिवर्तन का प्रबंधन करता है। इन परिवर्तनों को विभिन्न | संशोधन नियंत्रण समय के साथ डेटा के सेट में परिवर्तन का प्रबंधन करता है। इन परिवर्तनों को विभिन्न विधियों से संरचित किया जा सकता है। | ||
अधिकांशतः डेटा को कई व्यक्तिगत वस्तुओं के संग्रह के रूप में माना जाता है, जैसे फ़ाइलें या दस्तावेज़, और व्यक्तिगत फ़ाइलों में परिवर्तन ट्रैक किए जाते हैं। यह अलग-अलग फाइलों के बारे में अंतर्ज्ञान के साथ मेल खाता है लेकिन जब पहचान बदलती है, जैसे फ़ाइलों का नाम | अधिकांशतः डेटा को कई व्यक्तिगत वस्तुओं के संग्रह के रूप में माना जाता है, जैसे फ़ाइलें या दस्तावेज़, और व्यक्तिगत फ़ाइलों में परिवर्तन ट्रैक किए जाते हैं। यह अलग-अलग फाइलों के बारे में अंतर्ज्ञान के साथ मेल खाता है लेकिन जब पहचान बदलती है, जैसे फ़ाइलों का नाम परिवर्तित करने, विभाजित करने या विलय करने के समय समस्याएं पैदा होती हैं। तदनुसार, कुछ प्रणालियाँ जैसे कि गिट, इसके अतिरिक्त संपूर्ण रूप से डेटा में परिवर्तन पर विचार करती हैं, जो सरल परिवर्तनों के लिए कम सहज है लेकिन अधिक जटिल परिवर्तनों को सरल बनाता है। | ||
जब संशोधन नियंत्रण के अधीन डेटा को संशोधित किया जाता है, चेक आउट द्वारा पुनर्प्राप्त किए जाने के बाद, यह सामान्य रूप से संशोधन नियंत्रण प्रणाली (रिपॉजिटरी में) में तुरंत परिलक्षित नहीं होता है, | जब संशोधन नियंत्रण के अधीन डेटा को संशोधित किया जाता है, चेक आउट द्वारा पुनर्प्राप्त किए जाने के बाद, यह सामान्य रूप से संशोधन नियंत्रण प्रणाली (रिपॉजिटरी में) में तुरंत परिलक्षित नहीं होता है, इसके अतिरिक्त इसके अतिरिक्त चेक इन या प्रतिबद्ध होना चाहिए। संशोधन नियंत्रण के बाहर की प्रतिलिपि को कार्यशील प्रति के रूप में जाना जाता है। साधारण उदाहरण के रूप में, कंप्यूटर फ़ाइल को संपादित करते समय, संपादन प्रोग्राम द्वारा स्मृति में संग्रहीत डेटा कार्यशील प्रतिलिपि होती है, जिसे सहेज कर प्रतिबद्ध किया जाता है। विशेष रूप से, कोई दस्तावेज़ का प्रिंट आउट ले सकता है, इसे हाथ से संपादित कर सकता है, और केवल बाद में मैन्युअल रूप से कंप्यूटर में परिवर्तनों को इनपुट कर सकता है और इसे सहेज सकता है। स्रोत कोड नियंत्रण के लिए, कार्यशील प्रति इसके अतिरिक्त विशेष संशोधन में सभी फाइलों की प्रति है, जो सामान्यतः डेवलपर के कंप्यूटर पर स्थानीय रूप से संग्रहीत होती है;<ref group="note">In this case, edit buffers are a secondary form of working copy, and not referred to as such.</ref> इस स्थिति में फ़ाइल को सहेजने से केवल कार्यशील प्रति बदल जाती है, और रिपॉजिटरी में जाँच करना अलग चरण है। | ||
यदि ही डेटा सेट या दस्तावेज़ पर कई लोग काम कर रहे हैं, तो वे अंतर्निहित रूप से डेटा की शाखाएं बना रहे हैं (उनकी कार्यशील प्रतियों में), और इस प्रकार विलय के विवाद उत्पन्न होते हैं, जैसा कि नीचे चर्चा की गई है। साधारण सहयोगी दस्तावेज़ संपादन के लिए, [[फ़ाइल लॉकिंग]] का उपयोग करके या केवल उसी दस्तावेज़ पर काम करने से बचा जा सकता है जिस पर कोई और काम कर रहा है। | यदि ही डेटा सेट या दस्तावेज़ पर कई लोग काम कर रहे हैं, तो वे अंतर्निहित रूप से डेटा की शाखाएं बना रहे हैं (उनकी कार्यशील प्रतियों में), और इस प्रकार विलय के विवाद उत्पन्न होते हैं, जैसा कि नीचे चर्चा की गई है। साधारण सहयोगी दस्तावेज़ संपादन के लिए, [[फ़ाइल लॉकिंग]] का उपयोग करके या केवल उसी दस्तावेज़ पर काम करने से बचा जा सकता है जिस पर कोई और काम कर रहा है। | ||
| Line 39: | Line 37: | ||
=== ग्राफ संरचना === | === ग्राफ संरचना === | ||
[[File:Revision controlled project visualization-2010-24-02.svg|thumb|upright| | [[File:Revision controlled project visualization-2010-24-02.svg|thumb|upright|संशोधन-नियंत्रित परियोजना का उदाहरण इतिहास ग्राफ; ट्रंक हरे रंग में है, शाखाएं पीले रंग में हैं, और मर्ज (लाल तीर) की उपस्थिति के कारण ग्राफ पेड़ नहीं है।]][[ग्राफ सिद्धांत]] के संदर्भ में, संशोधनों को सामान्यतः विकास की रेखा (ट्रंक) के रूप में माना जाता है, जो शाखाओं से दूर होती है, निर्देशित वृक्ष का निर्माण करती है, जिसे विकास की या से अधिक समानांतर रेखाओं (शाखाओं की मुख्य रेखाएं) के रूप में देखा जाता है। वास्तव में यह संरचना अधिक जटिल है, निर्देशित विश्वकोश ग्राफ का निर्माण करती है, लेकिन कई उद्देश्यों के लिए मर्ज के साथ पेड़ पर्याप्त सन्निकटन है। | ||
संशोधन समय के साथ अनुक्रम में होते हैं, और इस प्रकार संशोधन संख्या या टाइमस्टैम्प द्वारा क्रम में व्यवस्थित किया जा सकता है।<ref group="note">In principle two revisions can have identical timestamp, and thus cannot be ordered on a line. This is generally the case for separate repositories, though is also possible for simultaneous changes to several branches in a single repository. In these cases, the revisions can be thought of as a set of separate lines, one per repository or branch (or branch within a repository).</ref> संशोधन पिछले संशोधनों पर आधारित होते हैं, चूंकि पुराने संशोधन को बड़े पैमाने पर या पूरी तरह से बदलना संभव है, जैसे कि सभी | संशोधन समय के साथ अनुक्रम में होते हैं, और इस प्रकार संशोधन संख्या या टाइमस्टैम्प द्वारा क्रम में व्यवस्थित किया जा सकता है।<ref group="note">In principle two revisions can have identical timestamp, and thus cannot be ordered on a line. This is generally the case for separate repositories, though is also possible for simultaneous changes to several branches in a single repository. In these cases, the revisions can be thought of as a set of separate lines, one per repository or branch (or branch within a repository).</ref> संशोधन पिछले संशोधनों पर आधारित होते हैं, चूंकि पुराने संशोधन को बड़े पैमाने पर या पूरी तरह से बदलना संभव है, जैसे कि सभी सम्मलित पाठ हटाएं जाते हैं या नया पाठ डाला जाता हैं। सबसे सरल स्थिति में, बिना किसी ब्रांचिंग या पूर्ववत के, प्रत्येक संशोधन अकेले अपने तत्काल पूर्ववर्ती पर आधारित होता है, और वे सरल रेखा बनाते हैं, जिसमें नवीनतम संस्करण, हेड संशोधन या टिप होता है। ग्राफ सिद्धांत के शब्दों में, प्रत्येक संशोधन को बिंदु के रूप में और प्रत्येक व्युत्पन्न संशोधन संबंध को तीर के रूप में चित्रित करना (पारंपरिक रूप से पुराने से नए की ओर इशारा करते हुए, समय के समान दिशा में), यह [[रेखीय ग्राफ]] है। यदि ब्रांचिंग है, तो भविष्य के कई संशोधन पिछले संशोधन पर आधारित होते हैं, या पूर्ववत होते हैं, इसलिए संशोधन अपने पूर्ववर्ती की तुलना में पुराने संशोधन पर निर्भर हो सकता है, फिर परिणामी ग्राफ [[निर्देशित पेड़]] होता है (प्रत्येक नोड में से अधिक हो सकते हैं) चाइल्ड), और इसमें कई टिप्स हैं, जो बिना चिल्ड्रन वाले संशोधनों के अनुरूप हैं (प्रत्येक शाखा पर नवीनतम संशोधन)।<ref group="note">The revision or repository "tree" should not be confused with the directory tree of files in a working copy.</ref> सिद्धांत रूप में परिणामी पेड़ को पसंदीदा टिप (मुख्य नवीनतम संशोधन) की आवश्यकता नहीं है - केवल विभिन्न विभिन्न संशोधन - लेकिन व्यवहार में टिप को सामान्यतः हेड के रूप में पहचाना जाता है। जब कोई नया संशोधन हेड पर आधारित होता है, तो उसे या तो नए हेड के रूप में पहचाना जाता है, या नई शाखा माना जाता है।<ref group="note">Note that if a new branch is based on HEAD, then topologically HEAD is no longer a tip, since it has a child.</ref> प्रारंभ से हेड तक के संशोधनों की सूची (ग्राफ़ सिद्धांत के शब्दों में, ट्री में अद्वितीय पथ, जो पहले की तरह रेखीय ग्राफ़ बनाता है) ट्रंक या मेनलाइन है।<ref group="note">"Mainline" can also refer to the main path in a separate branch.</ref> इसके विपरीत, जब संशोधन से अधिक पिछले संशोधन पर आधारित हो सकता है (जब नोड में से अधिक पैरेंट हो सकते हैं), परिणामी प्रक्रिया को मर्ज (संशोधन नियंत्रण) कहा जाता है, और यह संशोधन नियंत्रण के सबसे जटिल पहलुओं में से है। यह अधिकांशतः तब होता है जब कई शाखाओं में परिवर्तन होते हैं (अधिकांशतः दो, लेकिन अधिक संभव होते हैं), जो तब दोनों परिवर्तनों को सम्मलित करते हुए ही शाखा में विलय कर दिए जाते हैं। यदि ये परिवर्तन ओवरलैप होते हैं, तो विलय करना मुश्किल या असंभव हो सकता है, और मैन्युअल हस्तक्षेप या पुनर्लेखन की आवश्यकता होती है। | ||
विलय की उपस्थिति में, परिणामी ग्राफ़ अब पेड़ नहीं है, क्योंकि नोड्स में कई | विलय की उपस्थिति में, परिणामी ग्राफ़ अब पेड़ नहीं है, क्योंकि नोड्स में कई पैरेन्ट्स हो सकते हैं, इसके अतिरिक्त इसके अतिरिक्त रूट निर्देशित एसाइक्लिक ग्राफ (डीएजी) है। ग्राफ विश्वकोश है क्योंकि पैरेन्ट्स हमेशा समय में पीछे होते हैं, और जड़ होते हैं क्योंकि सबसे पुराना संस्करण है। मान लें कि ट्रंक है, शाखाओं से विलय को पेड़ के बाहरी रूप में माना जा सकता है - शाखा में परिवर्तन पैच के रूप में पैक किए जाते हैं, जो हेड (ट्रंक के) पर लागू होते हैं, बिना किसी स्पष्ट संदर्भ के नया संशोधन बनाते हैं शाखा, और वृक्ष संरचना को संरक्षित करना। इस प्रकार, जबकि संस्करणों के बीच वास्तविक संबंध डैग बनाते हैं, इसे ट्री प्लस मर्ज माना जा सकता है, और ट्रंक स्वयं रेखा है। | ||
वितरित संशोधन नियंत्रण में, कई रिपॉजिटरी की उपस्थिति में ये मूल संस्करण (पेड़ की जड़) पर आधारित हो सकते हैं, लेकिन मूल रूट होने की आवश्यकता नहीं है, और इस प्रकार प्रत्येक रिपॉजिटरी के लिए केवल अलग रूट (सबसे पुराना संशोधन) , उदाहरण के लिए, यदि दो लोग परियोजना पर अलग-अलग काम करना शुरू करते हैं। इसी तरह कई डेटा सेट (एकाधिक प्रोजेक्ट) की उपस्थिति में जो डेटा का आदान-प्रदान या मर्ज करते हैं, भी रूट नहीं है, चूंकि सादगी के लिए कोई प्रोजेक्ट को प्राथमिक और दूसरे को द्वितीयक के रूप में सोच सकता है, पहले के साथ या उसके बिना मर्ज किया गया | वितरित संशोधन नियंत्रण में, कई रिपॉजिटरी की उपस्थिति में ये मूल संस्करण (पेड़ की जड़) पर आधारित हो सकते हैं, लेकिन मूल रूट होने की आवश्यकता नहीं है, और इस प्रकार प्रत्येक रिपॉजिटरी के लिए केवल अलग रूट (सबसे पुराना संशोधन) , उदाहरण के लिए, यदि दो लोग परियोजना पर अलग-अलग काम करना शुरू करते हैं। इसी तरह कई डेटा सेट (एकाधिक प्रोजेक्ट) की उपस्थिति में जो डेटा का आदान-प्रदान या मर्ज करते हैं, भी रूट नहीं है, चूंकि सादगी के लिए कोई प्रोजेक्ट को प्राथमिक और दूसरे को द्वितीयक के रूप में सोच सकता है, पहले के साथ या उसके बिना मर्ज किया गया जिसका अपना संशोधन इतिहास होता हैं। | ||
== विशिष्ट रणनीतियाँ == | == विशिष्ट रणनीतियाँ == | ||
प्रारंभिक ब्लूप्रिंट या [[सफेद छाप]] के संशोधनों पर नज़र रखने के आधार पर औपचारिक प्रक्रियाओं से विकसित अभियांत्रिकी संशोधन नियंत्रण{{Citation needed|reason=The rest of this paragraph is fairly specific; it sounds almost like it should've been part of an elder engineering book, any sources?|date=December 2017}}. नियंत्रण की इस प्रणाली ने स्पष्ट रूप से डिजाइन के पहले की स्थिति में लौटने की अनुमति दी, ऐसे स्थितियों के लिए जिनमें डिजाइन के विकास में अभियांत्रिकी डेड-एंड पहुंच गया था। किए गए परिवर्तनों का ट्रैक रखने के लिए पुनरीक्षण तालिका का उपयोग किया गया था। इसके अतिरिक्त, ड्राइंग के संशोधित क्षेत्रों को पुनरीक्षण बादलों का उपयोग करके प्रदर्शित किया गया था। | |||
संस्करण नियंत्रण व्यापार और कानून में व्यापक है। दरअसल, अनुबंध रेडलाइन और कानूनी ब्लैकलाइन संशोधन नियंत्रण के प्रारंभिक रूपों में से कुछ हैं,<ref>For Engineering drawings, see [[Whiteprint#Document control]], for some of the manual systems in place in the twentieth century, for example, the ''Engineering Procedures'' of [[Hughes Aircraft]], each revision of which required approval by [[Lawrence A. Hyland]]; see also the approval procedures instituted by the U.S. government.</ref> और अभी भी अलग-अलग डिग्री के परिष्कार के साथ व्यापार और कानून में कार्यरत हैं। पारंपरिक पुनरीक्षण नियंत्रण के मैनुअल इलेक्ट्रॉनिक कार्यान्वयन को प्रतिस्थापित करते हुए, [[सीएडी फ़ाइल]]ों में परिवर्तनों की इलेक्ट्रॉनिक ट्रैकिंग ([[उत्पाद डेटा प्रबंधन]] देखें) के लिए सबसे परिष्कृत तकनीकों का उपयोग किया जाने लगा है।{{citation needed|date=November 2016}} | |||
== स्रोत-प्रबंधन मॉडल == | == स्रोत-प्रबंधन मॉडल == | ||
पारंपरिक पुनरीक्षण नियंत्रण प्रणालियाँ केंद्रीकृत मॉडल का उपयोग करती हैं जहाँ सभी पुनरीक्षण नियंत्रण कार्य साझा [[सर्वर (कंप्यूटिंग)]] पर होते हैं। यदि दो डेवलपर ही फ़ाइल को ही समय में बदलने का प्रयास करते हैं, तो एक्सेस प्रबंधन के किसी तरीके के बिना डेवलपर एक-दूसरे के काम को ओवरराइट कर सकते हैं। केंद्रीकृत पुनरीक्षण नियंत्रण प्रणाली इस समस्या को दो अलग-अलग स्रोत प्रबंधन मॉडल में से में हल करती है: फ़ाइल लॉकिंग और वर्जन मर्जिंग। | पारंपरिक पुनरीक्षण नियंत्रण प्रणालियाँ केंद्रीकृत मॉडल का उपयोग करती हैं जहाँ सभी पुनरीक्षण नियंत्रण कार्य साझा [[सर्वर (कंप्यूटिंग)]] पर होते हैं। यदि दो डेवलपर ही फ़ाइल को ही समय में बदलने का प्रयास करते हैं, तो एक्सेस प्रबंधन के किसी तरीके के बिना डेवलपर एक-दूसरे के काम को ओवरराइट कर सकते हैं। केंद्रीकृत पुनरीक्षण नियंत्रण प्रणाली इस समस्या को दो अलग-अलग स्रोत प्रबंधन मॉडल में से में हल करती है: फ़ाइल लॉकिंग और वर्जन मर्जिंग। | ||
| Line 58: | Line 54: | ||
=== परमाणु संचालन === | === परमाणु संचालन === | ||
{{Main|परमाणु प्रतिबद्ध}} | {{Main|परमाणु प्रतिबद्ध}} | ||
एक ऑपरेशन परमाणु है यदि ऑपरेशन बाधित होने पर भी | एक ऑपरेशन परमाणु है यदि ऑपरेशन बाधित होने पर भी प्रणाली को सुसंगत स्थिति में छोड़ दिया जाता है। प्रतिबद्ध ऑपरेशन सामान्यतः इस अर्थ में सबसे महत्वपूर्ण है। कमिट संशोधन नियंत्रण प्रणाली को परिवर्तनों के समूह को अंतिम रूप देने और सभी उपयोगकर्ताओं के लिए उपलब्ध कराने के लिए कहते हैं। सभी पुनरीक्षण नियंत्रण प्रणालियों में परमाणु कार्य नहीं होते हैं; समवर्ती संस्करण प्रणाली में इस सुविधा का अभाव है।<ref>{{cite book |last1=Smart |first1=John Ferguson |title=जावा पावर टूल्स|date=2008 |publisher="O'Reilly Media, Inc." |isbn=9781491954546 |page=301 |url=https://books.google.com/books?id=YoTvBpKEx5EC&q=cvs+doesn%27t+support+atomic+commit&pg=PA301 |access-date=20 July 2019 |language=en}}</ref> | ||
=== फ़ाइल लॉकिंग === | === फ़ाइल लॉकिंग === | ||
समवर्ती पहुंच समस्याओं को रोकने की सबसे सरल विधि में फ़ाइल लॉकिंग सम्मलित है जिससे कि समय में केवल डेवलपर के पास उन फ़ाइलों की केंद्रीय रिपॉजिटरी (संस्करण नियंत्रण) प्रतियों तक पहुंच हो। | समवर्ती पहुंच समस्याओं को रोकने की सबसे सरल विधि में फ़ाइल लॉकिंग सम्मलित है जिससे कि समय में केवल डेवलपर के पास उन फ़ाइलों की केंद्रीय रिपॉजिटरी (संस्करण नियंत्रण) प्रतियों तक पहुंच हो। इस प्रकार जब डेवलपर किसी फ़ाइल की जाँच कर लेता है, तो अन्य उस फ़ाइल को पढ़ सकते हैं, लेकिन कोई भी अन्य उस फ़ाइल को तब तक नहीं बदल सकता जब तक कि वह डेवलपर अद्यतन संस्करण में जाँच नहीं करता (या चेकआउट को रद्द कर देता है)। | ||
फाइल लॉकिंग में | फाइल लॉकिंग में लाभ और हानियाँ दोनों हैं। जब कोई उपयोगकर्ता किसी बड़ी फ़ाइल (या फ़ाइलों के समूह) के कई अनुभागों में आमूल-चूल परिवर्तन कर रहा हो, तो यह कठिन मर्ज विरोधों से कुछ सुरक्षा प्रदान कर सकता है। यदि फ़ाइलों को बहुत लंबे समय के लिए विशेष रूप से लॉक छोड़ दिया जाता है, तो अन्य डेवलपर्स संशोधन नियंत्रण सॉफ़्टवेयर को बायपास करने और फ़ाइलों को स्थानीय रूप से बदलने के लिए लुभा सकते हैं, जब अन्य परिवर्तनों को अंततः चेक इन किया जाता है, तो कठिन मैन्युअल मर्ज को मजबूर किया जा सकता है। बड़े संगठन में, फ़ाइलें हो सकती हैं चेक आउट छोड़ दिया और लॉक कर दिया और भूल गए क्योंकि डेवलपर्स परियोजनाओं के बीच चलते हैं - ये टूल यह देखना सरल बना सकते हैं या नहीं कर सकते हैं कि किसके पास फ़ाइल चेक आउट हो गई है। | ||
=== संस्करण विलय === | === संस्करण विलय === | ||
{{Main|विलय (संस्करण नियंत्रण)}} | {{Main|विलय (संस्करण नियंत्रण)}} | ||
अधिकांश संस्करण नियंत्रण प्रणाली ही समय में कई डेवलपर्स को ही फाइल को संपादित करने की अनुमति देती हैं। केंद्रीय रिपॉजिटरी में परिवर्तनों की जांच करने वाला पहला डेवलपर हमेशा सफल होता है। | अधिकांश संस्करण नियंत्रण प्रणाली ही समय में कई डेवलपर्स को ही फाइल को संपादित करने की अनुमति देती हैं। केंद्रीय रिपॉजिटरी में परिवर्तनों की जांच करने वाला पहला डेवलपर हमेशा सफल होता है। प्रणाली केंद्रीय रिपॉजिटरी में आगे के परिवर्तनों को मर्ज (संशोधन नियंत्रण) करने की सुविधा प्रदान कर सकता है, और जब अन्य डेवलपर चेक इन करते हैं तो पहले डेवलपर से परिवर्तनों को संरक्षित कर सकते हैं। | ||
दो फाइलों को मर्ज करना बहुत ही नाजुक ऑपरेशन हो सकता है, और सामान्यतः केवल तभी संभव होता है जब डेटा संरचना सरल हो, जैसा कि [[पाठ फ़ाइल]]ों में होता है। दो [[छवि फ़ाइल]]ों के विलय का परिणाम छवि फ़ाइल में बिल्कुल भी नहीं हो सकता है। कोड में जाँच करने वाले दूसरे डेवलपर को यह सुनिश्चित करने के लिए मर्ज की देखभाल करने की आवश्यकता होगी कि परिवर्तन संगत हैं और यह कि मर्ज ऑपरेशन फ़ाइलों के भीतर अपनी [[तर्क]] त्रुटियों का परिचय नहीं देता है। ये समस्याएँ स्वचालित या अर्ध-स्वचालित मर्ज संचालन की उपलब्धता को मुख्य रूप से सरल पाठ-आधारित दस्तावेज़ों तक सीमित करती हैं, जब तक कि फ़ाइल प्रकारों के लिए कोई विशिष्ट मर्ज [[प्लग-इन (कंप्यूटिंग)]] उपलब्ध न हो। | दो फाइलों को मर्ज करना बहुत ही नाजुक ऑपरेशन हो सकता है, और सामान्यतः केवल तभी संभव होता है जब डेटा संरचना सरल हो, जैसा कि [[पाठ फ़ाइल]]ों में होता है। दो [[छवि फ़ाइल]]ों के विलय का परिणाम छवि फ़ाइल में बिल्कुल भी नहीं हो सकता है। कोड में जाँच करने वाले दूसरे डेवलपर को यह सुनिश्चित करने के लिए मर्ज की देखभाल करने की आवश्यकता होगी कि परिवर्तन संगत हैं और यह कि मर्ज ऑपरेशन फ़ाइलों के भीतर अपनी [[तर्क]] त्रुटियों का परिचय नहीं देता है। ये समस्याएँ स्वचालित या अर्ध-स्वचालित मर्ज संचालन की उपलब्धता को मुख्य रूप से सरल पाठ-आधारित दस्तावेज़ों तक सीमित करती हैं, जब तक कि फ़ाइल प्रकारों के लिए कोई विशिष्ट मर्ज [[प्लग-इन (कंप्यूटिंग)]] उपलब्ध न हो। | ||
आरक्षित संपादन की अवधारणा अनन्य लेखन पहुंच के लिए फ़ाइल को स्पष्ट रूप से लॉक करने का वैकल्पिक साधन प्रदान कर सकती है, तब भी जब मर्जिंग क्षमता सम्मलित हो। | |||
===बेसलाइन, लेबल और टैग=== | ===बेसलाइन, लेबल और टैग=== | ||
| Line 79: | Line 73: | ||
अधिकांश परियोजनाओं में, कुछ स्नैपशॉट दूसरों की तुलना में अधिक महत्वपूर्ण होते हैं, जैसे कि प्रकाशित रिलीज़, शाखाओं या मील के पत्थर को इंगित करने के लिए उपयोग किया जाता है। | अधिकांश परियोजनाओं में, कुछ स्नैपशॉट दूसरों की तुलना में अधिक महत्वपूर्ण होते हैं, जैसे कि प्रकाशित रिलीज़, शाखाओं या मील के पत्थर को इंगित करने के लिए उपयोग किया जाता है। | ||
जब ही संदर्भ में आधार रेखा और लेबल या टैग दोनों का साथ उपयोग किया जाता है, तो लेबल और टैग सामान्यतः स्नैपशॉट के रिकॉर्ड को पहचानने या बनाने के उपकरण के भीतर तंत्र को संदर्भित करते हैं, और आधार रेखा किसी दिए गए लेबल के बढ़ते महत्व को इंगित करती है। | जब ही संदर्भ में आधार रेखा और लेबल या टैग दोनों का साथ उपयोग किया जाता है, तो लेबल और टैग सामान्यतः स्नैपशॉट के रिकॉर्ड को पहचानने या बनाने के उपकरण के भीतर तंत्र को संदर्भित करते हैं, और आधार रेखा किसी दिए गए लेबल के बढ़ते महत्व या टैग को इंगित करती है। | ||
कॉन्फ़िगरेशन प्रबंधन की सबसे औपचारिक चर्चा बेसलाइन (कॉन्फ़िगरेशन प्रबंधन) शब्द का उपयोग करती है। | कॉन्फ़िगरेशन प्रबंधन की सबसे औपचारिक चर्चा बेसलाइन (कॉन्फ़िगरेशन प्रबंधन) शब्द का उपयोग करती है। | ||
| Line 85: | Line 79: | ||
== वितरित संशोधन नियंत्रण == | == वितरित संशोधन नियंत्रण == | ||
{{Main|वितरित संस्करण नियंत्रण}} | {{Main|वितरित संस्करण नियंत्रण}} | ||
वितरित पुनरीक्षण नियंत्रण प्रणाली (DRCS) केंद्रीकृत प्रणालियों के क्लाइंट-सर्वर मॉडल|क्लाइंट-सर्वर दृष्टिकोण के विपरीत सहकर्मी से सहकर्मी दृष्टिकोण लेती है। एकल, केंद्रीय रिपॉजिटरी के अतिरिक्त जिस पर क्लाइंट सिंक्रोनाइज़ करते हैं, कोडबेस की प्रत्येक सहकर्मी की कार्यशील प्रति अच्छा विश्वास है। | वितरित पुनरीक्षण नियंत्रण प्रणाली (DRCS) केंद्रीकृत प्रणालियों के क्लाइंट-सर्वर मॉडल|क्लाइंट-सर्वर दृष्टिकोण के विपरीत सहकर्मी से सहकर्मी दृष्टिकोण लेती है। एकल, केंद्रीय रिपॉजिटरी के अतिरिक्त जिस पर क्लाइंट सिंक्रोनाइज़ करते हैं, कोडबेस की प्रत्येक सहकर्मी की कार्यशील प्रति प्रामाणिक रिपॉजिटरी के लिए अच्छा विश्वास प्रदर्शित करती है।<ref>{{cite web | ||
| last = Wheeler | | last = Wheeler | ||
| first = David | | first = David | ||
| Line 93: | Line 87: | ||
| archive-url = https://web.archive.org/web/20201109022758/http://www.dwheeler.com/essays/scm.html | | archive-url = https://web.archive.org/web/20201109022758/http://www.dwheeler.com/essays/scm.html | ||
| url-status = dead | | url-status = dead | ||
}}</ref> | }}</ref> वितरित पुनरीक्षण नियंत्रण सहकर्मी से सहकर्मी [[पैच (यूनिक्स)]] (परिवर्तन-सेट) का आदान-प्रदान करके सिंक्रनाइज़ेशन आयोजित करता है। यह केंद्रीकृत प्रणाली से कुछ महत्वपूर्ण अंतरों का परिणाम है: | ||
वितरित पुनरीक्षण नियंत्रण सहकर्मी से सहकर्मी [[पैच (यूनिक्स)]] (परिवर्तन-सेट) का आदान-प्रदान करके सिंक्रनाइज़ेशन आयोजित करता है। यह केंद्रीकृत प्रणाली से कुछ महत्वपूर्ण अंतरों का परिणाम है: | * कोडबेस की कोई विहित, संदर्भ प्रति डिफ़ॉल्ट रूप से केवल कार्यशील प्रतियाँ सम्मलित नहीं है। | ||
* कोडबेस की कोई विहित, संदर्भ प्रति डिफ़ॉल्ट रूप से सम्मलित नहीं | |||
* सामान्य ऑपरेशन (जैसे कि कमिट करना, इतिहास देखना और परिवर्तनों को वापस करना) तेज हैं, क्योंकि केंद्रीय सर्वर के साथ संवाद करने की कोई आवश्यकता नहीं है।<ref name=Mercurial/>{{rp|7}} | * सामान्य ऑपरेशन (जैसे कि कमिट करना, इतिहास देखना और परिवर्तनों को वापस करना) तेज हैं, क्योंकि केंद्रीय सर्वर के साथ संवाद करने की कोई आवश्यकता नहीं है।<ref name=Mercurial/>{{rp|7}} | ||
इसके अतिरिक्त, संचार केवल तभी आवश्यक होता है जब परिवर्तन को अन्य साथियों से या उनके पास धकेला या खींचा जाता है। | |||
* प्रत्येक कार्यशील प्रति प्रभावी रूप से कोडबेस और उसके परिवर्तन-इतिहास के दूरस्थ बैकअप के रूप में कार्य करती है, जो डेटा हानि के खिलाफ अंतर्निहित सुरक्षा प्रदान करती है।<ref name=Mercurial/>{{rp|4}} | * प्रत्येक कार्यशील प्रति प्रभावी रूप से कोडबेस और उसके परिवर्तन-इतिहास के दूरस्थ बैकअप के रूप में कार्य करती है, जो डेटा हानि के खिलाफ अंतर्निहित सुरक्षा प्रदान करती है।<ref name=Mercurial/>{{rp|4}} | ||
== सर्वोत्तम अभ्यास == | == सर्वोत्तम अभ्यास == | ||
संस्करण नियंत्रण का पूर्ण लाभ प्राप्त करने के लिए सर्वोत्तम अभ्यासों का पालन करना आवश्यक है। सर्वोत्तम अभ्यास संस्करण नियंत्रण उपकरण और उस क्षेत्र के अनुसार भिन्न हो सकते हैं जिस पर संस्करण नियंत्रण लागू किया जाता है। सॉफ्टवेयर विकास में सामान्यतः स्वीकृत सर्वोत्तम प्रथाओं में सम्मलित हैं: वृद्धिशील, छोटे, परिवर्तन करना; कमिट करना जिसमें केवल कार्य या फिक्स सम्मलित है - इसका परिणाम केवल कोड को कमिट करना है जो काम करता है और जानबूझकर सम्मलिता कार्यक्षमता को नहीं तोड़ता है; रिलीज से पहले कार्यक्षमता को पूरा करने के लिए ब्रांचिंग का उपयोग करना; स्पष्ट और वर्णनात्मक प्रतिबद्ध संदेश लिखना, वर्णन या कोड में क्या और कैसे स्पष्ट करें; और सुसंगत ब्रांचिंग रणनीति का उपयोग | संस्करण नियंत्रण का पूर्ण लाभ प्राप्त करने के लिए सर्वोत्तम अभ्यासों का पालन करना आवश्यक है। सर्वोत्तम अभ्यास संस्करण नियंत्रण उपकरण और उस क्षेत्र के अनुसार भिन्न हो सकते हैं जिस पर संस्करण नियंत्रण लागू किया जाता है। सॉफ्टवेयर विकास में सामान्यतः स्वीकृत सर्वोत्तम प्रथाओं में सम्मलित हैं: वृद्धिशील, छोटे, परिवर्तन करना; कमिट करना जिसमें केवल कार्य या फिक्स सम्मलित है - इसका परिणाम केवल कोड को कमिट करना है जो काम करता है और जानबूझकर सम्मलिता कार्यक्षमता को नहीं तोड़ता है; रिलीज से पहले कार्यक्षमता को पूरा करने के लिए ब्रांचिंग का उपयोग करना; स्पष्ट और वर्णनात्मक प्रतिबद्ध संदेश लिखना, वर्णन या कोड में क्या और कैसे स्पष्ट करें; और सुसंगत ब्रांचिंग रणनीति का उपयोग करना सम्मलित हैं।<ref>{{cite web |url=https://about.gitlab.com/topics/version-control/version-control-best-practices/ |title=गिट संस्करण नियंत्रण सर्वोत्तम अभ्यास क्या हैं?|author=GitLab |website=gitlab.com |access-date=2022-11-11}}</ref> अन्य सर्वोत्तम सॉफ़्टवेयर विकास अभ्यास जैसे कोड समीक्षा और स्वचालित [[प्रतिगमन परीक्षण]] संस्करण नियंत्रण सर्वोत्तम प्रथाओं के अनुसरण में सहायता कर सकते हैं। | ||
== लागत और लाभ == | == लागत और लाभ == | ||
| Line 109: | Line 100: | ||
संस्करण नियंत्रण सॉफ़्टवेयर को लाइसेंस देने की लागत के अतिरिक्त, संस्करण नियंत्रण का उपयोग करने के लिए समय और प्रयास की आवश्यकता होती है। संस्करण नियंत्रण में अंतर्निहित अवधारणाओं को समझा जाना चाहिए और चुने गए संस्करण नियंत्रण सॉफ़्टवेयर को संचालित करने के लिए आवश्यक तकनीकी विवरणों को सीखना चाहिए। संस्करण नियंत्रण सर्वोत्तम प्रथाओं को सीखा जाना चाहिए और संगठन के सम्मलिता सॉफ़्टवेयर विकास प्रथाओं में एकीकृत किया जाना चाहिए। उपयोगी लाभ प्राप्त करने के लिए सर्वोत्तम प्रथाओं का पालन करने के लिए आवश्यक अनुशासन बनाए रखने के लिए प्रबंधन प्रयास की आवश्यकता हो सकती है। | संस्करण नियंत्रण सॉफ़्टवेयर को लाइसेंस देने की लागत के अतिरिक्त, संस्करण नियंत्रण का उपयोग करने के लिए समय और प्रयास की आवश्यकता होती है। संस्करण नियंत्रण में अंतर्निहित अवधारणाओं को समझा जाना चाहिए और चुने गए संस्करण नियंत्रण सॉफ़्टवेयर को संचालित करने के लिए आवश्यक तकनीकी विवरणों को सीखना चाहिए। संस्करण नियंत्रण सर्वोत्तम प्रथाओं को सीखा जाना चाहिए और संगठन के सम्मलिता सॉफ़्टवेयर विकास प्रथाओं में एकीकृत किया जाना चाहिए। उपयोगी लाभ प्राप्त करने के लिए सर्वोत्तम प्रथाओं का पालन करने के लिए आवश्यक अनुशासन बनाए रखने के लिए प्रबंधन प्रयास की आवश्यकता हो सकती है। | ||
एक मुख्य लाभ इतिहास को बनाए रखने और परिवर्तनों को वापस लाने की क्षमता है, जिससे डेवलपर परिवर्तनों को | एक मुख्य लाभ इतिहास को बनाए रखने और परिवर्तनों को वापस लाने की क्षमता है, जिससे डेवलपर परिवर्तनों को सरलता से पूर्ववत कर सकता है। यह डेवलपर को प्रयोग करने का अधिक अवसर देता है, जिससे सम्मलिता कोड को तोड़ने का डर समाप्त हो जाता है।<ref>{{cite web |url=https://www.claytex.com/tech-blog/the-cost-of-not-using-version-control/ |author=Alessandro Picarelli |title=संस्करण नियंत्रण का उपयोग नहीं करने की लागत|date=2020-11-17 | access-date=2022-11-18 |quote=कार्य घंटों के संदर्भ में यह आपको 6 से 48 गुना अधिक खर्च करने वाला है, जो कि संस्करण नियंत्रण का उपयोग करने में आपकी लागत होगी, और यह एक एकल डेवलपर के लिए कुछ मॉडलों को रिवाइंड करने के लिए है।}}</ref> ब्रांचिंग के साथ सहायता करता है। सोर्स कोड [[पैच (कंप्यूटिंग)]] का ब्रांचिंग और विलय, उत्पादन, पैकेजिंग और लेबलिंग और कोड बेस के लिए पैच का सरल अनुप्रयोग, परिनियोजन प्रक्रिया के विभिन्न चरणों से जुड़े कई कोड बेस के रखरखाव और समवर्ती विकास को सरल करता है; विकास, परीक्षण, मंचन, उत्पादन, आदि।<ref>{{cite web |url=https://www.seguetech.com/a-review-of-software-version-control-systems-benefits-and-why-it-matters/ |title=सॉफ़्टवेयर संस्करण नियंत्रण की समीक्षा: सिस्टम, लाभ, और यह क्यों मायने रखता है|author=Irma Azarian |date=2023-06-14 |access-date=2022-11-18 |quote=संस्करण नियंत्रण प्रणाली आपको फ़ाइलों की तुलना करने, अंतरों की पहचान करने और किसी भी कोड को जमा करने से पहले यदि आवश्यक हो तो परिवर्तनों को मर्ज करने की अनुमति देती है। वर्ज़निंग भी एप्लिकेशन बिल्ड का ट्रैक रखने का एक शानदार तरीका है, यह पहचानने में सक्षम है कि वर्तमान में कौन सा संस्करण विकास, क्यूए और उत्पादन में है।}}</ref> क्षति न्यूनीकरण, जवाबदेही, प्रक्रिया और डिजाइन में सुधार, और संस्करण नियंत्रण द्वारा प्रदान किए गए रिकॉर्ड रखने से जुड़े अन्य लाभ हो सकते हैं, किसने, कब, क्यों और कैसे किया, इसकी ट्रैकिंग।<ref>{{cite web |url=https://reqtest.com/requirements-blog/what-are-benefits-of-version-control/ |author=ReQtest |title=संस्करण नियंत्रण के क्या लाभ हैं?|date=2020-10-26 | access-date=2022-11-21 |quote=दस्तावेज़ का इतिहास लेखक और संपादन की तारीख के बारे में अमूल्य जानकारी प्रदान करता है। यह किए गए परिवर्तनों के उद्देश्य पर भी देता है। इसका नवीनतम संस्करण पर काम करने वाले डेवलपर पर प्रभाव पड़ेगा क्योंकि यह पिछले संस्करणों में अनुभव की गई समस्याओं को हल करने में मदद करेगा। दस्तावेज़ के लेखक की पहचान करने की क्षमता वर्तमान टीम को दस्तावेज़ों को विशिष्ट योगदानकर्ताओं से लिंक करने में सक्षम बनाती है। बदले में, यह वर्तमान टीम को उन पैटर्नों को उजागर करने में सक्षम बनाता है जो बग्स को ठीक करने में मदद कर सकते हैं। यह सॉफ़्टवेयर की समग्र कार्यप्रणाली को बेहतर बनाने में मदद करेगा।}}</ref> यह अच्छी पुनर्मूल्यांकन की अनुमति देता है कि आगे बढ़ने वाली समस्याओं और समाधानों को संबोधित करने के लिए परिवर्तन क्यों किए गए थे।<ref>{{cite web |url=https://towardsdatascience.com/version-control-101-definition-and-benefits-6fd7ad49e5f1?gi=8f0ff1f61153 |author=Sara A. Metwalli |title=संस्करण नियंत्रण 101: परिभाषा और लाभ| date=2020-10-14 |access-date=2022-11-18 |quote=इसके अलावा, यदि समय के साथ, किसी विशेष सुविधा को जोड़ने से परियोजना का विस्तार या विस्तार करने में कठिनाई होती है, तो संस्करण नियंत्रण का उपयोग करने से डेवलपर उस विशेष सुविधा को ट्रैक कर सकते हैं और परियोजना की कार्यक्षमता को प्रभावित किए बिना इसे बदल सकते हैं या हटा सकते हैं।}}</ref > जब बग उत्पन्न होते हैं, तो यह जानना कि क्या किया गया था जब क्षति न्यूनीकरण और पुनर्प्राप्ति में मदद करता है कि क्या समस्याएँ सम्मलित हैं, वे कितने समय से सम्मलित हैं, और समस्या का दायरा और समाधान निर्धारित करने में सहायता करते हैं।<ref>{{cite web |url=https://www.spiceworks.com/tech/devops/articles/what-is-version-control/ |author=Chiradeep BasuMallick |title=संस्करण नियंत्रण क्या है? अर्थ, उपकरण और लाभ|date=2022-10-06 |access-date=2022-11-18 |quote=सॉफ़्टवेयर टीमें कोड समीक्षाओं के माध्यम से पिछले संस्करणों की जांच करके समाधान के विकास को समझ सकती हैं।}}</ref> पिछले संस्करणों को स्थापित किया जा सकता है और कोड की परीक्षा और संदेशों को प्रतिबद्ध करने के निष्कर्षों को सत्यापित करने के लिए परीक्षण किया जा सकता है।<ref>{{cite web |url=https://www.spiceworks.com/tech/devops/articles/what-is-version-control/ |author=Chiradeep BasuMallick |title=संस्करण नियंत्रण क्या है? अर्थ, उपकरण और लाभ|date=2022-10-06 |access-date=2022-11-18 |quote=यदि कोई त्रुटि हो जाती है, तो डेवलपर समय पर वापस जा सकते हैं और टीम के सभी सदस्यों के लिए गड़बड़ी को कम करते हुए गलती को दूर करने के लिए कोड के पूर्व पुनरावृत्तियों की समीक्षा कर सकते हैं।}}</ref> संस्करण नियंत्रण डिबगिंग को बहुत सरल बना सकता है। कई संस्करणों के लिए परीक्षण स्थिति का अनुप्रयोग उस परिवर्तन की शीघ्रता से पहचान कर सकता है जिसने बग प्रदर्शिक किया था।<ref>{{cite web |url=https://git-scm.com/book/en/v2/Appendix-C%3A-Git-Commands-Debugging |first=Scott |last=Chacon |first2=Ben |last2=Straub |publisher=Apress |edition=Version 2.1.395-2-g27002dd |title=गिट के लिए| date=2022-10-03 |access-date=2022-11-18 |quote=गिट बिसेक्ट टूल एक अविश्वसनीय रूप से सहायक डिबगिंग टूल है जिसका उपयोग यह पता लगाने के लिए किया जाता है कि स्वचालित बाइनरी खोज करके बग या समस्या को पेश करने वाला पहला कौन सा विशिष्ट कमिट था।}}</ref> डेवलपर को संपूर्ण कोड आधार से परिचित होने की आवश्यकता नहीं है और इसके अतिरिक्त समस्या को प्रस्तुत करने वाले कोड पर ध्यान केंद्रित कर सकता है। | ||
ब्रांचिंग | |||
क्षति न्यूनीकरण, जवाबदेही, प्रक्रिया और डिजाइन में सुधार, और संस्करण नियंत्रण द्वारा प्रदान किए गए रिकॉर्ड रखने से जुड़े अन्य लाभ हो सकते हैं, किसने, कब, क्यों और कैसे किया, इसकी ट्रैकिंग।<ref>{{cite web |url=https://reqtest.com/requirements-blog/what-are-benefits-of-version-control/ |author=ReQtest |title=संस्करण नियंत्रण के क्या लाभ हैं?|date=2020-10-26 | access-date=2022-11-21 |quote=दस्तावेज़ का इतिहास लेखक और संपादन की तारीख के बारे में अमूल्य जानकारी प्रदान करता है। यह किए गए परिवर्तनों के उद्देश्य पर भी देता है। इसका नवीनतम संस्करण पर काम करने वाले डेवलपर पर प्रभाव पड़ेगा क्योंकि यह पिछले संस्करणों में अनुभव की गई समस्याओं को हल करने में मदद करेगा। दस्तावेज़ के लेखक की पहचान करने की क्षमता वर्तमान टीम को दस्तावेज़ों को विशिष्ट योगदानकर्ताओं से लिंक करने में सक्षम बनाती है। बदले में, यह वर्तमान टीम को उन पैटर्नों को उजागर करने में सक्षम बनाता है जो बग्स को ठीक करने में मदद कर सकते हैं। यह सॉफ़्टवेयर की समग्र कार्यप्रणाली को बेहतर बनाने में मदद करेगा।}}</ref> यह | |||
संस्करण नियंत्रण कई | संस्करण नियंत्रण कई विधियों से सहयोग को बढ़ाता है। चूंकि संस्करण नियंत्रण परस्पर विरोधी परिवर्तनों की पहचान कर सकता है, अर्थात कोड की समान पंक्तियों में किए गए असंगत परिवर्तन, डेवलपर्स के बीच समन्वय की कम आवश्यकता होती है।<ref>{{cite web |url=https://www.seguetech.com/a-review-of-software-version-control-systems-benefits-and-why-it-matters/ |title=सॉफ़्टवेयर संस्करण नियंत्रण की समीक्षा: सिस्टम, लाभ, और यह क्यों मायने रखता है|author=Irma Azarian |date=2023-06-14 |access-date=2022-11-18 |quote=वर्जनिंग एक अनमोल प्रक्रिया है, खासकर तब जब आपके पास एक ही एप्लिकेशन पर कई डेवलपर काम कर रहे हों, क्योंकि यह उन्हें आसानी से फाइल साझा करने की अनुमति देता है। संस्करण नियंत्रण के बिना, डेवलपर्स अंततः एक दूसरे के पैर की उंगलियों पर कदम रखेंगे और कोड परिवर्तनों को अधिलेखित कर देंगे जो किसी और ने इसे साकार किए बिना भी पूरा किया हो। इन प्रणालियों का उपयोग करने से आप संशोधनों के लिए फ़ाइलों की जांच कर सकते हैं, फिर, चेक-इन के दौरान, यदि फ़ाइलें किसी अन्य उपयोगकर्ता द्वारा बदली गई हैं, तो आपको सतर्क किया जाएगा और उन्हें मर्ज करने की अनुमति दी जाएगी।}}</ref> कमिट्स, शाखाओं, और सभी संबद्ध प्रतिबद्ध संदेशों और संस्करण लेबलों की पैकेजिंग, डेवलपर्स के बीच पल और समय दोनों में संचार में सुधार करती है।<ref>{{cite web |url=https://dev.to/jessekphillips/git-is-a-communication-tool--2j9k |author=Jesse Phillips |title=गिट एक संचार उपकरण है|date=2019-01-21 |orig-date=2018-12-12 |access-date=2022-11-18 |quote=रीबेस, मर्ज, और/या स्क्वैश का उपयोग करने पर चर्चा जारी है। मैं संचार करते हुए इन सभी विकल्पों के बिंदु पर ध्यान केंद्रित करना चाहता हूं।}}</ref> बेहतर संचार, चाहे तत्काल हो या स्थगित, कोड समीक्षा प्रक्रिया, परीक्षण प्रक्रिया और सॉफ्टवेयर विकास प्रक्रिया के अन्य महत्वपूर्ण पहलुओं में सुधार कर सकता है। | ||
== एकीकरण == | == एकीकरण == | ||
कुछ अधिक उन्नत पुनरीक्षण-नियंत्रण उपकरण कई अन्य सुविधाएं प्रदान करते हैं, जिससे अन्य उपकरणों और सॉफ्टवेयर-अभियांत्रिकी प्रक्रियाओं के साथ गहन एकीकरण की अनुमति मिलती है। प्लग-इन (कंप्यूटिंग) अधिकांशतः [[Oracle JDeveloper]], [[IntelliJ IDEA]], एक्लिप्स (कंप्यूटिंग), [[विजुअल स्टूडियो]], [[डेल्फी (प्रोग्रामिंग भाषा)]], [[NetBeans]], [[Xcode]], और [[GNU Emacs]] (vc.el के माध्यम से) जैसे एकीकृत विकास परिवेश के लिए उपलब्ध हैं। उन्नत अनुसंधान प्रोटोटाइप उपयुक्त प्रतिबद्ध संदेश उत्पन्न करते हैं,<ref>{{Cite book |last1=Cortes-Coy|first1=Luis Fernando|last2=Linares-Vasquez|first2=Mario|last3=Aponte|first3=Jairo|last4=Poshyvanyk|first4=Denys|title=स्रोत कोड विश्लेषण और हेरफेर पर 2014 IEEE 14वां अंतर्राष्ट्रीय कार्य सम्मेलन|chapter=On Automatically Generating Commit Messages via Summarization of Source Code Changes|date=2014 |pages=275–284|publisher=IEEE|doi=10.1109/scam.2014.14|isbn=978-1-4799-6148-1|s2cid=360545}}</ref> लेकिन यह केवल उन परियोजनाओं पर काम करता है जिनका पहले से ही बड़ा इतिहास है, क्योंकि प्रतिबद्ध संदेश परियोजना के सम्मेलनों और विशिष्टताओं पर बहुत निर्भर हैं।<ref>{{Cite book|last1=Etemadi|first1=Khashayar|last2=Monperrus|first2=Martin|title=सॉफ्टवेयर इंजीनियरिंग कार्यशालाओं पर IEEE/ACM 42वें अंतर्राष्ट्रीय सम्मेलन की कार्यवाही|chapter=On the Relevance of Cross-project Learning with Nearest Neighbours for Commit Message Generation|date=2020-06-27 |language=en|location=Seoul, Republic of Korea|publisher=ACM|pages=470–475|doi=10.1145/3387940.3391488|arxiv=2010.01924|isbn=9781450379632|s2cid=221911386}}</ref> | कुछ अधिक उन्नत पुनरीक्षण-नियंत्रण उपकरण कई अन्य सुविधाएं प्रदान करते हैं, जिससे अन्य उपकरणों और सॉफ्टवेयर-अभियांत्रिकी प्रक्रियाओं के साथ गहन एकीकरण की अनुमति मिलती है। प्लग-इन (कंप्यूटिंग) अधिकांशतः [[Oracle JDeveloper|औरेकल जेडेवलपर्स (Oracle JDevelopers)]], [[IntelliJ IDEA|इंटेल आईजे आइडिया (IntelliJ IDEA)]], एक्लिप्स (कंप्यूटिंग), [[विजुअल स्टूडियो]], [[डेल्फी (प्रोग्रामिंग भाषा)]], [[NetBeans|नेट बीन्स]], [[Xcode|एक्स कोड (Xcode)]], और [[GNU Emacs|जीएनयू ईमैक्स (GNU Emacs)]] (vc.el के माध्यम से) जैसे एकीकृत विकास परिवेश के लिए उपलब्ध हैं। उन्नत अनुसंधान प्रोटोटाइप उपयुक्त प्रतिबद्ध संदेश उत्पन्न करते हैं,<ref>{{Cite book |last1=Cortes-Coy|first1=Luis Fernando|last2=Linares-Vasquez|first2=Mario|last3=Aponte|first3=Jairo|last4=Poshyvanyk|first4=Denys|title=स्रोत कोड विश्लेषण और हेरफेर पर 2014 IEEE 14वां अंतर्राष्ट्रीय कार्य सम्मेलन|chapter=On Automatically Generating Commit Messages via Summarization of Source Code Changes|date=2014 |pages=275–284|publisher=IEEE|doi=10.1109/scam.2014.14|isbn=978-1-4799-6148-1|s2cid=360545}}</ref> लेकिन यह केवल उन परियोजनाओं पर काम करता है जिनका पहले से ही बड़ा इतिहास है, क्योंकि प्रतिबद्ध संदेश परियोजना के सम्मेलनों और विशिष्टताओं पर बहुत निर्भर हैं।<ref>{{Cite book|last1=Etemadi|first1=Khashayar|last2=Monperrus|first2=Martin|title=सॉफ्टवेयर इंजीनियरिंग कार्यशालाओं पर IEEE/ACM 42वें अंतर्राष्ट्रीय सम्मेलन की कार्यवाही|chapter=On the Relevance of Cross-project Learning with Nearest Neighbours for Commit Message Generation|date=2020-06-27 |language=en|location=Seoul, Republic of Korea|publisher=ACM|pages=470–475|doi=10.1145/3387940.3391488|arxiv=2010.01924|isbn=9781450379632|s2cid=221911386}}</ref> | ||
== सामान्य शब्दावली == | == सामान्य शब्दावली == | ||
शब्दावली प्रणाली से प्रणाली में भिन्न हो सकती है, लेकिन | शब्दावली प्रणाली से प्रणाली में भिन्न हो सकती है, लेकिन सामान्य उपयोग में आने वाली कुछ शर्तों में सम्मलित हैं:<ref>{{cite book | last = Wingerd | first = Laura | title = प्रैक्टिकल परफोर्स| publisher = O'Reilly | year = 2005 | url = http://safari.oreilly.com/0596101856 | isbn = 0-596-10185-6 | access-date = 2006-08-27 | archive-date = 2007-12-21 | archive-url = https://web.archive.org/web/20071221132707/http://safari.oreilly.com/0596101856 | url-status = dead }}</ref> | ||
; बेसलाइन (कॉन्फ़िगरेशन प्रबंधन) : किसी दस्तावेज़ या स्रोत फ़ाइल का स्वीकृत पुनरीक्षण जिसमें बाद में परिवर्तन किए जा सकते हैं। देखें #आधार रेखाएँ, लेबल और टैग|आधार रेखाएँ, लेबल और टैग। | ; बेसलाइन (कॉन्फ़िगरेशन प्रबंधन) : किसी दस्तावेज़ या स्रोत फ़ाइल का स्वीकृत पुनरीक्षण जिसमें बाद में परिवर्तन किए जा सकते हैं। देखें #आधार रेखाएँ, लेबल और टैग|आधार रेखाएँ, लेबल और टैग। | ||
; {{visible anchor| | ; {{visible anchor|दोष}} : लेखक और संशोधन के लिए खोज जिसने किसी विशेष पंक्ति को अंतिम रूप से संशोधित किया। | ||
; शाखाकरण (पुनरीक्षण नियंत्रण) : संस्करण नियंत्रण के अनुसार फाइलों का सेट समय पर बिंदु पर शाखाबद्ध या फोर्क किया जा सकता है, जिससे कि उस समय से आगे, उन फाइलों की दो प्रतियां अलग-अलग गति से या अलग-अलग | ; शाखाकरण (पुनरीक्षण नियंत्रण) : संस्करण नियंत्रण के अनुसार फाइलों का सेट समय पर बिंदु पर शाखाबद्ध या फोर्क किया जा सकता है, जिससे कि उस समय से आगे, उन फाइलों की दो प्रतियां अलग-अलग गति से या अलग-अलग विधियों से एक-दूसरे से स्वतंत्र रूप से विकसित हो सकें। | ||
; परिवर्तन: एक परिवर्तन (या [[अंतर]], या [[डेल्टा एन्कोडिंग]]) संस्करण नियंत्रण के अनुसार दस्तावेज़ में विशिष्ट संशोधन का प्रतिनिधित्व करता है। परिवर्तन माने जाने वाले संशोधन की ग्रैन्युलैरिटी संस्करण नियंत्रण प्रणालियों के बीच भिन्न होती है। | ; परिवर्तन: एक परिवर्तन (या [[अंतर]], या [[डेल्टा एन्कोडिंग]]) संस्करण नियंत्रण के अनुसार दस्तावेज़ में विशिष्ट संशोधन का प्रतिनिधित्व करता है। परिवर्तन माने जाने वाले संशोधन की ग्रैन्युलैरिटी संस्करण नियंत्रण प्रणालियों के बीच भिन्न होती है। | ||
; परिवर्तन सूची: [[परमाणु लेनदेन]] बहु-परिवर्तन के साथ कई संस्करण नियंत्रण प्रणालियों पर, परिवर्तन सूची (या सीएल), परिवर्तन सेट, अद्यतन, या पैच (कंप्यूटिंग) ही प्रतिबद्धता में किए गए परिवर्तनों के सेट की पहचान करता है। यह स्रोत कोड के अनुक्रमिक दृश्य का भी प्रतिनिधित्व कर सकता है, जिससे स्रोत की परीक्षा किसी विशेष चेंजलिस्ट आईडी के रूप में हो सकती है। | ; परिवर्तन सूची: [[परमाणु लेनदेन]] बहु-परिवर्तन के साथ कई संस्करण नियंत्रण प्रणालियों पर, परिवर्तन सूची (या सीएल), परिवर्तन सेट, अद्यतन, या पैच (कंप्यूटिंग) ही प्रतिबद्धता में किए गए परिवर्तनों के सेट की पहचान करता है। यह स्रोत कोड के अनुक्रमिक दृश्य का भी प्रतिनिधित्व कर सकता है, जिससे स्रोत की परीक्षा किसी विशेष चेंजलिस्ट आईडी के रूप में हो सकती है। | ||
; चेकआउट: चेक आउट (या सह) करने के लिए रिपॉजिटरी से स्थानीय कामकाजी प्रति बनाना है। उपयोगकर्ता विशिष्ट संशोधन निर्दिष्ट कर सकता है या नवीनतम प्राप्त कर सकता है। वर्किंग कॉपी का वर्णन करने के लिए 'चेकआउट' शब्द को संज्ञा के रूप में भी उपयोग किया जा सकता है। जब किसी फ़ाइल को किसी साझा फ़ाइल सर्वर से चेक आउट किया गया है, तो इसे अन्य उपयोगकर्ताओं द्वारा संपादित नहीं किया जा सकता है। इसे होटल की तरह समझें, जब आप चेक आउट करते हैं, तो आपकी सुविधाओं तक पहुंच नहीं होती है। | ; चेकआउट: चेक आउट (या सह) करने के लिए रिपॉजिटरी से स्थानीय कामकाजी प्रति बनाना है। उपयोगकर्ता विशिष्ट संशोधन निर्दिष्ट कर सकता है या नवीनतम प्राप्त कर सकता है। वर्किंग कॉपी का वर्णन करने के लिए 'चेकआउट' शब्द को संज्ञा के रूप में भी उपयोग किया जा सकता है। जब किसी फ़ाइल को किसी साझा फ़ाइल सर्वर से चेक आउट किया गया है, तो इसे अन्य उपयोगकर्ताओं द्वारा संपादित नहीं किया जा सकता है। इसे होटल की तरह समझें, जब आप चेक आउट करते हैं, तो आपकी सुविधाओं तक पहुंच नहीं होती है। | ||
; क्लोन: क्लोनिंग का अर्थ है रिपॉजिटरी बनाना जिसमें किसी अन्य रिपॉजिटरी से संशोधन सम्मलित हैं। यह खाली (नए आरंभिक) रिपॉजिटरी में धकेलने या खींचने के बराबर है। संज्ञा के रूप में, दो रिपॉजिटरी को क्लोन कहा जा सकता है यदि उन्हें सिंक्रनाइज़ रखा जाता है, और समान संशोधन होते हैं। | ; क्लोन: क्लोनिंग का अर्थ है रिपॉजिटरी बनाना जिसमें किसी अन्य रिपॉजिटरी से संशोधन सम्मलित हैं। यह खाली (नए आरंभिक) रिपॉजिटरी में धकेलने या खींचने के बराबर है। संज्ञा के रूप में, दो रिपॉजिटरी को क्लोन कहा जा सकता है यदि उन्हें सिंक्रनाइज़ रखा जाता है, और समान संशोधन होते हैं। | ||
; [[चेंजसेट]] (संज्ञा): | ; [[चेंजसेट]] (संज्ञा): 'प्रतिबद्ध' या 'संशोधन' (एसवीएन) संशोधन है जो रिपॉजिटरी पर लागू होता है। | ||
; [[प्रतिबद्ध (संशोधन नियंत्रण)]] (क्रिया) : प्रतिबद्ध करने के लिए (चेक इन, सीआई या, शायद ही कभी, स्थापित करें, जमा करें या रिकॉर्ड करें) कार्यशील प्रति में किए गए परिवर्तनों को रिपॉजिटरी में वापस लिखना या विलय करना है। कमिट में मेटाडेटा, सामान्यतः लेखक की जानकारी और प्रतिबद्ध संदेश होता है जो परिवर्तन का वर्णन करता है। | ; [[प्रतिबद्ध (संशोधन नियंत्रण)]] (क्रिया) : प्रतिबद्ध करने के लिए (चेक इन, सीआई या, शायद ही कभी, स्थापित करें, जमा करें या रिकॉर्ड करें) कार्यशील प्रति में किए गए परिवर्तनों को रिपॉजिटरी में वापस लिखना या विलय करना है। कमिट में मेटाडेटा, सामान्यतः लेखक की जानकारी और प्रतिबद्ध संदेश होता है जो परिवर्तन का वर्णन करता है। | ||
; कमिट संदेश: कमिट के साथ संग्रहीत डेवलपर द्वारा लिखित संक्षिप्त नोट, जो कमिट का वर्णन करता है। आदर्श रूप से, यह रिकॉर्ड करता है कि संशोधन क्यों किया गया था, संशोधन के प्रभाव या उद्देश्य का विवरण, और परिवर्तन कैसे काम करता है, इसके स्पष्ट पहलू। | ; कमिट संदेश: कमिट के साथ संग्रहीत डेवलपर द्वारा लिखित संक्षिप्त नोट, जो कमिट का वर्णन करता है। आदर्श रूप से, यह रिकॉर्ड करता है कि संशोधन क्यों किया गया था, संशोधन के प्रभाव या उद्देश्य का विवरण, और परिवर्तन कैसे काम करता है, इसके स्पष्ट पहलू। | ||
; संघर्ष: एक विरोध तब होता है जब विभिन्न पक्ष ही दस्तावेज़ में परिवर्तन करते हैं, और | ; संघर्ष: एक विरोध तब होता है जब विभिन्न पक्ष ही दस्तावेज़ में परिवर्तन करते हैं, और प्रणाली परिवर्तनों का समाधान करने में असमर्थ होता है। उपयोगकर्ता को परिवर्तनों को मिलाकर, या दूसरे के पक्ष में परिवर्तन का चयन करके विरोध का समाधान करना चाहिए। | ||
; [[डेल्टा संपीड़न]]: अधिकांश पुनरीक्षण नियंत्रण सॉफ़्टवेयर डेल्टा संपीड़न का उपयोग करता है, जो फ़ाइलों के क्रमिक संस्करणों के बीच केवल अंतर को बनाए रखता है। यह फ़ाइलों के कई अलग-अलग संस्करणों के अधिक कुशल भंडारण की अनुमति देता है। | ; [[डेल्टा संपीड़न]]: अधिकांश पुनरीक्षण नियंत्रण सॉफ़्टवेयर डेल्टा संपीड़न का उपयोग करता है, जो फ़ाइलों के क्रमिक संस्करणों के बीच केवल अंतर को बनाए रखता है। यह फ़ाइलों के कई अलग-अलग संस्करणों के अधिक कुशल भंडारण की अनुमति देता है। | ||
; डायनेमिक स्ट्रीम: एक स्ट्रीम जिसमें कुछ या सभी फ़ाइल संस्करण पैरेंट स्ट्रीम के संस्करणों के दर्पण होते हैं। | ; डायनेमिक स्ट्रीम: एक स्ट्रीम जिसमें कुछ या सभी फ़ाइल संस्करण पैरेंट स्ट्रीम के संस्करणों के दर्पण होते हैं। | ||
; निर्यात: निर्यात रिपॉजिटरी से फाइलों को प्राप्त करने का कार्य है। यह चेक आउट के समान है, सिवाय इसके कि यह वर्किंग कॉपी में उपयोग किए गए वर्जन-कंट्रोल मेटाडेटा के बिना क्लीन डायरेक्टरी ट्री बनाता है। यह अधिकांशतः सामग्री प्रकाशित करने से पहले उपयोग किया जाता है, उदाहरण के | ; निर्यात: निर्यात रिपॉजिटरी से फाइलों को प्राप्त करने का कार्य है। यह चेक आउट के समान है, सिवाय इसके कि यह वर्किंग कॉपी में उपयोग किए गए वर्जन-कंट्रोल मेटाडेटा के बिना क्लीन डायरेक्टरी ट्री बनाता है। यह अधिकांशतः सामग्री प्रकाशित करने से पहले उपयोग किया जाता है, उदाहरण के लिए | ||
; लायें : पुल देखें। | ; लायें : पुल देखें। | ||
; आगे एकीकरण: मुख्य ट्रंक में किए गए परिवर्तनों को विकास (फीचर या टीम) शाखा में विलय करने की प्रक्रिया। | ; आगे एकीकरण: मुख्य ट्रंक में किए गए परिवर्तनों को विकास (फीचर या टीम) शाखा में विलय करने की प्रक्रिया। | ||
| Line 149: | Line 136: | ||
:* एक शाखा बनाई जाती है, फाइलों में कोड स्वतंत्र रूप से संपादित किया जाता है, और अद्यतन शाखा को बाद में एकल, एकीकृत ट्रंक में सम्मलित किया जाता है। | :* एक शाखा बनाई जाती है, फाइलों में कोड स्वतंत्र रूप से संपादित किया जाता है, और अद्यतन शाखा को बाद में एकल, एकीकृत ट्रंक में सम्मलित किया जाता है। | ||
: * फाइलों का सेट ब्रांच किया गया है, शाखा में ब्रांचिंग से पहले सम्मलित समस्या को ठीक किया गया है, और फ़िक्स को फिर दूसरी शाखा में मिला दिया गया है। (इस प्रकार के चयनात्मक विलय को कभी-कभी पिछले स्थिति में पूर्ण विलय से अलग करने के लिए चेरी पिक के रूप में जाना जाता है।) | : * फाइलों का सेट ब्रांच किया गया है, शाखा में ब्रांचिंग से पहले सम्मलित समस्या को ठीक किया गया है, और फ़िक्स को फिर दूसरी शाखा में मिला दिया गया है। (इस प्रकार के चयनात्मक विलय को कभी-कभी पिछले स्थिति में पूर्ण विलय से अलग करने के लिए चेरी पिक के रूप में जाना जाता है।) | ||
; प्रचार करें: फ़ाइल सामग्री को कम नियंत्रित स्थान से अधिक नियंत्रित स्थान में कॉपी करने का कार्य। उदाहरण के लिए, उपयोगकर्ता के कार्यक्षेत्र से रिपॉजिटरी में, या स्ट्रीम से उसके | ; प्रचार करें: फ़ाइल सामग्री को कम नियंत्रित स्थान से अधिक नियंत्रित स्थान में कॉपी करने का कार्य। उदाहरण के लिए, उपयोगकर्ता के कार्यक्षेत्र से रिपॉजिटरी में, या स्ट्रीम से उसके पैरेन्ट्स तक।<ref>{{cite book | title = अवधारणा मैनुअल| edition = Version 4.7 | publisher = Accurev | date = July 2008}}</ref> | ||
; खींचो, धक्का दो: एक रिपॉजिटरी से दूसरे में संशोधन कॉपी करें। पुल रिसीविंग रिपॉजिटरी द्वारा शुरू किया जाता है, जबकि स्रोत द्वारा पुश शुरू किया जाता है। फ़ेच का उपयोग कभी-कभी पुल के पर्याय के रूप में किया जाता है, या इसका | ; खींचो, धक्का दो: एक रिपॉजिटरी से दूसरे में संशोधन कॉपी करें। पुल रिसीविंग रिपॉजिटरी द्वारा शुरू किया जाता है, जबकि स्रोत द्वारा पुश शुरू किया जाता है। फ़ेच का उपयोग कभी-कभी पुल के पर्याय के रूप में किया जाता है, या इसका अभिप्राय यह है कि पुल के बाद अपडेट होता है। | ||
; पुल अनुरोध: एक डेवलपर दूसरों से उनके पुश किए गए परिवर्तनों को मर्ज करने के लिए कह रहा है। | ; पुल अनुरोध: एक डेवलपर दूसरों से उनके पुश किए गए परिवर्तनों को मर्ज करने के लिए कह रहा है। | ||
; रिपॉजिटरी (संस्करण नियंत्रण): रिपॉजिटरी (या रेपो) वह जगह है जहां फाइलों का वर्तमान और ऐतिहासिक डेटा संग्रहीत किया जाता है, अधिकांशतः सर्वर पर। कभी-कभी डिपो भी कहा जाता है। | ; रिपॉजिटरी (संस्करण नियंत्रण): रिपॉजिटरी (या रेपो) वह जगह है जहां फाइलों का वर्तमान और ऐतिहासिक डेटा संग्रहीत किया जाता है, अधिकांशतः सर्वर पर। कभी-कभी डिपो भी कहा जाता है। | ||
; हल करें: एक ही दस्तावेज़ में विभिन्न परिवर्तनों के बीच विरोध को संबोधित करने के लिए उपयोगकर्ता के हस्तक्षेप का कार्य। | ; हल करें: एक ही दस्तावेज़ में विभिन्न परिवर्तनों के बीच विरोध को संबोधित करने के लिए उपयोगकर्ता के हस्तक्षेप का कार्य। | ||
; रिवर्स इंटीग्रेशन: विभिन्न टीम शाखाओं को वर्जनिंग | ; रिवर्स इंटीग्रेशन: विभिन्न टीम शाखाओं को वर्जनिंग प्रणाली के मुख्य ट्रंक में मर्ज करने की प्रक्रिया। | ||
; पुनरीक्षण: इसके अतिरिक्त संस्करण: सॉफ्टवेयर संस्करण किसी भी रूप में परिवर्तन है। एसवीके में, रिपॉजिटरी में पूरे पेड़ के समय में संशोधन स्थिति है। | ; पुनरीक्षण: इसके अतिरिक्त संस्करण: सॉफ्टवेयर संस्करण किसी भी रूप में परिवर्तन है। एसवीके में, रिपॉजिटरी में पूरे पेड़ के समय में संशोधन स्थिति है। | ||
; साझा करें: एक ही समय में फ़ाइल या फ़ोल्डर को कई शाखाओं में उपलब्ध कराने का कार्य। जब साझा फ़ाइल को शाखा में बदला जाता है, तो इसे अन्य शाखाओं में बदल दिया जाता है। | ; साझा करें: एक ही समय में फ़ाइल या फ़ोल्डर को कई शाखाओं में उपलब्ध कराने का कार्य। जब साझा फ़ाइल को शाखा में बदला जाता है, तो इसे अन्य शाखाओं में बदल दिया जाता है। | ||
| Line 176: | Line 163: | ||
* [[सॉफ्टवेयर वर्जनिंग]] | * [[सॉफ्टवेयर वर्जनिंग]] | ||
* [[संस्करण फाइल सिस्टम]]}} | * [[संस्करण फाइल सिस्टम]]}} | ||
==टिप्पणियाँ== | ==टिप्पणियाँ== | ||
Revision as of 21:20, 4 January 2023
 | This article needs additional citations for verification. (April 2011) (Learn how and when to remove this template message) |
सॉफ्टवेयर अभियांत्रिकी में, संस्करण नियंत्रण (जिसे पुनरीक्षण नियंत्रण, स्रोत नियंत्रण या स्रोत कोड प्रबंधन के रूप में भी जाना जाता है) कंप्यूटर प्रोग्राम, दस्तावेज़, बड़ी वेब साइट या सूचना के अन्य संग्रह में परिवर्तन के प्रबंधन के लिए जिम्मेदार प्रणाली का वर्ग है। संस्करण नियंत्रण सॉफ्टवेयर कॉन्फ़िगरेशन प्रबंधन का घटक है।[1]
परिवर्तनों को सामान्यतः संख्या या अक्षर कोड द्वारा पहचाना जाता है, जिसे संशोधन संख्या, संशोधन स्तर या केवल संशोधन कहा जाता है। उदाहरण के लिए, फ़ाइलों का प्रारंभिक सेट संशोधन 1 है। जब पहला परिवर्तन किया जाता है, परिणामी सेट संशोधन 2 होता है, और इसी तरह आगे भी। प्रत्येक संशोधन टाईम स्टैम्प और परिवर्तन करने वाले व्यक्ति से जुड़ा होता है। संशोधनों की तुलना की जा सकती है, उन्हें पुनर्स्थापित किया जा सकता है, और कुछ प्रकार की फाइलों के साथ विलय किया जा सकता है।[2]
संशोधनों को व्यवस्थित और नियंत्रित करने के लिए तार्किक तरीके की आवश्यकता लगभग तब तक रही है जब तक लेखन अस्तित्व में रहा है, लेकिन कंप्यूटिंग का युग शुरू होने पर संशोधन नियंत्रण अधिक महत्वपूर्ण और जटिल हो गया। संस्करण (पुस्तक) की संख्या और विनिर्देश (तकनीकी मानक) ऐसे उदाहरण हैं जो प्रिंट-ओनली युग के हैं। आज, सबसे सक्षम (साथ ही जटिल) पुनरीक्षण नियंत्रण प्रणालियां वे हैं जिनका उपयोग सॉफ्टवेयर विकास में किया जाता है, जहां लोगों की टीम समवर्ती रूप से समान फ़ाइलों में परिवर्तन कर सकती है।
वर्जन कंट्रोल प्रणाली सामान्यतः स्टैंड-अलोन एप्लिकेशन के रूप में चलाए जाते हैं, लेकिन संशोधन नियंत्रण भी विभिन्न प्रकार के सॉफ्टवेयर डेवलपमेंट एम्बेड किया जाता है, जैसे शब्द संसाधक और स्प्रेडशीट, सहयोगी ग्रुपवेयर,[3] और सामग्री प्रबंधन प्रणालियाँ, उदाहरण के लिए, विकिपीडिया की सहायता: पृष्ठ इतिहास। संशोधन नियंत्रण किसी दस्तावेज़ को पिछले संशोधन में वापस लाने में सक्षम बनाता है, जो संपादकों को दूसरे के संपादनों को ट्रैक करने, गलतियों को सुधारने और हफ्ता में बर्बरता और स्पैमिंग से बचाव करने की अनुमति देने के लिए महत्वपूर्ण है।
सिंहावलोकन
कंप्यूटर सॉफ़्टवेयर अभियांत्रिकी में, पुनरीक्षण नियंत्रण किसी भी प्रकार का अभ्यास है जो ट्रैक करता है और स्रोत कोड में परिवर्तन पर नियंत्रण प्रदान करता है। सॉफ्टवेयर डेवलपर कभी-कभी दस्तावेज़ीकरण और कॉन्फ़िगरेशन फ़ाइलें के साथ-साथ स्रोत कोड को बनाए रखने के लिए पुनरीक्षण नियंत्रण सॉफ़्टवेयर का उपयोग करते हैं।
जैसा कि टीम सॉफ्टवेयर डिजाइन, विकसित और तैनात करती है, ही सॉफ्टवेयर के कई संस्करणों को अलग-अलग साइटों पर तैनात किया जाना ट्रंक (सॉफ्टवेयर) के डेवलपर्स के लिए अपडेट पर साथ काम करना आम बात है। कंप्यूटर बग या सॉफ्टवेयर की विशेषताएं अधिकांशतः केवल कुछ संस्करणों में ही सम्मलित होती हैं (क्योंकि कुछ समस्याओं को ठीक करने और कार्यक्रम के विकास के रूप में दूसरों की शुरूआत के कारण)। इसलिए, बगों का पता लगाने और उन्हें ठीक करने के प्रयोजनों के लिए, यह निर्धारित करने के लिए सॉफ़्टवेयर के विभिन्न संस्करणों को पुनः प्राप्त करने और चलाने में सक्षम होना महत्वपूर्ण है कि समस्या किस संस्करण में होती है। सॉफ़्टवेयर के दो संस्करणों को समवर्ती रूप से विकसित करना भी आवश्यक हो सकता है: उदाहरण के लिए, जहाँ संस्करण में बग फिक्स हैं, लेकिन कोई नई सुविधाएँ नहीं हैं (ब्रांचिंग (संशोधन नियंत्रण)), जबकि दूसरा संस्करण वह है जहाँ नई सुविधाओं पर काम किया जाता है (ट्रंक () सॉफ्टवेयर))।
सबसे सरल स्तर पर, डेवलपर्स प्रोग्राम के विभिन्न संस्करणों की कई प्रतियों को सरलता से रख सकते हैं, और उन्हें उचित रूप से लेबल कर सकते हैं। इस सरल तरीके का उपयोग कई बड़ी सॉफ्टवेयर परियोजनाओं में किया गया है। जबकि यह विधि काम कर सकती है, यह अक्षम है क्योंकि कार्यक्रम की कई समान-समान प्रतियों को बनाए रखना पड़ता है। इसके लिए डेवलपर्स को बहुत अधिक आत्म-अनुशासन की आवश्यकता होती है और अधिकांशतः गलतियाँ होती हैं। चूंकि कोड आधार समान है, इसलिए इसे डेवलपर्स के सेट को पढ़ने-लिखने-निष्पादित करने की अनुमति देने की भी आवश्यकता होती है, और यह अनुमतियों को प्रबंधित करने वाले किसी व्यक्ति के दबाव को जोड़ता है जिससे कि कोड आधार समझौता न हो, जो अधिक जटिलता जोड़ता है। परिणाम स्वरूप, संशोधन नियंत्रण प्रक्रिया के कुछ या सभी को स्वचालित करने के लिए प्रणाली विकसित किए गए हैं। यह सुनिश्चित करता है कि संस्करण नियंत्रण चरणों का अधिकांश प्रबंधन पर्दे के पीछे छिपा हुआ है।
इसके अतिरिक्त, सॉफ्टवेयर विकास, कानूनी और व्यावसायिक अभ्यास, और अन्य वातावरण में, टीम द्वारा संपादित किए जाने वाले एकल दस्तावेज़ या कोड के स्निपेट के लिए यह तेजी से सामान्य हो गया है, जिसके सदस्य भौगोलिक रूप से अलग-अलग हो सकते हैं और अलग-अलग और यहां तक कि इसके विपरीत हो सकते हैं। रूचियाँ। परिष्कृत पुनरीक्षण नियंत्रण जो दस्तावेजों और कोड में परिवर्तनों के स्वामित्व के लिए ट्रैक करता है और ऐसी स्थितियों में अत्यंत सहायक या अपरिहार्य भी हो सकता है।
पुनरीक्षण नियंत्रण विन्यास फाइल में परिवर्तनों को भी ट्रैक कर सकता है, जैसे कि सामान्यतः इसमें संग्रहीत /etc या /usr/local/etc यूनिक्स प्रणाली पर। यह प्रणाली प्रशासकों को किए गए परिवर्तनों को सरलता से ट्रैक करने का तरीका देता है और आवश्यकता पड़ने पर प्राचीन संस्करणों में वापस जाने का तरीका देता है।
इतिहास
OS/360 और उत्तराधिकारी के लिए आईबीएम का OS/360 समर्थन कार्यक्रम आईईबीयूपीडीटीई (IEBUPDTE) सॉफ़्टवेयर अपडेट टूल 1962 से पहले का है, यकीनन संस्करण नियंत्रण प्रणाली टूल का अग्रदूत है। स्रोत कोड नियंत्रण के लिए डिज़ाइन किया गया पूर्ण प्रणाली 1972 में शुरू किया गया था, उसी प्रणाली के लिए स्रोत कोड नियंत्रण प्रणाली (OS/360)। स्रोत कोड नियंत्रण प्रणाली की शुरूआत, 4 दिसंबर, 1975 को प्रकाशित होने के कारण, ऐतिहासिक रूप से निहित है कि यह पहली जानबूझकर संशोधन नियंत्रण प्रणाली थी।[4] आरसीएस ने ठीक बाद में पीछा किया,[5] इसके नेटवर्क संस्करण समवर्ती संस्करण प्रणाली के साथ। समवर्ती संस्करण प्रणाली के बाद की अगली पीढ़ी में अपाचे सर्वर का प्रभुत्व था,[6] गिट जैसे वितरित पुनरीक्षण नियंत्रण उपकरण के उदय के बाद इसका उदाहरण हैं।[7]
संरचना
संशोधन नियंत्रण समय के साथ डेटा के सेट में परिवर्तन का प्रबंधन करता है। इन परिवर्तनों को विभिन्न विधियों से संरचित किया जा सकता है।
अधिकांशतः डेटा को कई व्यक्तिगत वस्तुओं के संग्रह के रूप में माना जाता है, जैसे फ़ाइलें या दस्तावेज़, और व्यक्तिगत फ़ाइलों में परिवर्तन ट्रैक किए जाते हैं। यह अलग-अलग फाइलों के बारे में अंतर्ज्ञान के साथ मेल खाता है लेकिन जब पहचान बदलती है, जैसे फ़ाइलों का नाम परिवर्तित करने, विभाजित करने या विलय करने के समय समस्याएं पैदा होती हैं। तदनुसार, कुछ प्रणालियाँ जैसे कि गिट, इसके अतिरिक्त संपूर्ण रूप से डेटा में परिवर्तन पर विचार करती हैं, जो सरल परिवर्तनों के लिए कम सहज है लेकिन अधिक जटिल परिवर्तनों को सरल बनाता है।
जब संशोधन नियंत्रण के अधीन डेटा को संशोधित किया जाता है, चेक आउट द्वारा पुनर्प्राप्त किए जाने के बाद, यह सामान्य रूप से संशोधन नियंत्रण प्रणाली (रिपॉजिटरी में) में तुरंत परिलक्षित नहीं होता है, इसके अतिरिक्त इसके अतिरिक्त चेक इन या प्रतिबद्ध होना चाहिए। संशोधन नियंत्रण के बाहर की प्रतिलिपि को कार्यशील प्रति के रूप में जाना जाता है। साधारण उदाहरण के रूप में, कंप्यूटर फ़ाइल को संपादित करते समय, संपादन प्रोग्राम द्वारा स्मृति में संग्रहीत डेटा कार्यशील प्रतिलिपि होती है, जिसे सहेज कर प्रतिबद्ध किया जाता है। विशेष रूप से, कोई दस्तावेज़ का प्रिंट आउट ले सकता है, इसे हाथ से संपादित कर सकता है, और केवल बाद में मैन्युअल रूप से कंप्यूटर में परिवर्तनों को इनपुट कर सकता है और इसे सहेज सकता है। स्रोत कोड नियंत्रण के लिए, कार्यशील प्रति इसके अतिरिक्त विशेष संशोधन में सभी फाइलों की प्रति है, जो सामान्यतः डेवलपर के कंप्यूटर पर स्थानीय रूप से संग्रहीत होती है;[note 1] इस स्थिति में फ़ाइल को सहेजने से केवल कार्यशील प्रति बदल जाती है, और रिपॉजिटरी में जाँच करना अलग चरण है।
यदि ही डेटा सेट या दस्तावेज़ पर कई लोग काम कर रहे हैं, तो वे अंतर्निहित रूप से डेटा की शाखाएं बना रहे हैं (उनकी कार्यशील प्रतियों में), और इस प्रकार विलय के विवाद उत्पन्न होते हैं, जैसा कि नीचे चर्चा की गई है। साधारण सहयोगी दस्तावेज़ संपादन के लिए, फ़ाइल लॉकिंग का उपयोग करके या केवल उसी दस्तावेज़ पर काम करने से बचा जा सकता है जिस पर कोई और काम कर रहा है।
पुनरीक्षण नियंत्रण प्रणालियाँ अधिकांशतः केंद्रीकृत होती हैं, एकल आधिकारिक डेटा स्टोर, रिपॉजिटरी, और चेक-आउट और चेक-इन इस केंद्रीय रिपॉजिटरी के संदर्भ में किए जाते हैं। वैकल्पिक रूप से, वितरित पुनरीक्षण नियंत्रण में, कोई भी रिपॉजिटरी आधिकारिक नहीं है, और डेटा को चेक आउट किया जा सकता है और किसी भी रिपॉजिटरी में चेक किया जा सकता है। अलग रिपॉजिटरी में चेक करते समय, इसे मर्ज या पैच के रूप में समझा जाता है।
ग्राफ संरचना
ग्राफ सिद्धांत के संदर्भ में, संशोधनों को सामान्यतः विकास की रेखा (ट्रंक) के रूप में माना जाता है, जो शाखाओं से दूर होती है, निर्देशित वृक्ष का निर्माण करती है, जिसे विकास की या से अधिक समानांतर रेखाओं (शाखाओं की मुख्य रेखाएं) के रूप में देखा जाता है। वास्तव में यह संरचना अधिक जटिल है, निर्देशित विश्वकोश ग्राफ का निर्माण करती है, लेकिन कई उद्देश्यों के लिए मर्ज के साथ पेड़ पर्याप्त सन्निकटन है।
संशोधन समय के साथ अनुक्रम में होते हैं, और इस प्रकार संशोधन संख्या या टाइमस्टैम्प द्वारा क्रम में व्यवस्थित किया जा सकता है।[note 2] संशोधन पिछले संशोधनों पर आधारित होते हैं, चूंकि पुराने संशोधन को बड़े पैमाने पर या पूरी तरह से बदलना संभव है, जैसे कि सभी सम्मलित पाठ हटाएं जाते हैं या नया पाठ डाला जाता हैं। सबसे सरल स्थिति में, बिना किसी ब्रांचिंग या पूर्ववत के, प्रत्येक संशोधन अकेले अपने तत्काल पूर्ववर्ती पर आधारित होता है, और वे सरल रेखा बनाते हैं, जिसमें नवीनतम संस्करण, हेड संशोधन या टिप होता है। ग्राफ सिद्धांत के शब्दों में, प्रत्येक संशोधन को बिंदु के रूप में और प्रत्येक व्युत्पन्न संशोधन संबंध को तीर के रूप में चित्रित करना (पारंपरिक रूप से पुराने से नए की ओर इशारा करते हुए, समय के समान दिशा में), यह रेखीय ग्राफ है। यदि ब्रांचिंग है, तो भविष्य के कई संशोधन पिछले संशोधन पर आधारित होते हैं, या पूर्ववत होते हैं, इसलिए संशोधन अपने पूर्ववर्ती की तुलना में पुराने संशोधन पर निर्भर हो सकता है, फिर परिणामी ग्राफ निर्देशित पेड़ होता है (प्रत्येक नोड में से अधिक हो सकते हैं) चाइल्ड), और इसमें कई टिप्स हैं, जो बिना चिल्ड्रन वाले संशोधनों के अनुरूप हैं (प्रत्येक शाखा पर नवीनतम संशोधन)।[note 3] सिद्धांत रूप में परिणामी पेड़ को पसंदीदा टिप (मुख्य नवीनतम संशोधन) की आवश्यकता नहीं है - केवल विभिन्न विभिन्न संशोधन - लेकिन व्यवहार में टिप को सामान्यतः हेड के रूप में पहचाना जाता है। जब कोई नया संशोधन हेड पर आधारित होता है, तो उसे या तो नए हेड के रूप में पहचाना जाता है, या नई शाखा माना जाता है।[note 4] प्रारंभ से हेड तक के संशोधनों की सूची (ग्राफ़ सिद्धांत के शब्दों में, ट्री में अद्वितीय पथ, जो पहले की तरह रेखीय ग्राफ़ बनाता है) ट्रंक या मेनलाइन है।[note 5] इसके विपरीत, जब संशोधन से अधिक पिछले संशोधन पर आधारित हो सकता है (जब नोड में से अधिक पैरेंट हो सकते हैं), परिणामी प्रक्रिया को मर्ज (संशोधन नियंत्रण) कहा जाता है, और यह संशोधन नियंत्रण के सबसे जटिल पहलुओं में से है। यह अधिकांशतः तब होता है जब कई शाखाओं में परिवर्तन होते हैं (अधिकांशतः दो, लेकिन अधिक संभव होते हैं), जो तब दोनों परिवर्तनों को सम्मलित करते हुए ही शाखा में विलय कर दिए जाते हैं। यदि ये परिवर्तन ओवरलैप होते हैं, तो विलय करना मुश्किल या असंभव हो सकता है, और मैन्युअल हस्तक्षेप या पुनर्लेखन की आवश्यकता होती है।
विलय की उपस्थिति में, परिणामी ग्राफ़ अब पेड़ नहीं है, क्योंकि नोड्स में कई पैरेन्ट्स हो सकते हैं, इसके अतिरिक्त इसके अतिरिक्त रूट निर्देशित एसाइक्लिक ग्राफ (डीएजी) है। ग्राफ विश्वकोश है क्योंकि पैरेन्ट्स हमेशा समय में पीछे होते हैं, और जड़ होते हैं क्योंकि सबसे पुराना संस्करण है। मान लें कि ट्रंक है, शाखाओं से विलय को पेड़ के बाहरी रूप में माना जा सकता है - शाखा में परिवर्तन पैच के रूप में पैक किए जाते हैं, जो हेड (ट्रंक के) पर लागू होते हैं, बिना किसी स्पष्ट संदर्भ के नया संशोधन बनाते हैं शाखा, और वृक्ष संरचना को संरक्षित करना। इस प्रकार, जबकि संस्करणों के बीच वास्तविक संबंध डैग बनाते हैं, इसे ट्री प्लस मर्ज माना जा सकता है, और ट्रंक स्वयं रेखा है।
वितरित संशोधन नियंत्रण में, कई रिपॉजिटरी की उपस्थिति में ये मूल संस्करण (पेड़ की जड़) पर आधारित हो सकते हैं, लेकिन मूल रूट होने की आवश्यकता नहीं है, और इस प्रकार प्रत्येक रिपॉजिटरी के लिए केवल अलग रूट (सबसे पुराना संशोधन) , उदाहरण के लिए, यदि दो लोग परियोजना पर अलग-अलग काम करना शुरू करते हैं। इसी तरह कई डेटा सेट (एकाधिक प्रोजेक्ट) की उपस्थिति में जो डेटा का आदान-प्रदान या मर्ज करते हैं, भी रूट नहीं है, चूंकि सादगी के लिए कोई प्रोजेक्ट को प्राथमिक और दूसरे को द्वितीयक के रूप में सोच सकता है, पहले के साथ या उसके बिना मर्ज किया गया जिसका अपना संशोधन इतिहास होता हैं।
विशिष्ट रणनीतियाँ
प्रारंभिक ब्लूप्रिंट या सफेद छाप के संशोधनों पर नज़र रखने के आधार पर औपचारिक प्रक्रियाओं से विकसित अभियांत्रिकी संशोधन नियंत्रण[citation needed]. नियंत्रण की इस प्रणाली ने स्पष्ट रूप से डिजाइन के पहले की स्थिति में लौटने की अनुमति दी, ऐसे स्थितियों के लिए जिनमें डिजाइन के विकास में अभियांत्रिकी डेड-एंड पहुंच गया था। किए गए परिवर्तनों का ट्रैक रखने के लिए पुनरीक्षण तालिका का उपयोग किया गया था। इसके अतिरिक्त, ड्राइंग के संशोधित क्षेत्रों को पुनरीक्षण बादलों का उपयोग करके प्रदर्शित किया गया था।
संस्करण नियंत्रण व्यापार और कानून में व्यापक है। दरअसल, अनुबंध रेडलाइन और कानूनी ब्लैकलाइन संशोधन नियंत्रण के प्रारंभिक रूपों में से कुछ हैं,[8] और अभी भी अलग-अलग डिग्री के परिष्कार के साथ व्यापार और कानून में कार्यरत हैं। पारंपरिक पुनरीक्षण नियंत्रण के मैनुअल इलेक्ट्रॉनिक कार्यान्वयन को प्रतिस्थापित करते हुए, सीएडी फ़ाइलों में परिवर्तनों की इलेक्ट्रॉनिक ट्रैकिंग (उत्पाद डेटा प्रबंधन देखें) के लिए सबसे परिष्कृत तकनीकों का उपयोग किया जाने लगा है।[citation needed]
स्रोत-प्रबंधन मॉडल
पारंपरिक पुनरीक्षण नियंत्रण प्रणालियाँ केंद्रीकृत मॉडल का उपयोग करती हैं जहाँ सभी पुनरीक्षण नियंत्रण कार्य साझा सर्वर (कंप्यूटिंग) पर होते हैं। यदि दो डेवलपर ही फ़ाइल को ही समय में बदलने का प्रयास करते हैं, तो एक्सेस प्रबंधन के किसी तरीके के बिना डेवलपर एक-दूसरे के काम को ओवरराइट कर सकते हैं। केंद्रीकृत पुनरीक्षण नियंत्रण प्रणाली इस समस्या को दो अलग-अलग स्रोत प्रबंधन मॉडल में से में हल करती है: फ़ाइल लॉकिंग और वर्जन मर्जिंग।
परमाणु संचालन
एक ऑपरेशन परमाणु है यदि ऑपरेशन बाधित होने पर भी प्रणाली को सुसंगत स्थिति में छोड़ दिया जाता है। प्रतिबद्ध ऑपरेशन सामान्यतः इस अर्थ में सबसे महत्वपूर्ण है। कमिट संशोधन नियंत्रण प्रणाली को परिवर्तनों के समूह को अंतिम रूप देने और सभी उपयोगकर्ताओं के लिए उपलब्ध कराने के लिए कहते हैं। सभी पुनरीक्षण नियंत्रण प्रणालियों में परमाणु कार्य नहीं होते हैं; समवर्ती संस्करण प्रणाली में इस सुविधा का अभाव है।[9]
फ़ाइल लॉकिंग
समवर्ती पहुंच समस्याओं को रोकने की सबसे सरल विधि में फ़ाइल लॉकिंग सम्मलित है जिससे कि समय में केवल डेवलपर के पास उन फ़ाइलों की केंद्रीय रिपॉजिटरी (संस्करण नियंत्रण) प्रतियों तक पहुंच हो। इस प्रकार जब डेवलपर किसी फ़ाइल की जाँच कर लेता है, तो अन्य उस फ़ाइल को पढ़ सकते हैं, लेकिन कोई भी अन्य उस फ़ाइल को तब तक नहीं बदल सकता जब तक कि वह डेवलपर अद्यतन संस्करण में जाँच नहीं करता (या चेकआउट को रद्द कर देता है)।
फाइल लॉकिंग में लाभ और हानियाँ दोनों हैं। जब कोई उपयोगकर्ता किसी बड़ी फ़ाइल (या फ़ाइलों के समूह) के कई अनुभागों में आमूल-चूल परिवर्तन कर रहा हो, तो यह कठिन मर्ज विरोधों से कुछ सुरक्षा प्रदान कर सकता है। यदि फ़ाइलों को बहुत लंबे समय के लिए विशेष रूप से लॉक छोड़ दिया जाता है, तो अन्य डेवलपर्स संशोधन नियंत्रण सॉफ़्टवेयर को बायपास करने और फ़ाइलों को स्थानीय रूप से बदलने के लिए लुभा सकते हैं, जब अन्य परिवर्तनों को अंततः चेक इन किया जाता है, तो कठिन मैन्युअल मर्ज को मजबूर किया जा सकता है। बड़े संगठन में, फ़ाइलें हो सकती हैं चेक आउट छोड़ दिया और लॉक कर दिया और भूल गए क्योंकि डेवलपर्स परियोजनाओं के बीच चलते हैं - ये टूल यह देखना सरल बना सकते हैं या नहीं कर सकते हैं कि किसके पास फ़ाइल चेक आउट हो गई है।
संस्करण विलय
अधिकांश संस्करण नियंत्रण प्रणाली ही समय में कई डेवलपर्स को ही फाइल को संपादित करने की अनुमति देती हैं। केंद्रीय रिपॉजिटरी में परिवर्तनों की जांच करने वाला पहला डेवलपर हमेशा सफल होता है। प्रणाली केंद्रीय रिपॉजिटरी में आगे के परिवर्तनों को मर्ज (संशोधन नियंत्रण) करने की सुविधा प्रदान कर सकता है, और जब अन्य डेवलपर चेक इन करते हैं तो पहले डेवलपर से परिवर्तनों को संरक्षित कर सकते हैं।
दो फाइलों को मर्ज करना बहुत ही नाजुक ऑपरेशन हो सकता है, और सामान्यतः केवल तभी संभव होता है जब डेटा संरचना सरल हो, जैसा कि पाठ फ़ाइलों में होता है। दो छवि फ़ाइलों के विलय का परिणाम छवि फ़ाइल में बिल्कुल भी नहीं हो सकता है। कोड में जाँच करने वाले दूसरे डेवलपर को यह सुनिश्चित करने के लिए मर्ज की देखभाल करने की आवश्यकता होगी कि परिवर्तन संगत हैं और यह कि मर्ज ऑपरेशन फ़ाइलों के भीतर अपनी तर्क त्रुटियों का परिचय नहीं देता है। ये समस्याएँ स्वचालित या अर्ध-स्वचालित मर्ज संचालन की उपलब्धता को मुख्य रूप से सरल पाठ-आधारित दस्तावेज़ों तक सीमित करती हैं, जब तक कि फ़ाइल प्रकारों के लिए कोई विशिष्ट मर्ज प्लग-इन (कंप्यूटिंग) उपलब्ध न हो।
आरक्षित संपादन की अवधारणा अनन्य लेखन पहुंच के लिए फ़ाइल को स्पष्ट रूप से लॉक करने का वैकल्पिक साधन प्रदान कर सकती है, तब भी जब मर्जिंग क्षमता सम्मलित हो।
बेसलाइन, लेबल और टैग
अधिकांश पुनरीक्षण नियंत्रण उपकरण स्नैपशॉट (प्रोजेक्ट को लेबल करें) या स्नैपशॉट के रिकॉर्ड (इसे बेसलाइन एक्स के साथ आज़माएं) की पहचान करने की क्रिया को संदर्भित करने के लिए इन समान शर्तों (बेसलाइन, लेबल, टैग) में से केवल का उपयोग करेंगे। दस्तावेज़ीकरण या चर्चा में सामान्यतः बेसलाइन, लेबल या टैग में से केवल शब्द का उपयोग किया जाता है[citation needed]; उन्हें पर्यायवाची माना जा सकता है।
अधिकांश परियोजनाओं में, कुछ स्नैपशॉट दूसरों की तुलना में अधिक महत्वपूर्ण होते हैं, जैसे कि प्रकाशित रिलीज़, शाखाओं या मील के पत्थर को इंगित करने के लिए उपयोग किया जाता है।
जब ही संदर्भ में आधार रेखा और लेबल या टैग दोनों का साथ उपयोग किया जाता है, तो लेबल और टैग सामान्यतः स्नैपशॉट के रिकॉर्ड को पहचानने या बनाने के उपकरण के भीतर तंत्र को संदर्भित करते हैं, और आधार रेखा किसी दिए गए लेबल के बढ़ते महत्व या टैग को इंगित करती है।
कॉन्फ़िगरेशन प्रबंधन की सबसे औपचारिक चर्चा बेसलाइन (कॉन्फ़िगरेशन प्रबंधन) शब्द का उपयोग करती है।
वितरित संशोधन नियंत्रण
वितरित पुनरीक्षण नियंत्रण प्रणाली (DRCS) केंद्रीकृत प्रणालियों के क्लाइंट-सर्वर मॉडल|क्लाइंट-सर्वर दृष्टिकोण के विपरीत सहकर्मी से सहकर्मी दृष्टिकोण लेती है। एकल, केंद्रीय रिपॉजिटरी के अतिरिक्त जिस पर क्लाइंट सिंक्रोनाइज़ करते हैं, कोडबेस की प्रत्येक सहकर्मी की कार्यशील प्रति प्रामाणिक रिपॉजिटरी के लिए अच्छा विश्वास प्रदर्शित करती है।[10] वितरित पुनरीक्षण नियंत्रण सहकर्मी से सहकर्मी पैच (यूनिक्स) (परिवर्तन-सेट) का आदान-प्रदान करके सिंक्रनाइज़ेशन आयोजित करता है। यह केंद्रीकृत प्रणाली से कुछ महत्वपूर्ण अंतरों का परिणाम है:
- कोडबेस की कोई विहित, संदर्भ प्रति डिफ़ॉल्ट रूप से केवल कार्यशील प्रतियाँ सम्मलित नहीं है।
- सामान्य ऑपरेशन (जैसे कि कमिट करना, इतिहास देखना और परिवर्तनों को वापस करना) तेज हैं, क्योंकि केंद्रीय सर्वर के साथ संवाद करने की कोई आवश्यकता नहीं है।[1]: 7
इसके अतिरिक्त, संचार केवल तभी आवश्यक होता है जब परिवर्तन को अन्य साथियों से या उनके पास धकेला या खींचा जाता है।
- प्रत्येक कार्यशील प्रति प्रभावी रूप से कोडबेस और उसके परिवर्तन-इतिहास के दूरस्थ बैकअप के रूप में कार्य करती है, जो डेटा हानि के खिलाफ अंतर्निहित सुरक्षा प्रदान करती है।[1]: 4
सर्वोत्तम अभ्यास
संस्करण नियंत्रण का पूर्ण लाभ प्राप्त करने के लिए सर्वोत्तम अभ्यासों का पालन करना आवश्यक है। सर्वोत्तम अभ्यास संस्करण नियंत्रण उपकरण और उस क्षेत्र के अनुसार भिन्न हो सकते हैं जिस पर संस्करण नियंत्रण लागू किया जाता है। सॉफ्टवेयर विकास में सामान्यतः स्वीकृत सर्वोत्तम प्रथाओं में सम्मलित हैं: वृद्धिशील, छोटे, परिवर्तन करना; कमिट करना जिसमें केवल कार्य या फिक्स सम्मलित है - इसका परिणाम केवल कोड को कमिट करना है जो काम करता है और जानबूझकर सम्मलिता कार्यक्षमता को नहीं तोड़ता है; रिलीज से पहले कार्यक्षमता को पूरा करने के लिए ब्रांचिंग का उपयोग करना; स्पष्ट और वर्णनात्मक प्रतिबद्ध संदेश लिखना, वर्णन या कोड में क्या और कैसे स्पष्ट करें; और सुसंगत ब्रांचिंग रणनीति का उपयोग करना सम्मलित हैं।[11] अन्य सर्वोत्तम सॉफ़्टवेयर विकास अभ्यास जैसे कोड समीक्षा और स्वचालित प्रतिगमन परीक्षण संस्करण नियंत्रण सर्वोत्तम प्रथाओं के अनुसरण में सहायता कर सकते हैं।
लागत और लाभ
लागत और लाभ चुने गए संस्करण नियंत्रण उपकरण और जिस क्षेत्र में इसे लागू किया गया है, उसके आधार पर अलग-अलग होंगे। यह खंड सॉफ्टवेयर विकास के क्षेत्र की बात करता है, जहां संस्करण नियंत्रण व्यापक रूप से लागू होता है।
संस्करण नियंत्रण सॉफ़्टवेयर को लाइसेंस देने की लागत के अतिरिक्त, संस्करण नियंत्रण का उपयोग करने के लिए समय और प्रयास की आवश्यकता होती है। संस्करण नियंत्रण में अंतर्निहित अवधारणाओं को समझा जाना चाहिए और चुने गए संस्करण नियंत्रण सॉफ़्टवेयर को संचालित करने के लिए आवश्यक तकनीकी विवरणों को सीखना चाहिए। संस्करण नियंत्रण सर्वोत्तम प्रथाओं को सीखा जाना चाहिए और संगठन के सम्मलिता सॉफ़्टवेयर विकास प्रथाओं में एकीकृत किया जाना चाहिए। उपयोगी लाभ प्राप्त करने के लिए सर्वोत्तम प्रथाओं का पालन करने के लिए आवश्यक अनुशासन बनाए रखने के लिए प्रबंधन प्रयास की आवश्यकता हो सकती है।
एक मुख्य लाभ इतिहास को बनाए रखने और परिवर्तनों को वापस लाने की क्षमता है, जिससे डेवलपर परिवर्तनों को सरलता से पूर्ववत कर सकता है। यह डेवलपर को प्रयोग करने का अधिक अवसर देता है, जिससे सम्मलिता कोड को तोड़ने का डर समाप्त हो जाता है।[12] ब्रांचिंग के साथ सहायता करता है। सोर्स कोड पैच (कंप्यूटिंग) का ब्रांचिंग और विलय, उत्पादन, पैकेजिंग और लेबलिंग और कोड बेस के लिए पैच का सरल अनुप्रयोग, परिनियोजन प्रक्रिया के विभिन्न चरणों से जुड़े कई कोड बेस के रखरखाव और समवर्ती विकास को सरल करता है; विकास, परीक्षण, मंचन, उत्पादन, आदि।[13] क्षति न्यूनीकरण, जवाबदेही, प्रक्रिया और डिजाइन में सुधार, और संस्करण नियंत्रण द्वारा प्रदान किए गए रिकॉर्ड रखने से जुड़े अन्य लाभ हो सकते हैं, किसने, कब, क्यों और कैसे किया, इसकी ट्रैकिंग।[14] यह अच्छी पुनर्मूल्यांकन की अनुमति देता है कि आगे बढ़ने वाली समस्याओं और समाधानों को संबोधित करने के लिए परिवर्तन क्यों किए गए थे।[15] जब बग उत्पन्न होते हैं, तो यह जानना कि क्या किया गया था जब क्षति न्यूनीकरण और पुनर्प्राप्ति में मदद करता है कि क्या समस्याएँ सम्मलित हैं, वे कितने समय से सम्मलित हैं, और समस्या का दायरा और समाधान निर्धारित करने में सहायता करते हैं।[16] पिछले संस्करणों को स्थापित किया जा सकता है और कोड की परीक्षा और संदेशों को प्रतिबद्ध करने के निष्कर्षों को सत्यापित करने के लिए परीक्षण किया जा सकता है।[17] संस्करण नियंत्रण डिबगिंग को बहुत सरल बना सकता है। कई संस्करणों के लिए परीक्षण स्थिति का अनुप्रयोग उस परिवर्तन की शीघ्रता से पहचान कर सकता है जिसने बग प्रदर्शिक किया था।[18] डेवलपर को संपूर्ण कोड आधार से परिचित होने की आवश्यकता नहीं है और इसके अतिरिक्त समस्या को प्रस्तुत करने वाले कोड पर ध्यान केंद्रित कर सकता है।
संस्करण नियंत्रण कई विधियों से सहयोग को बढ़ाता है। चूंकि संस्करण नियंत्रण परस्पर विरोधी परिवर्तनों की पहचान कर सकता है, अर्थात कोड की समान पंक्तियों में किए गए असंगत परिवर्तन, डेवलपर्स के बीच समन्वय की कम आवश्यकता होती है।[19] कमिट्स, शाखाओं, और सभी संबद्ध प्रतिबद्ध संदेशों और संस्करण लेबलों की पैकेजिंग, डेवलपर्स के बीच पल और समय दोनों में संचार में सुधार करती है।[20] बेहतर संचार, चाहे तत्काल हो या स्थगित, कोड समीक्षा प्रक्रिया, परीक्षण प्रक्रिया और सॉफ्टवेयर विकास प्रक्रिया के अन्य महत्वपूर्ण पहलुओं में सुधार कर सकता है।
एकीकरण
कुछ अधिक उन्नत पुनरीक्षण-नियंत्रण उपकरण कई अन्य सुविधाएं प्रदान करते हैं, जिससे अन्य उपकरणों और सॉफ्टवेयर-अभियांत्रिकी प्रक्रियाओं के साथ गहन एकीकरण की अनुमति मिलती है। प्लग-इन (कंप्यूटिंग) अधिकांशतः औरेकल जेडेवलपर्स (Oracle JDevelopers), इंटेल आईजे आइडिया (IntelliJ IDEA), एक्लिप्स (कंप्यूटिंग), विजुअल स्टूडियो, डेल्फी (प्रोग्रामिंग भाषा), नेट बीन्स, एक्स कोड (Xcode), और जीएनयू ईमैक्स (GNU Emacs) (vc.el के माध्यम से) जैसे एकीकृत विकास परिवेश के लिए उपलब्ध हैं। उन्नत अनुसंधान प्रोटोटाइप उपयुक्त प्रतिबद्ध संदेश उत्पन्न करते हैं,[21] लेकिन यह केवल उन परियोजनाओं पर काम करता है जिनका पहले से ही बड़ा इतिहास है, क्योंकि प्रतिबद्ध संदेश परियोजना के सम्मेलनों और विशिष्टताओं पर बहुत निर्भर हैं।[22]
सामान्य शब्दावली
शब्दावली प्रणाली से प्रणाली में भिन्न हो सकती है, लेकिन सामान्य उपयोग में आने वाली कुछ शर्तों में सम्मलित हैं:[23]
- बेसलाइन (कॉन्फ़िगरेशन प्रबंधन)
- किसी दस्तावेज़ या स्रोत फ़ाइल का स्वीकृत पुनरीक्षण जिसमें बाद में परिवर्तन किए जा सकते हैं। देखें #आधार रेखाएँ, लेबल और टैग|आधार रेखाएँ, लेबल और टैग।
- दोष
- लेखक और संशोधन के लिए खोज जिसने किसी विशेष पंक्ति को अंतिम रूप से संशोधित किया।
- शाखाकरण (पुनरीक्षण नियंत्रण)
- संस्करण नियंत्रण के अनुसार फाइलों का सेट समय पर बिंदु पर शाखाबद्ध या फोर्क किया जा सकता है, जिससे कि उस समय से आगे, उन फाइलों की दो प्रतियां अलग-अलग गति से या अलग-अलग विधियों से एक-दूसरे से स्वतंत्र रूप से विकसित हो सकें।
- परिवर्तन
- एक परिवर्तन (या अंतर, या डेल्टा एन्कोडिंग) संस्करण नियंत्रण के अनुसार दस्तावेज़ में विशिष्ट संशोधन का प्रतिनिधित्व करता है। परिवर्तन माने जाने वाले संशोधन की ग्रैन्युलैरिटी संस्करण नियंत्रण प्रणालियों के बीच भिन्न होती है।
- परिवर्तन सूची
- परमाणु लेनदेन बहु-परिवर्तन के साथ कई संस्करण नियंत्रण प्रणालियों पर, परिवर्तन सूची (या सीएल), परिवर्तन सेट, अद्यतन, या पैच (कंप्यूटिंग) ही प्रतिबद्धता में किए गए परिवर्तनों के सेट की पहचान करता है। यह स्रोत कोड के अनुक्रमिक दृश्य का भी प्रतिनिधित्व कर सकता है, जिससे स्रोत की परीक्षा किसी विशेष चेंजलिस्ट आईडी के रूप में हो सकती है।
- चेकआउट
- चेक आउट (या सह) करने के लिए रिपॉजिटरी से स्थानीय कामकाजी प्रति बनाना है। उपयोगकर्ता विशिष्ट संशोधन निर्दिष्ट कर सकता है या नवीनतम प्राप्त कर सकता है। वर्किंग कॉपी का वर्णन करने के लिए 'चेकआउट' शब्द को संज्ञा के रूप में भी उपयोग किया जा सकता है। जब किसी फ़ाइल को किसी साझा फ़ाइल सर्वर से चेक आउट किया गया है, तो इसे अन्य उपयोगकर्ताओं द्वारा संपादित नहीं किया जा सकता है। इसे होटल की तरह समझें, जब आप चेक आउट करते हैं, तो आपकी सुविधाओं तक पहुंच नहीं होती है।
- क्लोन
- क्लोनिंग का अर्थ है रिपॉजिटरी बनाना जिसमें किसी अन्य रिपॉजिटरी से संशोधन सम्मलित हैं। यह खाली (नए आरंभिक) रिपॉजिटरी में धकेलने या खींचने के बराबर है। संज्ञा के रूप में, दो रिपॉजिटरी को क्लोन कहा जा सकता है यदि उन्हें सिंक्रनाइज़ रखा जाता है, और समान संशोधन होते हैं।
- चेंजसेट (संज्ञा)
- 'प्रतिबद्ध' या 'संशोधन' (एसवीएन) संशोधन है जो रिपॉजिटरी पर लागू होता है।
- प्रतिबद्ध (संशोधन नियंत्रण) (क्रिया)
- प्रतिबद्ध करने के लिए (चेक इन, सीआई या, शायद ही कभी, स्थापित करें, जमा करें या रिकॉर्ड करें) कार्यशील प्रति में किए गए परिवर्तनों को रिपॉजिटरी में वापस लिखना या विलय करना है। कमिट में मेटाडेटा, सामान्यतः लेखक की जानकारी और प्रतिबद्ध संदेश होता है जो परिवर्तन का वर्णन करता है।
- कमिट संदेश
- कमिट के साथ संग्रहीत डेवलपर द्वारा लिखित संक्षिप्त नोट, जो कमिट का वर्णन करता है। आदर्श रूप से, यह रिकॉर्ड करता है कि संशोधन क्यों किया गया था, संशोधन के प्रभाव या उद्देश्य का विवरण, और परिवर्तन कैसे काम करता है, इसके स्पष्ट पहलू।
- संघर्ष
- एक विरोध तब होता है जब विभिन्न पक्ष ही दस्तावेज़ में परिवर्तन करते हैं, और प्रणाली परिवर्तनों का समाधान करने में असमर्थ होता है। उपयोगकर्ता को परिवर्तनों को मिलाकर, या दूसरे के पक्ष में परिवर्तन का चयन करके विरोध का समाधान करना चाहिए।
- डेल्टा संपीड़न
- अधिकांश पुनरीक्षण नियंत्रण सॉफ़्टवेयर डेल्टा संपीड़न का उपयोग करता है, जो फ़ाइलों के क्रमिक संस्करणों के बीच केवल अंतर को बनाए रखता है। यह फ़ाइलों के कई अलग-अलग संस्करणों के अधिक कुशल भंडारण की अनुमति देता है।
- डायनेमिक स्ट्रीम
- एक स्ट्रीम जिसमें कुछ या सभी फ़ाइल संस्करण पैरेंट स्ट्रीम के संस्करणों के दर्पण होते हैं।
- निर्यात
- निर्यात रिपॉजिटरी से फाइलों को प्राप्त करने का कार्य है। यह चेक आउट के समान है, सिवाय इसके कि यह वर्किंग कॉपी में उपयोग किए गए वर्जन-कंट्रोल मेटाडेटा के बिना क्लीन डायरेक्टरी ट्री बनाता है। यह अधिकांशतः सामग्री प्रकाशित करने से पहले उपयोग किया जाता है, उदाहरण के लिए
- लायें
- पुल देखें।
- आगे एकीकरण
- मुख्य ट्रंक में किए गए परिवर्तनों को विकास (फीचर या टीम) शाखा में विलय करने की प्रक्रिया।
- सिर
- कभी-कभी टिप भी कहा जाता है, यह सबसे हालिया प्रतिबद्धता को संदर्भित करता है, या तो ट्रंक या शाखा में। ट्रंक और प्रत्येक शाखा का अपना सिर होता है, चूंकि हेड को कभी-कभी ट्रंक को संदर्भित करने के लिए उपयोग किया जाता है।[24]
- आयात
- आयात पहली बार रिपॉजिटरी में स्थानीय निर्देशिका ट्री (जो कि वर्तमान में कार्यशील प्रति नहीं है) को कॉपी करने का कार्य है।
- प्रारंभ करें
- एक नया, खाली रिपॉजिटरी बनाने के लिए।
- इंटरलीव्ड डेल्टास
- कुछ रिवीजन कंट्रोल सॉफ्टवेयर इंटरलीव्ड डेल्टास का उपयोग करता है, ऐसी विधि जो टेक्स्ट आधारित फाइलों के इतिहास को डेल्टा कम्प्रेशन का उपयोग करने की तुलना में अधिक कुशल तरीके से संग्रहीत करने की अनुमति देती है।
- लेबल
- टैग देखें।
- फ़ाइल लॉकिंग
- जब कोई डेवलपर किसी फ़ाइल को लॉक करता है, तो कोई भी उस फ़ाइल को तब तक अपडेट नहीं कर सकता जब तक कि वह अनलॉक न हो जाए। लॉकिंग को संस्करण नियंत्रण प्रणाली, या डेवलपर्स (उर्फ सोशल लॉकिंग) के बीच अनौपचारिक संचार के माध्यम से समर्थित किया जा सकता है।
- मेनलाइन
- ट्रंक के समान, लेकिन प्रत्येक शाखा के लिए मेनलाइन हो सकती है।
- विलय (पुनरीक्षण नियंत्रण)
- एक विलय या एकीकरण ऑपरेशन है जिसमें फ़ाइल या फाइलों के सेट पर परिवर्तन के दो सेट लागू होते हैं। कुछ नमूना परिदृश्य इस प्रकार हैं:
- * उपयोगकर्ता, फाइलों के सेट पर काम कर रहा है, अन्य उपयोगकर्ताओं द्वारा किए गए परिवर्तनों के साथ उनकी कार्यशील प्रति को अपडेट या सिंक करता है, और रिपॉजिटरी में चेक किया जाता है।[25]
- एक उपयोगकर्ता उन फ़ाइलों की जाँच करने का प्रयास करता है जिन्हें फ़ाइलों की जाँच के बाद से दूसरों द्वारा अपडेट किया गया है, और संशोधन नियंत्रण सॉफ़्टवेयर स्वचालित रूप से फ़ाइलों को मर्ज कर देता है (सामान्यतः, उपयोगकर्ता को संकेत देने के बाद कि क्या इसे स्वचालित मर्ज के साथ आगे बढ़ना चाहिए, और कुछ में स्थिति केवल ऐसा कर रहे हैं यदि विलय स्पष्ट रूप से और उचित रूप से हल किया जा सकता है)।
- एक शाखा बनाई जाती है, फाइलों में कोड स्वतंत्र रूप से संपादित किया जाता है, और अद्यतन शाखा को बाद में एकल, एकीकृत ट्रंक में सम्मलित किया जाता है।
- * फाइलों का सेट ब्रांच किया गया है, शाखा में ब्रांचिंग से पहले सम्मलित समस्या को ठीक किया गया है, और फ़िक्स को फिर दूसरी शाखा में मिला दिया गया है। (इस प्रकार के चयनात्मक विलय को कभी-कभी पिछले स्थिति में पूर्ण विलय से अलग करने के लिए चेरी पिक के रूप में जाना जाता है।)
- प्रचार करें
- फ़ाइल सामग्री को कम नियंत्रित स्थान से अधिक नियंत्रित स्थान में कॉपी करने का कार्य। उदाहरण के लिए, उपयोगकर्ता के कार्यक्षेत्र से रिपॉजिटरी में, या स्ट्रीम से उसके पैरेन्ट्स तक।[26]
- खींचो, धक्का दो
- एक रिपॉजिटरी से दूसरे में संशोधन कॉपी करें। पुल रिसीविंग रिपॉजिटरी द्वारा शुरू किया जाता है, जबकि स्रोत द्वारा पुश शुरू किया जाता है। फ़ेच का उपयोग कभी-कभी पुल के पर्याय के रूप में किया जाता है, या इसका अभिप्राय यह है कि पुल के बाद अपडेट होता है।
- पुल अनुरोध
- एक डेवलपर दूसरों से उनके पुश किए गए परिवर्तनों को मर्ज करने के लिए कह रहा है।
- रिपॉजिटरी (संस्करण नियंत्रण)
- रिपॉजिटरी (या रेपो) वह जगह है जहां फाइलों का वर्तमान और ऐतिहासिक डेटा संग्रहीत किया जाता है, अधिकांशतः सर्वर पर। कभी-कभी डिपो भी कहा जाता है।
- हल करें
- एक ही दस्तावेज़ में विभिन्न परिवर्तनों के बीच विरोध को संबोधित करने के लिए उपयोगकर्ता के हस्तक्षेप का कार्य।
- रिवर्स इंटीग्रेशन
- विभिन्न टीम शाखाओं को वर्जनिंग प्रणाली के मुख्य ट्रंक में मर्ज करने की प्रक्रिया।
- पुनरीक्षण
- इसके अतिरिक्त संस्करण: सॉफ्टवेयर संस्करण किसी भी रूप में परिवर्तन है। एसवीके में, रिपॉजिटरी में पूरे पेड़ के समय में संशोधन स्थिति है।
- साझा करें
- एक ही समय में फ़ाइल या फ़ोल्डर को कई शाखाओं में उपलब्ध कराने का कार्य। जब साझा फ़ाइल को शाखा में बदला जाता है, तो इसे अन्य शाखाओं में बदल दिया जाता है।
- स्ट्रीम
- ब्रांच्ड फाइलों के लिए कंटेनर जिसका ऐसे अन्य कंटेनरों से संबंध ज्ञात है। धाराएँ पदानुक्रम बनाती हैं; प्रत्येक धारा अपनी मूल धारा से विभिन्न गुण (जैसे संस्करण, नामस्थान, कार्यप्रवाह नियम, ग्राहक, आदि) प्राप्त कर सकती है।
- पुनरीक्षण टैग
- एक टैग या लेबल समय में महत्वपूर्ण स्नैपशॉट को संदर्भित करता है, जो कई फाइलों में संगत होता है। उस बिंदु पर इन फ़ाइलों को उपयोगकर्ता के अनुकूल, सार्थक नाम या संशोधन संख्या के साथ टैग किया जा सकता है।आधार रेखाएँ, लेबल और टैग या आधार रेखाएँ, लेबल और टैग देखें ।
- ट्रंक (सॉफ्टवेयर)
- विकास की अनूठी रेखा जो शाखा नहीं है (कभी-कभी इसे बेसलाइन, मेनलाइन या मास्टर भी कहा जाता है)[27][28])
- अपडेट
- एक अपडेट (या सिंक, लेकिन सिंक का मतलब संयुक्त पुश और पुल भी हो सकता है) रिपॉजिटरी में किए गए बदलावों (उदाहरण के लिए, अन्य लोगों द्वारा) को स्थानीय वर्किंग कॉपी में मर्ज कर देता है। अद्यतन कुछ सीएम टूल्स (सीएम +, पीएलएस, एसएमएस) द्वारा परिवर्तन पैकेज अवधारणा के लिए उपयोग किया जाने वाला शब्द भी है (परिवर्तन सूची देखें)। पुनरीक्षण नियंत्रण प्रणालियों में चेकआउट का पर्यायवाची जिसके लिए प्रत्येक रिपॉजिटरी में ठीक कार्यशील प्रति (वितरित प्रणालियों में सामान्य) की आवश्यकता होती है
- ताला खोलना
- ताला खोलना।
- वर्किंग कॉपी
- वर्किंग कॉपी विशिष्ट समय या संशोधन पर रिपॉजिटरी से फाइलों की स्थानीय कॉपी होती है। रिपॉजिटरी में फाइलों पर किए गए सभी काम शुरू में वर्किंग कॉपी पर किए जाते हैं, इसलिए यह नाम है। संकल्पनात्मक रूप से, यह सैंडबॉक्स (सॉफ्टवेयर विकास) है।
यह भी देखें
टिप्पणियाँ
- ↑ In this case, edit buffers are a secondary form of working copy, and not referred to as such.
- ↑ In principle two revisions can have identical timestamp, and thus cannot be ordered on a line. This is generally the case for separate repositories, though is also possible for simultaneous changes to several branches in a single repository. In these cases, the revisions can be thought of as a set of separate lines, one per repository or branch (or branch within a repository).
- ↑ The revision or repository "tree" should not be confused with the directory tree of files in a working copy.
- ↑ Note that if a new branch is based on HEAD, then topologically HEAD is no longer a tip, since it has a child.
- ↑ "Mainline" can also refer to the main path in a separate branch.
संदर्भ
- ↑ 1.0 1.1 1.2 O'Sullivan, Bryan (2009). Mercurial: निश्चित गाइड. Sebastopol: O'Reilly Media, Inc. ISBN 9780596555474. Retrieved 4 September 2015.
- ↑ Scott, Chacon; Straub, Ben (2014). प्रो गिट दूसरा संस्करण (in English). United States: Apress. p. 14.
- ↑ "Google Docs", See what's changed in a file, Google Inc..
- ↑ Rochkind, Marc J. (1975). "स्रोत कोड नियंत्रण प्रणाली" (PDF). IEEE Transactions on Software Engineering. SE-1 (4): 364–370. doi:10.1109/TSE.1975.6312866. S2CID 10006076.
- ↑ Tichy, Walter F. (1985). "आरसीएस - संस्करण नियंत्रण के लिए एक प्रणाली". Software: Practice and Experience. 15 (7): 637–654. doi:10.1002/spe.4380150703. ISSN 0038-0644. S2CID 2605086.
- ↑ Collins-Sussman, Ben; Fitzpatrick, BW; Pilato, CM (2004), Version Control with Subversion, O'Reilly, ISBN 0-596-00448-6
- ↑ Loeliger, Jon; McCullough, Matthew (2012). गिट के साथ संस्करण नियंत्रण: सहयोगी सॉफ्टवेयर विकास के लिए शक्तिशाली उपकरण और तकनीकें. O'Reilly Media. pp. 2–5. ISBN 9781449345044.
- ↑ For Engineering drawings, see Whiteprint#Document control, for some of the manual systems in place in the twentieth century, for example, the Engineering Procedures of Hughes Aircraft, each revision of which required approval by Lawrence A. Hyland; see also the approval procedures instituted by the U.S. government.
- ↑ Smart, John Ferguson (2008). जावा पावर टूल्स (in English). "O'Reilly Media, Inc.". p. 301. ISBN 9781491954546. Retrieved 20 July 2019.
- ↑ Wheeler, David. "ओपन सोर्स सॉफ्टवेयर / फ्री सॉफ्टवेयर (OSS/FS) सॉफ्टवेयर कॉन्फ़िगरेशन मैनेजमेंट (SCM) सिस्टम पर टिप्पणियाँ". Archived from the original on November 9, 2020. Retrieved May 8, 2007.
- ↑ GitLab. "गिट संस्करण नियंत्रण सर्वोत्तम अभ्यास क्या हैं?". gitlab.com. Retrieved 2022-11-11.
- ↑ Alessandro Picarelli (2020-11-17). "संस्करण नियंत्रण का उपयोग नहीं करने की लागत". Retrieved 2022-11-18.
कार्य घंटों के संदर्भ में यह आपको 6 से 48 गुना अधिक खर्च करने वाला है, जो कि संस्करण नियंत्रण का उपयोग करने में आपकी लागत होगी, और यह एक एकल डेवलपर के लिए कुछ मॉडलों को रिवाइंड करने के लिए है।
- ↑ Irma Azarian (2023-06-14). "सॉफ़्टवेयर संस्करण नियंत्रण की समीक्षा: सिस्टम, लाभ, और यह क्यों मायने रखता है". Retrieved 2022-11-18.
संस्करण नियंत्रण प्रणाली आपको फ़ाइलों की तुलना करने, अंतरों की पहचान करने और किसी भी कोड को जमा करने से पहले यदि आवश्यक हो तो परिवर्तनों को मर्ज करने की अनुमति देती है। वर्ज़निंग भी एप्लिकेशन बिल्ड का ट्रैक रखने का एक शानदार तरीका है, यह पहचानने में सक्षम है कि वर्तमान में कौन सा संस्करण विकास, क्यूए और उत्पादन में है।
- ↑ ReQtest (2020-10-26). "संस्करण नियंत्रण के क्या लाभ हैं?". Retrieved 2022-11-21.
दस्तावेज़ का इतिहास लेखक और संपादन की तारीख के बारे में अमूल्य जानकारी प्रदान करता है। यह किए गए परिवर्तनों के उद्देश्य पर भी देता है। इसका नवीनतम संस्करण पर काम करने वाले डेवलपर पर प्रभाव पड़ेगा क्योंकि यह पिछले संस्करणों में अनुभव की गई समस्याओं को हल करने में मदद करेगा। दस्तावेज़ के लेखक की पहचान करने की क्षमता वर्तमान टीम को दस्तावेज़ों को विशिष्ट योगदानकर्ताओं से लिंक करने में सक्षम बनाती है। बदले में, यह वर्तमान टीम को उन पैटर्नों को उजागर करने में सक्षम बनाता है जो बग्स को ठीक करने में मदद कर सकते हैं। यह सॉफ़्टवेयर की समग्र कार्यप्रणाली को बेहतर बनाने में मदद करेगा।
- ↑ Sara A. Metwalli (2020-10-14). "संस्करण नियंत्रण 101: परिभाषा और लाभ". Retrieved 2022-11-18.
इसके अलावा, यदि समय के साथ, किसी विशेष सुविधा को जोड़ने से परियोजना का विस्तार या विस्तार करने में कठिनाई होती है, तो संस्करण नियंत्रण का उपयोग करने से डेवलपर उस विशेष सुविधा को ट्रैक कर सकते हैं और परियोजना की कार्यक्षमता को प्रभावित किए बिना इसे बदल सकते हैं या हटा सकते हैं।
- ↑ Chiradeep BasuMallick (2022-10-06). "संस्करण नियंत्रण क्या है? अर्थ, उपकरण और लाभ". Retrieved 2022-11-18.
सॉफ़्टवेयर टीमें कोड समीक्षाओं के माध्यम से पिछले संस्करणों की जांच करके समाधान के विकास को समझ सकती हैं।
- ↑ Chiradeep BasuMallick (2022-10-06). "संस्करण नियंत्रण क्या है? अर्थ, उपकरण और लाभ". Retrieved 2022-11-18.
यदि कोई त्रुटि हो जाती है, तो डेवलपर समय पर वापस जा सकते हैं और टीम के सभी सदस्यों के लिए गड़बड़ी को कम करते हुए गलती को दूर करने के लिए कोड के पूर्व पुनरावृत्तियों की समीक्षा कर सकते हैं।
- ↑ Chacon, Scott; Straub, Ben (2022-10-03). "गिट के लिए" (Version 2.1.395-2-g27002dd ed.). Apress. Retrieved 2022-11-18.
गिट बिसेक्ट टूल एक अविश्वसनीय रूप से सहायक डिबगिंग टूल है जिसका उपयोग यह पता लगाने के लिए किया जाता है कि स्वचालित बाइनरी खोज करके बग या समस्या को पेश करने वाला पहला कौन सा विशिष्ट कमिट था।
- ↑ Irma Azarian (2023-06-14). "सॉफ़्टवेयर संस्करण नियंत्रण की समीक्षा: सिस्टम, लाभ, और यह क्यों मायने रखता है". Retrieved 2022-11-18.
वर्जनिंग एक अनमोल प्रक्रिया है, खासकर तब जब आपके पास एक ही एप्लिकेशन पर कई डेवलपर काम कर रहे हों, क्योंकि यह उन्हें आसानी से फाइल साझा करने की अनुमति देता है। संस्करण नियंत्रण के बिना, डेवलपर्स अंततः एक दूसरे के पैर की उंगलियों पर कदम रखेंगे और कोड परिवर्तनों को अधिलेखित कर देंगे जो किसी और ने इसे साकार किए बिना भी पूरा किया हो। इन प्रणालियों का उपयोग करने से आप संशोधनों के लिए फ़ाइलों की जांच कर सकते हैं, फिर, चेक-इन के दौरान, यदि फ़ाइलें किसी अन्य उपयोगकर्ता द्वारा बदली गई हैं, तो आपको सतर्क किया जाएगा और उन्हें मर्ज करने की अनुमति दी जाएगी।
- ↑ Jesse Phillips (2019-01-21) [2018-12-12]. "गिट एक संचार उपकरण है". Retrieved 2022-11-18.
रीबेस, मर्ज, और/या स्क्वैश का उपयोग करने पर चर्चा जारी है। मैं संचार करते हुए इन सभी विकल्पों के बिंदु पर ध्यान केंद्रित करना चाहता हूं।
- ↑ Cortes-Coy, Luis Fernando; Linares-Vasquez, Mario; Aponte, Jairo; Poshyvanyk, Denys (2014). "On Automatically Generating Commit Messages via Summarization of Source Code Changes". स्रोत कोड विश्लेषण और हेरफेर पर 2014 IEEE 14वां अंतर्राष्ट्रीय कार्य सम्मेलन. IEEE. pp. 275–284. doi:10.1109/scam.2014.14. ISBN 978-1-4799-6148-1. S2CID 360545.
- ↑ Etemadi, Khashayar; Monperrus, Martin (2020-06-27). "On the Relevance of Cross-project Learning with Nearest Neighbours for Commit Message Generation". सॉफ्टवेयर इंजीनियरिंग कार्यशालाओं पर IEEE/ACM 42वें अंतर्राष्ट्रीय सम्मेलन की कार्यवाही (in English). Seoul, Republic of Korea: ACM. pp. 470–475. arXiv:2010.01924. doi:10.1145/3387940.3391488. ISBN 9781450379632. S2CID 221911386.
- ↑ Wingerd, Laura (2005). प्रैक्टिकल परफोर्स. O'Reilly. ISBN 0-596-10185-6. Archived from the original on 2007-12-21. Retrieved 2006-08-27.
- ↑ Gregory, Gary (February 3, 2011). "वर्जन कंट्रोल सिस्टम में ट्रंक बनाम हेड". Java, Eclipse, and other tech tidbits. Retrieved 2012-12-16.
- ↑ Collins-Sussman, Fitzpatrick & Pilato 2004, 1.5: SVN tour cycle resolve: ‘The G stands for merGed, which means that the file had local changes to begin with, but the changes coming from the repository didn't overlap with the local changes.’
- ↑ अवधारणा मैनुअल (Version 4.7 ed.). Accurev. July 2008.
- ↑ Wallen, Jack (2020-09-22). "अक्टूबर में शुरू होने वाले मुख्य के साथ मास्टर को बदलने के लिए गिटहब: डेवलपर्स को अब क्या करने की आवश्यकता है". TechRepublic. Retrieved 2022-04-24.
- ↑ Heinze, Carolyn (2020-11-24). "GitHub ने अपनी मास्टर ब्रांच का नाम बदलकर main क्यों कर दिया". TheServerSide. Retrieved 2022-04-24.
बाहरी कड़ियाँ
- "Visual Guide to Version Control", Better explained.
- Sink, Eric, "Source Control", SCM (how‐to). The basics of version control.
श्रेणी:संस्करण नियंत्रण प्रणाली श्रेणी:तकनीकी संचार श्रेणी: सॉफ्टवेयर विकास प्रक्रिया श्रेणी: वितरित संस्करण नियंत्रण प्रणाली
