संस्करण नियंत्रण प्रणाली - कौन सा बेहतर है? संस्करण नियंत्रण प्रणाली गिट, एसवीएन और अन्य, तुलना। क्या हुआ है

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

सरल शब्दों में, परिष्कृत एप्लिकेशन का उपयोग करना कठिन था। इसलिए, मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी की प्रयोगशाला में, उन्होंने सुधार किया और सभी "समस्याग्रस्त तत्वों" को काट दिया (आखिरकार, जो एक के लिए समस्या है वह आसानी से दूसरे के लिए एक फायदा हो सकता है)। उन्नत एवं सरलीकृत संस्करण को गिटलेस कहा गया। इसे Git से संबंधित 2,400 प्रश्नों को ध्यान में रखते हुए विकसित किया गया था और StackOverflow डेवलपर साइट से लिया गया था।

गिट में क्या खराबी है?

उदाहरण

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

पिछले संस्करण के साथ बुनियादी कार्यों की संक्षिप्त तुलना

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

स्टेजिंग फ़ंक्शन फ़ाइल में किए गए परिवर्तनों को अनुक्रमित करता है। यदि आप फ़ाइलों को चरणबद्ध चिह्नित करते हैं, तो Git समझता है कि आपने उन्हें चेकआउट के लिए चरणबद्ध कर दिया है।

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

गिटलेस गाइड के लेखक की रिपोर्ट है कि शाखाओं के बीच स्विच करते समय समस्या उत्पन्न होती है। यह याद रखना मुश्किल हो सकता है कि कौन सा सामान कहां जाता है। खैर, इन सबसे ऊपर यह है कि यदि आप विलय की प्रक्रिया में हैं, जिसमें परस्पर विरोधी फ़ाइलें शामिल हैं, तो फ़ंक्शन मदद नहीं करता है। यह पेरेज़ डी रोसो की राय है.

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

बचत परिवर्तन

इसके अलावा, आप किसी भी फ़ाइल के वर्गीकरण को इसमें बदल सकते हैं: मॉनिटर किया हुआ, अनट्रैक किया हुआ, या अनदेखा किया हुआ। इससे कोई फर्क नहीं पड़ता कि यह फ़ाइल हेडर में मौजूद है या नहीं।

विकास प्रक्रियाओं की शाखाएँ

सीधे शब्दों में कहें तो, Gitless के साथ आपको उन अनियंत्रित परिवर्तनों के बारे में याद रखने की ज़रूरत नहीं है जो लक्ष्य शाखा में परिवर्तनों के साथ टकराव करते हैं।

यदि आप किसी विलय या फ़्यूज़ के बीच में हैं तो आप संघर्ष की स्थिति का समाधान भी स्थगित कर सकते हैं। जब तक आप वापस नहीं लौटेंगे तब तक संघर्ष बना रहेगा।

दूरस्थ रिपॉजिटरी के साथ कार्य करना

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

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

नतीजा क्या हुआ?

प्रोजेक्ट बनाने के लिए कठोर तरीकों का उपयोग किया गया सॉफ़्टवेयर. दुनिया भर में सबसे व्यापक रूप से उपयोग किए जाने वाले सॉफ़्टवेयर प्रोजेक्टों में से एक में कमियों की पहचान करना आवश्यक है। अतीत में, कई उपयोगकर्ताओं ने Git के पक्ष और विपक्ष में मज़ेदार तर्क दिए हैं, लेकिन उनमें से कोई भी वैज्ञानिक दृष्टिकोण पर आधारित नहीं था।

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

हम लगातार अंदर हैं सामान्य रूपरेखा, हम नियंत्रण प्रणालियों की विशेषताओं का विश्लेषण करेंगे, उनकी वास्तुकला और प्रश्न में एप्लिकेशन की मुख्य विशेषताओं के बारे में बात करेंगे। इसके अलावा, हम Git के साथ काम करने के लिए वर्तमान में मौजूदा इंटरफेस की समीक्षा करेंगे।

लेखक आपको स्पष्ट, स्पष्ट और सामान्य तस्वीर प्रस्तुत करने के लिए जानबूझकर कार्यों, कुंजियों और अन्य सूक्ष्मताओं की शब्दावली को छोड़ देता है। यह आलेख मानता है कि पाठक यूनिक्स जैसे ऑपरेटिंग सिस्टम (ओएस) से परिचित है और है भी बुनियादी ज्ञानसामान्य तौर पर एल्गोरिथमिक्स और कंप्यूटर विज्ञान के क्षेत्र में।

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

2. गिट है...

Git एक वितरित फ़ाइल संस्करण नियंत्रण प्रणाली है। प्रोग्राम कोड मुख्य रूप से सी में लिखा गया है। यह प्रोजेक्ट विकास को प्रबंधित करने के लिए 2005 में लिनस टोरवाल्ड्स द्वारा बनाया गया था लिनक्स कर्नेलऔर, जीएनयू/लिनक्स की तरह, मुफ़्त सॉफ़्टवेयर (सॉफ़्टवेयर) है, जबकि तीसरे पक्ष का उपयोगजीएनयू जीपीएल लाइसेंस संस्करण 2 के अधीन है। संक्षेप में, इस समझौते को मुफ्त कोड सॉफ़्टवेयर के रूप में वर्णित किया जा सकता है जिसे खुले तौर पर विकसित किया जाना चाहिए, अर्थात। किसी भी प्रोग्रामर को किसी भी स्तर पर प्रोजेक्ट में सुधार जारी रखने का अधिकार है। अपने अल्प अस्तित्व के दौरान यह प्रणालीकई प्रमुख डेवलपर्स द्वारा पेश किया गया है। Git का उपयोग लिनक्स समुदाय में गनोम, जीएनयू कोर यूटिलिटीज, वीएलसी, काहिरा, पर्ल, क्रोमियम, वाइन जैसे प्रोजेक्ट में किया जाता है।

3. संस्करण नियंत्रण प्रणाली

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

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

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

4. वितरित संस्करण नियंत्रण प्रणालियों के बीच अंतर

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

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

5. Git की मुख्य विशेषताएँ एवं विशेषताएँ

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

Git की एक विशेष विशेषता यह है कि प्रोजेक्ट संस्करणों पर कार्य कालानुक्रमिक क्रम में नहीं हो सकता है। विकास कई समानांतर शाखाओं में किया जा सकता है, जो डिज़ाइन प्रक्रिया के दौरान किसी भी समय विलय और विभाजित हो सकते हैं।

Git एक काफी लचीली प्रणाली है, और इसके अनुप्रयोग का दायरा केवल विकास तक ही सीमित नहीं है। उदाहरण के लिए, पत्रकार, तकनीकी साहित्य के लेखक, प्रशासक और विश्वविद्यालय के शिक्षक अपने कार्य क्षेत्र में इसका अच्छी तरह से उपयोग कर सकते हैं। इन कार्यों में किसी दस्तावेज़, रिपोर्ट या होमवर्क का संस्करण नियंत्रण शामिल है।

आइए हम Git और अन्य वितरित और केंद्रीकृत प्रबंधन प्रणालियों के बीच मुख्य अंतर पर प्रकाश डालें।

गिट वास्तुकला

SHA1 (सिक्योर हैश एल्गोरिथम 1) एक क्रिप्टोग्राफ़िक हैशिंग एल्गोरिथम है। प्रत्येक Git प्रोजेक्ट फ़ाइल में एक नाम और सामग्री होती है। नाम डेटा के पहले 20 बाइट्स है, यह हेक्साडेसिमल संख्या प्रणाली में चालीस अक्षरों में स्पष्ट रूप से लिखा गया है। यह कुंजी फ़ाइल की सामग्री को हैश करके प्राप्त की जाती है। इसलिए, उदाहरण के लिए, दो नामों की तुलना करके, हम लगभग सौ प्रतिशत संभावना के साथ कह सकते हैं कि उनकी सामग्री समान है। साथ ही, विभिन्न शाखाओं (रिपॉजिटरी) में समान वस्तुओं के नाम समान हैं, जो आपको डेटा के साथ सीधे काम करने की अनुमति देता है। एक अच्छा जोड़उपरोक्त इस तथ्य से भी समर्थित है कि हैश आपको सटीक रूप से यह निर्धारित करने की अनुमति देता है कि फ़ाइलें क्षतिग्रस्त हैं या नहीं। उदाहरण के लिए, सामग्री के हैश की तुलना नाम से करके, हम काफी सटीकता से कह सकते हैं कि डेटा दूषित है या नहीं। निम्नलिखित में, नाम से हमारा तात्पर्य फ़ाइल नाम से होगा, और वर्णों की स्ट्रिंग को SHA1 हैश कहा जाएगा।

यह तथाकथित टकरावों का उल्लेख करने योग्य है। "भ्रष्टाचार का बिल्कुल सटीक पता लगाना" का अर्थ है कि ऐसी फ़ाइलें हैं, जिनकी सामग्री अलग-अलग है, जिनका SHA1 हैश समान है। ऐसी टक्करों की संभावना बहुत कम है, और प्रारंभिक आकलन 2 से -80वीं शक्ति (~10 से -25वीं शक्ति) के बराबर है। चूँकि, इसका कोई सटीक अनुमान नहीं है इस पलअंतर्राष्ट्रीय समुदाय इस क्रिप्टोग्राफ़िक योजना को प्रभावी ढंग से समझने में सक्षम नहीं है।

गिट ऑब्जेक्ट्स

Git में फ़ाइल संस्करणों के साथ काम करने की तुलना सामान्य ऑपरेशन से की जा सकती है फ़ाइल सिस्टमआउच. संरचना में चार प्रकार की वस्तुएं होती हैं: ब्लॉब, ट्री, कमिट और संदर्भ; उनमें से कुछ, बदले में, उप-वस्तुओं में विभाजित हैं।

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

पेड़

• स्वयं का SHA1 हैश;
• बूँदों और/या पेड़ों का SHA1 हैश;
• यूनिक्स सिस्टम के पहुँच अधिकार;
• प्रतीकात्मक वस्तु का नाम (के लिए नाम) आंतरिक उपयोगसिस्टम में)।

इसके मूल में, एक वस्तु एक निर्देशिका के अनुरूप होती है। यह प्रोजेक्ट फ़ाइलों के पदानुक्रम को परिभाषित करता है।

प्रतिबद्ध- एक डेटा प्रकार जिसमें शामिल है:

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

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

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

लिंक से, बदले में, हम कई उप-वस्तुओं को अलग कर सकते हैं जिनमें कुछ अंतर हैं: शाखा, टैग। आइए उन पर नजर डालें.

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

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

• पहले भाग में अपना स्वयं का SHA1 हैश शामिल है;
• दूसरे भाग में शामिल हैं:
  • एनोटेट टैग द्वारा इंगित वस्तु का SHA1;
  • संदर्भित वस्तु का प्रकार (ब्लॉब, ट्री, कमिट, या टैग);
  • प्रतीकात्मक टैग नाम;
  • टैग निर्माण की तिथि और समय;
  • टैग निर्माता का नाम और ईमेल;
  • डेटा का एक मनमाना टुकड़ा (इस ब्लॉक का उपयोग इलेक्ट्रॉनिक हस्ताक्षर के लिए या किसी टैग को समझाने के लिए किया जा सकता है)।

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

आइए डेटा भंडारण के क्षण को स्पष्ट करें। फ़ाइल सामग्री विभिन्न संस्करणकालक्रम में यह काफी अधिक मेमोरी लेता है। इसलिए, उदाहरण के लिए, बीस संस्करणों की बीस फ़ाइलों की एक परियोजना में, संग्रह का वजन 20 गुना अधिक (शायद लगभग सौ मेगाबाइट) होगा, लेकिन क्या होगा यदि दोनों की संख्या 10 गुना अधिक हो (यह बहुत अधिक नहीं लगता है)? अधिग्रहीत स्थान का आकार 100 गुना (अर्थात लगभग 1 जीबी) बढ़ जाएगा। में वास्तविक समस्याएँअधिगृहीत स्मृति की वृद्धि दर समय पर रैखिक रूप से निर्भर होने से बहुत दूर है। इस समस्या को हल करने के लिए कई अनुकूलन हैं:

• प्रत्येक Git ऑब्जेक्ट को एक नियमित संग्रह (tar.gz) के रूप में संग्रहीत किया जाता है;
• अनुक्रमिक डेल्टा संपीड़न संपूर्ण फ़ाइल पदानुक्रम पर लागू होता है।

आइए इसे एक उदाहरण से देखें.

आपके पास अपने प्रोजेक्ट का तीन साल का इतिहास है, जिसमें लगभग एक हजार फ़ाइलें और सौ संस्करण हैं। यदि किसी बिंदु पर आपको स्वयं से संपर्क करने की आवश्यकता पड़े प्रारंभिक संस्करण, Git को फ़ाइल के संपूर्ण इतिहास को डेल्टा-संपीड़ित करना होगा। निराशाजनक बात यह है कि इस प्रक्रिया में दोपहर तक का समय लग सकता है। Git तथाकथित चौकियाँ करने की पेशकश करता है, अर्थात। एक गैर-संग्रहीत फ़ाइल को एक निश्चित संख्या में संस्करणों के माध्यम से संग्रहीत करें, जिसे हम संपीड़न गहराई कहते हैं। फिर, हमारे उदाहरण में, संपूर्ण इतिहास को डेल्टा संपीड़न की एक निश्चित पूर्व निर्धारित संख्या तक सीमित कर दिया गया है, जिसे अनज़िप करके आप कालक्रम में किसी भी संस्करण को देख सकते हैं। ध्यान दें कि कुछ प्रकार की वस्तुओं पर डेल्टा संपीड़न का उपयोग करना सबसे उचित है जो पदानुक्रम में निकटतम हैं, रिपॉजिटरी को प्रकार और आकार के अनुसार क्रमबद्ध किया जाना चाहिए; इस अनुच्छेद में वर्णित संचालन की यह श्रृंखला git-repack फ़ंक्शन (और git-gc, जिसमें यह शामिल है) द्वारा निष्पादित की जाती है।

शाखाओं का विलय एवं विभाजन

यह प्रश्न बहुत श्रमसाध्य और गहन है, और इसलिए हम विलय और पृथक्करण की अवधारणाओं को केवल सामान्य शब्दों में प्रस्तुत करेंगे। आइए फिर से उदाहरण देखें.

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

मान लीजिए कि हमें एक ही कार्य के पहले से ही पूर्ण किए गए दो परिणाम प्राप्त हुए, जिन पर प्रोग्रामर के दो समूहों ने काम किया। काय करते? देखें कि किसका कोड तेज़ और अधिक विश्वसनीय है? यह बहुत सरल है, लेकिन हमेशा सर्वोत्तम समाधान नहीं है। अच्छा निर्णय- इसका मतलब है, कोड और फ़ाइलों की थोड़ी समझ रखना, उन्हें उप-कार्यों या कोड ब्लॉकों में तोड़ना। और तभी हम शक्तियों की पहचान कर सकते हैं और कमजोर पक्षइन टुकड़ों का. निःसंदेह, यह विकल्प केवल तभी उपयुक्त है जब आपने पहले से अनुमान लगा लिया हो कि आप बाद में इन सभी कणों को एक साथ एकत्र करने में सक्षम होंगे। वह मामला जहां आप स्वयं कोड विकसित करते हैं, कुछ बग्स को सुधारते और ठीक करते हैं, दिए गए उदाहरण के बराबर है। यह प्रोसेसदो पूर्णांकों को एक में मिलाना विलयन कहलाता है। दो संस्करणों के संयोजन की प्रक्रिया परियोजना प्रबंधन का महत्वपूर्ण क्षण है। जैसा भी हो, आपको इस ऑपरेशन के स्वचालित निष्पादन से बचना चाहिए। विशेष फ़ीचर Git सबसे विश्वसनीय और निष्पक्ष है तेज तरीकाशाखाकरण समस्या का समाधान.

प्रणाली के फायदों में शामिल हैं:

1. यूनिक्स-उन्मुख।
2. वैचारिक स्थिरता (सिस्टम का उपयोग करने के नियमों का पालन करते हुए, निराशाजनक स्थिति में आना या कुछ ऐसा प्राप्त करना जिसकी आपको उम्मीद नहीं थी) बहुत मुश्किल है।
3. उच्च प्रदर्शन (यह सिस्टम के सबसे स्पष्ट लाभों में से एक है, जिसकी कीमत "वैचारिक स्थिरता" और "यूनिक्स-उन्मुखता" है)।
4. सबवर्सन, मर्कुरियल, जैसे तीसरे पक्ष सिस्टम के साथ गिट का एकीकरण ...
5. फ़ाइलों के एक समूह को प्रबंधित करना (सिस्टम को प्रत्येक फ़ाइल में परिवर्तनों पर अलग से विचार करने की आवश्यकता नहीं है, यह पूरे प्रोजेक्ट में किसी भी बदलाव को याद रखता है, और यदि आपको अचानक एकल परिवर्तनों को ट्रैक करने की आवश्यकता होती है, तो यह ठीक उसी भाग को प्रदर्शित करेगा जो इस फ़ाइल से जुड़ा है ).
6. मर्ज ऑपरेशन (एक जटिल कार्य का अधिकतम स्वचालित कार्यान्वयन)।

नुकसान में शामिल हैं:

1. यूनिक्स-उन्मुख (यह गैर-यूनिक्स प्रणालियों पर परिपक्व गिट कार्यान्वयन की कमी पर ध्यान देने योग्य है)।
2. समय-समय पर git-gc कमांड चलाने की आवश्यकता (फ़ाइलों के समूहों को पैक करता है और जो लिंक से लिंक नहीं हैं उन्हें हटा देता है)।
3. हैश टकराव (विभिन्न सामग्रियों वाली फ़ाइलों के SHA1 हैश का मिलान)।

6. गिट इंटरफेस

"कितने लोग, इतनी सारी राय।" आइए सिस्टम के साथ काम करने के लिए कई प्रकार के इंटरफेस को उजागर करने का प्रयास करें। निम्नलिखित में से प्रत्येक प्रकार के एप्लिकेशन कुछ उद्देश्यों के लिए अपने तरीके से बेहतर हैं।

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

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

तीसरे प्रकार के इंटरफ़ेस को प्रतिष्ठित किया जा सकता है - पहले दो का मिश्रण। वे। आपके पास एक कंसोल एप्लिकेशन है, जैसे देशी गिट शेल। आप पेड़ों को प्रदर्शित करने, संस्करण पदानुक्रम के अवलोकन को सरल बनाने, संस्करणों के बीच अंतर, और अपनी आवश्यक वस्तुओं को ढूंढने के लिए Gitk या QGit जैसी कई अतिरिक्त उपयोगिताओं का उपयोग कर सकते हैं।

सात निष्कर्ष

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

मुझे हाल ही में अपने कई कर्मचारियों को Git की मूल बातें सिखाने की ज़रूरत पड़ी जो अभी प्रोग्रामिंग सीख रहे थे और काम करने की कोशिश कर रहे थे। शुरुआती लोगों के लिए इंटरनेट पर लेखों की खोज करने के बाद, मुझे यह तथ्य पता चला कि उनमें से अधिकांश कंसोल गिट का उपयोग कैसे करें या अन्य समान प्रणालियों पर इसकी आवश्यकता और लाभ के बारे में हैं। एक नौसिखिया आमतौर पर इन सभी चीजों में बहुत अच्छा नहीं होता है। मेरा मानना ​​है कि सबसे पहले तो उसे यह सब जानने की जरूरत नहीं है। आख़िरकार, आप अपनी परियोजनाओं के लिए Git का उपयोग कर सकते हैं और प्रोग्रामिंग सीखने के साथ-साथ इसके सभी आनंद सीख सकते हैं। लेकिन,मैं दृढ़तापूर्वक अनुशंसा करता हूं कि आप इस लेख को एक शैक्षिक लेख के रूप में लें और भविष्य में Git के बारे में और जानें।.

सामान्य तौर पर, कट के नीचे उपयोग करने के तरीके पर एक लेख हैस्मार्टगिट और बिटबकेट आप एक महत्वाकांक्षी डेवलपर के रूप में अपना जीवन बेहतर बना सकते हैं।

एम हम क्या करेंगे इसकी एक छोटी सी योजना:

1. बिटबकेट पर एक रिपॉजिटरी बनाना।
2. एक रिपॉजिटरी को क्लोन करना (इसे स्मार्टगिट में जोड़ना)।
3. कमिट बनाना.
4. परिवर्तन रद्द करें.
5. शाखाएँ बनाना.
6. शाखाओं को दूरस्थ रिपॉजिटरी में धकेलना (शाखाओं को दूरस्थ सर्वर पर अपलोड करना)।
7. शाखाओं का विलय.

जाना। रिपॉजिटरी बनाना बहुत है सरल कार्य. हम इसके लिए BitBucket का उपयोग करेंगे, इसलिए आपके पास वहां एक खाता होना चाहिए। पंजीकरण के बाद, "बनाएं" बटन पर क्लिक करें और आवश्यक फ़ील्ड भरें। आइए स्मार्टगिट का उपयोग करके रिपॉजिटरी को क्लोन करें। आइए हमारे भंडार का एक लिंक लें।

अब स्मार्टगिट लॉन्च करें, "प्रोजेक्ट" - "क्लोन" (या Ctrl + Alt + O) चुनें और आवश्यक फ़ील्ड भरें:

सिस्टम आपसे Bitbucket उपयोगकर्ता नाम और पासवर्ड मांगेगा:

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

अगली विंडो स्मार्टगिट में प्रोजेक्ट का नाम है:

यदि आपने क्लोन किया है खाली भंडार(जैसा कि इस आलेख में है), आपको निम्न विंडो दिखाई देगी:

आगे बढ़ो। आइए एक समिति बनाएं. कॉमेट क्या है? यह बदलावों की प्रतिबद्धता है. प्रत्येक कमिट "याद रखता है" कि आपने वास्तव में क्या बदला है और किसी भी समय आप फ़ाइलों को उनकी पिछली स्थिति में वापस कर सकते हैं। मैं आपको प्रत्येक महत्वपूर्ण परिवर्तन के बाद एक प्रतिबद्धता बनाने की सलाह देता हूं, उदाहरण के लिए, किसी फ़ंक्शन में बग को ठीक करना। कमिट बनाने के लिए, आपको प्रोजेक्ट में कुछ बदलना होगा। प्रोजेक्ट फ़ोल्डर में कुछ फ़ाइलें जोड़ें:

अब आप स्मार्टगिट में हमारे प्रोजेक्ट में बदलाव देख सकते हैं:

दोनों फ़ाइलों का चयन करें और पहले "स्टेज" और फिर "कमिट" पर क्लिक करें। आपको "स्टेज" पर क्लिक करने की आवश्यकता क्यों है? "स्टेज" बटन चयनित फ़ाइलों को वर्तमान इंडेक्स में जोड़ता है। यदि आप दो फ़ाइलों के लिए एक कमिट बनाना चाहते हैं, और बदल गए हैं, मान लीजिए, 5, तो बस इन दो फ़ाइलों का चयन करें, "स्टेज" पर क्लिक करें, जो उन्हें इंडेक्स में जोड़ देगा, और फिर "कमिट करें"। इस तरह, केवल चयनित दो फ़ाइलें ही प्रतिबद्ध होंगी।

जिसके बाद एक विंडो दिखाई देगी जहां आपको एक कमिट कमेंट दर्ज करना होगा। आमतौर पर वे वहां लिखते हैं कि क्या बदला गया, जोड़ा गया, हटाया गया, इत्यादि:

फिर "कमिट करें" बटन पर क्लिक करें। "कमिट और पुश" बटन एक ही काम करता है, लेकिन रिमोट रिपॉजिटरी (हमारे मामले में, बिटबकेट) में परिवर्तनों को अपलोड (अपलोड) भी करता है। अभी ऐसा मत करो. हम आगे धक्का देने से निपटेंगे। नीचे, शाखाओं की सूची दिखाई देगी स्थानीय शाखा"मालिक"। यह एप्लिकेशन कोड की मुख्य शाखा है. मैं आपको थोड़ी देर बाद बताऊंगा कि शाखाएँ क्या हैं। आइए अब अपने प्रोजेक्ट के साथ कुछ करें, और फिर परिवर्तनों को वापस लें। मैं readme.txt फ़ाइल को हटा दूंगा, Index.php फ़ाइल को संपादित करूंगा, और एक नई confic.cfg फ़ाइल जोड़ूंगा:

अब कमिट के बाद परिवर्तन को वापस लेते हैं। आइये लॉग पर जाएँ:

उस कमिट का चयन करें जिस पर हम रोलबैक करना चाहते हैं और "रीसेट" पर क्लिक करें:

अगली विंडो में हमें यह चुनने के लिए कहा जाता है कि हम कौन सा "रीसेट" करना चाहते हैं:

समझाऊंगा। याद रखें कि जब आप कोई कमिट बनाते हैं, तो आप सबसे पहले स्टेज पर फ़ाइलें जोड़ते हैं। यह आपको केवल अनुक्रमित फ़ाइलें प्रतिबद्ध करने की अनुमति देता है। सॉफ्ट रीसेट केवल कमिट को रीसेट करता है। फ़ाइलों में अनुक्रमणिका और भौतिक परिवर्तन बने रहते हैं। मिश्रित रीसेट सॉफ्टवेयर की तरह ही काम करता है, लेकिन फ़ाइल इंडेक्स को भी हटा देता है। हार्ड रीसेट फ़ाइलों में कमिट, इंडेक्स और भौतिक परिवर्तन हटा देता है। सावधानी से प्रयोग करें मुश्किल रीसेट, ताकि गलती से अनावश्यक चीजें न हटें।

मैंने स्पष्टता के लिए हार्ड रीसेट किया:

जैसा कि आप देख सकते हैं, फ़ाइलों में सभी परिवर्तन गायब हो गए हैं, या यूँ कहें कि सब कुछ पहली प्रतिबद्धता की स्थिति में वापस आ गया है।

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

आइए अपनी खुद की शाखा बनाने का प्रयास करें। हमारे पास पहले से ही एक है, यह मास्टर है। जब आप पहली बार प्रतिबद्ध होते हैं तो यह स्वचालित रूप से (यदि मौजूद नहीं है) बनाया जाता है। आइए एक और शाखा बनाएं और इसे "new_future1" नाम दें। F7 दबाएँ या "स्थानीय शाखाएँ" शिलालेख पर "शाखाएँ" टैब के नीचे राइट-क्लिक करें और ड्रॉप-डाउन सूची से "शाखा जोड़ें" चुनें:

बनाई गई शाखा पर तुरंत स्विच करने के लिए "शाखा जोड़ें और स्विच करें" पर क्लिक करें। अब आप नए कमिट बना सकते हैं, फ़ाइलें बदल सकते हैं और चिंता नहीं कर सकते। क्योंकि आपके पास लौटने के लिए हमेशा एक मास्टर शाखा होती है। जब आप एक शाखा बदलते हैं, तो Git उस शाखा की स्थानीय फ़ाइलों को बदल देता है। यानी, यदि आप एक नई शाखा बनाते हैं, Index.php फ़ाइल में कुछ बदलते हैं, और फिर मास्टर शाखा पर स्विच करते हैं, तो आपके द्वारा किए गए सभी परिवर्तन हटा दिए जाएंगे। यदि आप बनाई गई शाखा पर वापस स्विच करते हैं, तो परिवर्तन वापस आ जाएंगे।

अब तक हमने स्थानीय स्तर पर काम किया है।' आइए अपना काम सर्वर पर अपलोड करने का प्रयास करें। आइए new_future1 शाखा में कुछ कमिट बनाएं। यदि रिपॉजिटरी खाली है, और यह खाली है क्योंकि हमने इसे कुछ समय पहले बनाया था और सर्वर पर कुछ भी अपलोड नहीं किया था, बिटबकेट मुख्य शाखा को असाइन करता है जिसे पहले अपलोड किया गया था। इसलिए, आइए "मास्टर" शाखा पर जाएँ और "पुश" बटन दबाएँ:

इसके बाद, स्मार्टगिट पूछेगा कि क्या शाखा ट्रैकिंग (कॉफिगर ट्रैकिंग) को कॉन्फ़िगर करना है। जब आप कोड अपडेट डाउनलोड या अपलोड करते हैं तो ट्रैकिंग आपको संबंधित शाखाओं को स्वचालित रूप से अपडेट करने की अनुमति देती है। तो बेझिझक "कॉन्फ़िगर करें" पर क्लिक करें:

अब दूसरी शाखा में जाएं और वही करें। आइए बिटबकेट पर जाएं और देखें कि "कमिट्स" अनुभाग में क्या बदलाव आया है:

जैसा कि आप देख सकते हैं, सब कुछ रिमोट सर्वर पर चला गया।

अब शाखाओं का विलय करते हैं। इसकी आवश्यकता क्यों है? आइए एक मॉड्यूल के साथ वही उदाहरण लें। देर-सबेर आप इसे पूरा कर लेंगे और आपको मॉड्यूल कोड को मुख्य एप्लिकेशन कोड में जोड़ने की आवश्यकता होगी। बस शाखाओं का विलय ही काफी है। ऐसा करने के लिए, उस शाखा पर स्विच करें जिसमें आप कोड को मर्ज करना चाहते हैं। हमारे मामले में, यह मास्टर है. फिर उस शाखा पर राइट-क्लिक करें जिससे आप कोड मर्ज करना चाहते हैं और "मर्ज" चुनें:

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

इस समय के लिए बस इतना ही. तस्वीरों की वजह से लेख बड़ा बनकर सामने आया. अपने उत्तर सबमिट करें. सवालों के जवाब लिखने।

यह अध्याय Git के साथ शुरुआत करने के बारे में है। सबसे पहले, हम संस्करण नियंत्रण प्रणालियों की मूल बातें सीखेंगे, फिर हम आपके ओएस पर गिट को चलाने के तरीके पर आगे बढ़ेंगे और अंत में इसे काम के लिए सेट अप करेंगे। अध्याय के अंत में, आपको पहले से ही पता चल जाएगा कि Git क्या है और आपको इसका उपयोग क्यों करना चाहिए, और आपके पास एक सिस्टम भी होगा जो अंततः काम करने के लिए कॉन्फ़िगर किया गया है।

संस्करण नियंत्रण प्रणाली के बारे में

"संस्करण नियंत्रण प्रणाली" क्या है और यह महत्वपूर्ण क्यों है? संस्करण नियंत्रण प्रणाली एक ऐसी प्रणाली है जो समय के साथ किसी फ़ाइल या फ़ाइलों के सेट में परिवर्तनों को रिकॉर्ड करती है और आपको बाद में एक विशिष्ट संस्करण पर वापस लौटने की अनुमति देती है। फ़ाइल संस्करण नियंत्रण के लिए, यह पुस्तक एक उदाहरण के रूप में उपयोग की जाएगी स्रोतसॉफ़्टवेयर, हालाँकि वास्तव में आप लगभग किसी भी प्रकार की फ़ाइल के लिए संस्करण नियंत्रण का उपयोग कर सकते हैं।

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

स्थानीय संस्करण नियंत्रण प्रणाली

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

इस समस्या को हल करने के लिए, प्रोग्रामर ने बहुत पहले एक सरल डेटाबेस के साथ स्थानीय वीसीएस विकसित किया था जो फाइलों में सभी परिवर्तनों के रिकॉर्ड संग्रहीत करता है, जिससे संशोधन नियंत्रण होता है।

आकृति 1। स्थानीय नियंत्रणसंस्करण.

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

केंद्रीकृत संस्करण नियंत्रण प्रणाली

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

चित्र 2. केंद्रीकृत संस्करण नियंत्रण।

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

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

विकेंद्रीकृत संस्करण नियंत्रण प्रणाली

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

चित्र 3. विकेंद्रीकृत संस्करण नियंत्रण।

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

क्या आप आधे समय में टीम आईटी विकास परियोजनाओं पर काम करना चाहते हैं? हमारा नया लेखक पाठ्यक्रम लें और सीखें कि Git के सभी लाभों का उपयोग कैसे करें!

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

यही कारण है कि लाखों प्रोग्रामर प्रतिदिन अपने काम में Git का उपयोग करते हैं। Git डेवलपर्स के लिए जीवन आसान बनाता है मोबाइल एप्लीकेशन, कंप्यूटर गेम, ओपन सोर्स सॉफ्टवेयर, वेब प्रोग्रामर। Git ने अपनी विश्वसनीयता से IT जगत को जीत लिया है, उच्च प्रदर्शन, शाखाओं के साथ काम करने में आसानी और सर्वर से स्वतंत्रता।

यह पाठ्यक्रम न केवल शुरुआती लोगों के लिए उपयोगी होगा, बल्कि अनुभवी डेवलपर्स के लिए भी उपयोगी होगा जो अपने Git कौशल में अंतराल को पाटना चाहते हैं। यह एक व्यावहारिक प्रकृति का है और इसका उद्देश्य डेवलपर्स के सामने आने वाली विशिष्ट समस्याओं और मुद्दों को हल करना है

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

यह अनूठा पाठ्यक्रम लें - और आपकी टीम का कोई भी आईटी विकास प्रोजेक्ट प्रभावी होगा!