🎣 🏜️ ✖️ मर्क्यूरियल और गिट के बीच समानताएं और अंतर 👨‍💻 🕉️ 🍜

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

थोड़ा इतिहास

मर्क्यूरियल और गिट, दोनों प्रणालियों के निर्माण के लिए प्रेरणा 2005 की एक घटना थी। बात यह थी कि उपरोक्त 2005 में, लिनक्स कर्नेल ने बिटकेपर संस्करण नियंत्रण प्रणाली को मुफ्त में उपयोग करने की क्षमता खो दी थी। तीन साल के लिए BitKeeper का उपयोग करने के बाद, कर्नेल डेवलपर्स इसके वितरित वर्कफ़्लो के आदी हैं। पैच के साथ स्वचालित काम ने लेखांकन और विलय के परिवर्तन की प्रक्रिया को बहुत सरल कर दिया, और लंबे समय तक इतिहास की उपस्थिति ने प्रतिगमन का संचालन करना संभव बना दिया।

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

भविष्य की प्रणाली के लिए तीसरी महत्वपूर्ण आवश्यकता बड़ी संख्या में परिवर्तनों और फाइलों के साथ काम की गति थी। लिनक्स कर्नेल एक बहुत बड़ी परियोजना है जो हजारों लोगों से हजारों अलग-अलग परिवर्तनों को लेती है।

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

Chodstvo

दोनों संस्करण नियंत्रण प्रणालियों में कई सामान्य विशेषताएं हैं:

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

मतभेद

विचारों की समानता और उच्च-स्तरीय कार्यक्षमता के बावजूद, निम्न-स्तरीय सिस्टम कार्यान्वयन काफी भिन्न हैं।

इतिहास का भंडारण

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

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

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

उपशाखा

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

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

उपयोग के व्यावहारिक पहलू

Git और Mercurial कार्यान्वयन में अंतर को उदाहरणों के साथ चित्रित किया जा सकता है।

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

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

मर्क्यूरियल में विभिन्न समस्याओं को हल करने के लिए एक्सटेंशन मौजूद हैं। प्रत्येक विस्तार अपनी समस्याओं को अच्छी तरह से हल करता है यदि यह अपने आप ही मौजूद है। यहां तक कि कुछ एक्सटेंशन भी हैं जो समान कार्यक्षमता प्रदान करते हैं, लेकिन विभिन्न तरीकों से।

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

एक अन्य उदाहरण git कमिट - कमांड है। यदि आपको नवीनतम प्रतिबद्ध को बदलने की आवश्यकता है, उदाहरण के लिए, कुछ भूल गए या टिप्पणी को बदल दें, तो git कमिट --amend कमांड फ़ाइल ऑब्जेक्ट्स, ट्रीज़ और कमिट ऑब्जेक्ट्स का एक पूरी तरह से नया सेट बनाएगा। उसके बाद, ब्रांच पॉइंटर को अपडेट किया जाता है। यदि आपको बाद में परिवर्तनों को वापस करने की आवश्यकता है, तो आपको केवल git रीसेट के साथ पिछले कमेंट में सूचक को वापस करने की आवश्यकता है - HEAD @ {1} कमांड। Mercurial में इसे दोहराने के लिए, आपको कमिट वापस करने की आवश्यकता है, फिर एक नया बनाएं, फिर कतार एक्सटेंशन का उपयोग करके अंतिम कमेंट की सामग्री को आयात करें, इसे पूरक करें और एक नया कमिट बनाएं।

यह ध्यान दिया जाना चाहिए कि उपरोक्त परिवर्धन में से कोई भी मर्क्यूरियल स्टोरेज प्रारूप की क्षमताओं का उपयोग नहीं करता है, और इस प्रकार वे केवल एक स्वतंत्र ऐड-ऑन के रूप में मौजूद हैं।

निष्कर्ष

इस लेख के अंतिम खंड में मैं एक संस्करण नियंत्रण प्रणाली की पसंद पर अपनी राय व्यक्त करना चाहूंगा। मर्क्यूरियल और गिट दोनों अपने सेगमेंट में अच्छे हैं।

उदाहरण के लिए, एक वाणिज्यिक सॉफ्टवेयर परियोजना चलाने के प्रयोजनों के लिए, मैं मर्क्यूरियल से अधिक प्रभावित हूं।

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

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

मर्क्यूरियल और गिट के बीच समानताएं और अंतर