Git और Mercurial - तुलना और विरोधाभास

Question

थोड़ी देर के लिए अब मैं अपनी निजी परियोजनाओं के लिए तोड़फोड़ कर रहा हूं।

अधिक से अधिक मैं Git और Mercurial और DVCS के बारे में महान बातें सुनता रहता हूं।

मैं पूरी DVCS चीज़ को एक चक्कर देना चाहूँगा, लेकिन मैं किसी भी विकल्प से परिचित नहीं हूँ।

Mercurial और Git के बीच कुछ अंतर क्या हैं?

नोट: मैं यह पता लगाने की कोशिश नहीं कर रहा हूं कि कौन सा "सबसे अच्छा" है या यहां तक ​​कि जो मुझे शुरू करना चाहिए। मैं मुख्य रूप से उन प्रमुख क्षेत्रों की तलाश कर रहा हूं जहां वे समान हैं, और जहां वे अलग हैं, क्योंकि मुझे यह जानने में दिलचस्पी है कि वे कार्यान्वयन और दर्शन के मामले में कैसे भिन्न हैं।

Comments

यह भी देखें stackoverflow.com/questions/995636/...

— VonC

मर्क्यूरियल और गिट के बीच अंतर क्या है के

— नवाफल

Answer 1

अस्वीकरण: मैं Git का उपयोग करता हूं, git मेलिंग सूची पर Git विकास का पालन करता हूं, और यहां तक ​​कि Git (gitwew मुख्य रूप से) में थोड़ा योगदान देता हूं। मैं मर्क्यूरियल को डॉक्यूमेंट से जानता हूं और कुछ ने फ्रीवन पर #revctrl IRC चैनल पर चर्चा से।

#Mercurial IRC चैनल पर सभी लोगों को धन्यवाद, जिन्होंने इस राइटअप के लिए मर्क्यूरियल के बारे में मदद प्रदान की

---

---

सारांश

_{यहाँ टेबल के लिए कुछ वाक्यविन्यास करना अच्छा होगा, कुछ जैसे PHPMarkdown / MultiMarkdown / Markdown का Maruku विस्तार}

• रिपोजिटरी संरचना: मर्क्यूरियल ऑक्टोपस मर्ज (दो से अधिक माता-पिता के साथ) की अनुमति नहीं देता है, न ही गैर-प्रतिबद्ध वस्तुओं को टैग करता है।
• टैग: मर्क्यूरियल .hgtagsप्रति-रिपॉजिटरी टैग के लिए विशेष नियमों के साथ संस्करण फ़ाइल का उपयोग करता है , और इसमें स्थानीय टैग के लिए भी समर्थन है .hg/localtags; Git टैग में refs/tags/नामस्थान में रहने वाले refs हैं , और डिफ़ॉल्ट रूप से लाने पर स्वतःभरण हैं और स्पष्ट पुश करने की आवश्यकता है।
• शाखाएँ: मर्क्युरियल में बेसिक वर्कफ़्लो अनाम प्रमुखों पर आधारित है ; Git हल्के नामित शाखाओं का उपयोग करता है, और इसमें विशेष प्रकार की शाखाएँ ( रिमोट-ट्रैकिंग शाखाएँ ) होती हैं जो दूरस्थ रिपॉजिटरी में शाखाओं का अनुसरण करती हैं।
• संशोधन नामकरण और सीमाएँ: मरकरी रिविजन नंबर , रिपॉजिटरी को स्थानीय और रिश्तेदार रिवीजन (टिप, यानी करंट ब्रांच से काउंटिंग) और इस स्थानीय नंबर पर संशोधन रेंज प्रदान करता है ; Git शाखा टिप के सापेक्ष संशोधन को संदर्भित करने का एक तरीका प्रदान करता है, और संशोधन रेंज टोपोलॉजिकल हैं (संशोधन के ग्राफ के आधार पर)
• मर्क्यूरियल नाम बदलने का उपयोग करता है , जबकि गिट फ़ाइल का नाम बदलने के लिए नाम का पता लगाने का उपयोग करता है
• नेटवर्क: मर्क्यूरियल SSH और HTTP "स्मार्ट" प्रोटोकॉल और स्थिर HTTP प्रोटोकॉल का समर्थन करता है; आधुनिक गिट SSH, HTTP और GIT "स्मार्ट" प्रोटोकॉल का समर्थन करता है, और HTTP (S) "गूंगा" प्रोटोकॉल। दोनों के पास ऑफ-लाइन परिवहन के लिए बंडलों फ़ाइलों के लिए समर्थन है।
• मर्क्यूरियल एक्सटेंशन (प्लगइन्स) और स्थापित एपीआई का उपयोग करता है; Git में स्क्रिप्टबिलिटी और स्थापित प्रारूप हैं।

---

कुछ चीजें हैं जो मर्क्यूरियल को गिट से अलग करती हैं, लेकिन कुछ अन्य चीजें हैं जो उन्हें समान बनाती हैं। दोनों परियोजनाएं एक दूसरे से विचार उधार लेती हैं। उदाहरण के लिए hg bisectमर्क्यूरियल में कमांड (पूर्व में बाइसेक्ट एक्सटेंशन ) git bisectगिट में कमांड से प्रेरित था , जबकि विचार से git bundleप्रेरित था hg bundle।

रिपॉजिटरी संरचना, संशोधन को संग्रहीत करना

Git में इसके ऑब्जेक्ट डेटाबेस में चार प्रकार की वस्तुएँ हैं: बूँद ऑब्जेक्ट्स जिसमें एक फ़ाइल की सामग्री होती है, पदानुक्रमित ट्री ऑब्जेक्ट्स जो निर्देशिका संरचना को संग्रहीत करते हैं, जिसमें फ़ाइल नाम और फ़ाइल अनुमतियों के प्रासंगिक भाग (फ़ाइलों के लिए निष्पादन योग्य अनुमति, एक प्रतीकात्मक लिंक शामिल हैं) , प्रतिबद्ध शून्य या अधिक माता पिता प्रतिबद्ध करने के लिए वस्तु है जो एक के प्रतिनिधित्व वाले संशोधन पर भंडार के राज्य के स्नैपशॉट को ग्रन्थकारिता की जानकारी, सूचक होते हैं प्रतिबद्ध (परियोजना के शीर्ष निर्देशिका के पेड़ वस्तु के माध्यम से) और संदर्भ, और टैग वस्तुओं जो अन्य वस्तुओं और कर सकते हैं संदर्भ PGP / GPG का उपयोग कर हस्ताक्षर किए जाएं।

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

Git रिपॉजिटरी को समय-समय पर रखरखाव की आवश्यकता होती है git gc(डिस्क स्थान को कम करने और प्रदर्शन में सुधार करने के लिए), हालांकि आजकल Git स्वचालित रूप से ऐसा करता है। (यह विधि रिपॉजिटरी के बेहतर संपीड़न प्रदान करती है।)

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

मर्क्युरियल का उपयोग करता लेनदेन पत्रिका के संचालन के atomicity प्रदान करने के लिए है, और पर निर्भर करता है छोटा सफाई के बाद विफल रहा है या बाधित आपरेशन करने के लिए फ़ाइलों। Revlogs केवल परिशिष्ट हैं।

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

अंतर:
^{गिट में पेड़ की वस्तुएं एक पदानुक्रमित संरचना बनाती हैं; मर्क्यूरियल मेनिफ़ेस्ट फ़ाइल में सपाट संरचना है। गिट ब्लॉब ऑब्जेक्ट में एक फ़ाइल की सामग्री के एक संस्करण को संग्रहीत करता है ; Mercurial filelog में एक फ़ाइल का पूरा इतिहास संग्रहीत किया जाता है (यदि हम यहां कोई नाम नहीं लेते हैं तो नाम बदलने में कोई जटिलता नहीं है)। इसका मतलब यह है कि ऑपरेशन के विभिन्न क्षेत्र हैं जहां मर्क्यूरियल की तुलना में Git तेज होगा, अन्य सभी चीज़ों को समान माना जाता है (जैसे विलय, या किसी प्रोजेक्ट का इतिहास दिखाना), और वे क्षेत्र जहाँ Git की तुलना में तेज़ी होगी (जैसे पैच लगाना, या दिखाना एक फ़ाइल का इतिहास)।यह समस्या अंतिम उपयोगकर्ता के लिए महत्वपूर्ण नहीं हो सकती है।}

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

जहाँ तक मुझे पता है मर्क्यूरियल में गिट से एनोटेट टैग (टैग ऑब्जेक्ट) के बराबर नहीं है । एनोटेट टैग्स का एक विशेष मामला हस्ताक्षरित टैग (PGP / GPG हस्ताक्षर के साथ) हैं; मर्क्यूरियल के समतुल्य GpgExtension का उपयोग करके किया जा सकता है , जो विस्तार मर्क्यूरियल के साथ वितरित किया जा रहा है। आप मर्क्यूरियल में गैर-प्रतिबद्ध ऑब्जेक्ट को टैग नहीं कर सकते हैं, जैसे कि आप Git में कर सकते हैं, लेकिन यह बहुत महत्वपूर्ण नहीं है, मुझे लगता है (कुछ गिट रिपॉजिटरी टैग किए गए टैग को सत्यापित करने के लिए उपयोग करने के लिए सार्वजनिक PGP कुंजी वितरित करने के लिए टैग की गई बूँद का उपयोग करते हैं)।

संदर्भ: शाखाएँ और टैग

जीआईटी संदर्भ (शाखाएं, रिमोट-ट्रैकिंग शाखाएं और टैग) कॉम के डीएजी के बाहर रहते हैं (जैसा कि उन्हें चाहिए)। refs/heads/नेमस्पेस ( स्थानीय शाखाओं ) में सन्दर्भ इंगित करता है, और आमतौर पर "गिट कमिट" द्वारा अद्यतन किया जाता है; वे शाखा के सिरे (सिर) की ओर इशारा करते हैं, इसीलिए ऐसा नाम है। refs/remotes/<remotename>/नेमस्पेस ( रिमोट-ट्रैकिंग ब्रांच ) के संदर्भ कमिट करने के लिए, दूरस्थ रिपॉजिटरी में शाखाओं का पालन करते <remotename>हैं और "git fetch" या समकक्ष द्वारा अपडेट किए जाते हैं। refs/tags/नाम स्थान ( टैग ) में संदर्भ आमतौर पर (हल्के टैग) या टैग ऑब्जेक्ट (एनोटेट और हस्ताक्षर किए गए टैग) को इंगित करता है, और बदलने के लिए नहीं है।

टैग

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

मर्क्यूरियल उन स्थानीय टैग का भी समर्थन करता है hg/localtags, जो संग्रहीत हैं , जो दूसरों को दिखाई नहीं देते हैं (और निश्चित रूप से हस्तांतरणीय नहीं हैं)

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

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

Git का Mercurial में स्थानीय टैग का एक सख्त समकक्ष नहीं है। फिर भी गिट बेस्ट प्रैक्टिस अलग-अलग सार्वजनिक नंगे रिपॉजिटरी को सेटअप करने की सलाह देती है, जिसमें आप तैयार बदलावों को धक्का देते हैं, और जिसमें से दूसरों को क्लोन और लाते हैं। इसका मतलब है कि जिन टैग्स (और शाखाएँ) को आप पुश नहीं करते हैं, वे आपके रिपॉजिटरी के लिए निजी हैं। दूसरी ओर आप स्थानीय टैग के लिए उदाहरण के अलावा heads, remotesया अन्य नाम स्थान का भी उपयोग कर सकते हैं ।tagslocal-tags

^{व्यक्तिगत राय: मेरी राय में टैग्स को रिवीजन ग्राफ से बाहर रहना चाहिए, क्योंकि वे इसके लिए बाहरी हैं (वे रिव्यू के ग्राफ में संकेत हैं)। टैग गैर-संस्करणित होना चाहिए, लेकिन हस्तांतरणीय होना चाहिए। फ़ाइलों की अनदेखी करने के लिए एक के समान एक तंत्र का उपयोग करने के लिए मर्क्यूरियल की पसंद, इसका मतलब है कि इसे या तो .hgtagsविशेष रूप से व्यवहार करना है (फ़ाइल इन-ट्री हस्तांतरणीय है, लेकिन साधारण यह संस्करण है), या ऐसे टैग हैं जो केवल स्थानीय हैं ( .hg/localtagsगैर-संस्करणित है, लेकिन अपरिहार्य)।}

शाखाओं

Git में स्थानीय शाखा (ब्रांच टिप, या ब्रांच हेड) एक कमिट के लिए एक नामित संदर्भ है, जहां कोई नया कमिट कर सकता है। शाखा का अर्थ विकास की सक्रिय रेखा भी हो सकता है, यानी शाखा टिप से सभी पहुंच योग्य हैं। स्थानीय शाखाएँ refs/heads/नामस्थान में निवास करती हैं , इसलिए 'मास्टर' शाखा का पूर्ण रूप से योग्य नाम 'रेफ्स / हेड / मास्टर' है।

जीआईटी में वर्तमान शाखा (जिसका अर्थ है चेक की गई शाखा, और वह शाखा जहां नई प्रतिबद्धता होगी) वह शाखा है जिसे एचआईएडी रेफरी द्वारा संदर्भित किया जाता है। प्रतीकात्मक संदर्भ होने के बजाए, किसी को सीधे इंगित करने के लिए HEAD हो सकता है; अनाम अनाम शाखा पर होने की इस स्थिति को अलग किया गया HEAD ("गिट शाखा" दिखाता है कि आप '(कोई शाखा नहीं)') पर हैं।

मर्क्यूरियल में अनाम शाखाएँ (शाखा प्रमुख) हैं, और कोई बुकमार्क ( बुकमार्क एक्सटेंशन के माध्यम से ) का उपयोग कर सकता है । ऐसी बुकमार्क शाखाएँ विशुद्ध रूप से स्थानीय हैं, और वे नाम (संस्करण 1.6 तक) मर्क्यूरियल का उपयोग कर हस्तांतरणीय नहीं थे। .hg/bookmarksफ़ाइल को दूरस्थ रिपॉजिटरी में कॉपी करने के लिए आप rsync या scp का उपयोग कर सकते हैं । आप hg id -r <bookmark> <url>किसी बुकमार्क के वर्तमान सिरे की संशोधन आईडी प्राप्त करने के लिए भी उपयोग कर सकते हैं ।

चूँकि 1.6 बुकमार्क को धक्का / खींचा जा सकता है। BookmarksExtension पृष्ठ पर एक अनुभाग है रिमोट डेटा संग्रह स्थान के साथ काम कर रहे । इसमें एक अंतर यह है कि मर्क्यूरियल बुकमार्क नामों में वैश्विक हैं , जबकि Git में 'रिमोट' की परिभाषा में रिमोट रिपॉजिटरी में नामों से शाखा के नाम की मैपिंग का वर्णन स्थानीय रिमोट-ट्रैकिंग शाखाओं के नाम से भी है; उदाहरण के लिए refs/heads/*:refs/remotes/origin/*मानचित्रण का अर्थ है कि व्यक्ति 'मूल / मास्टर' दूरस्थ-ट्रैकिंग शाखा ('refs / remotes / मूल / मास्टर') में दूरस्थ रिपॉजिटरी में 'मास्टर' शाखा ('रेफ्स / हेड / मास्टर') की स्थिति पा सकता है।

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

मर्क्यूरियल की "नामित शाखाओं" को मेरी राय में इसके बजाय प्रतिबद्ध लेबल कहा जाना चाहिए , क्योंकि यह वही है जो वे हैं। ऐसी स्थितियां हैं जहां "नामित शाखा" में कई युक्तियां (कई निःसंतान कमिट) हो सकती हैं, और इसमें संशोधन के ग्राफ के कई असमान हिस्से भी शामिल हो सकते हैं।

Git में उन Mercurial "एम्बेडेड शाखाओं" के बराबर नहीं है; इसके अलावा, Git का दर्शन यह है कि जब कोई कह सकता है कि शाखा में कुछ कमिटमेंट शामिल हैं, तो इसका मतलब यह नहीं है कि एक कमेटी किसी ब्रांच की है।

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

धक्का देने में शाखाएँ

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

जहां तक ​​मैं इसे समझता हूं, यदि आप कई संशोधनों को धक्का देते हैं, जिनमें मर्क्यूरियल पार्लानेंस में कुछ "नामित शाखा" के रूप में चिह्नित किए गए हैं, तो आपके पास उस "नामांकित शाखा" का भंडार होगा जिसमें आप धक्का देते हैं। इसका अर्थ है कि ऐसी एम्बेडेड शाखाओं ("नामित शाखाओं") के नाम वैश्विक हैं (दिए गए भंडार / परियोजना के क्लोन के संबंध में)।

डिफ़ॉल्ट रूप से ( push.defaultकॉन्फ़िगरेशन चर के अधीन ) "git push" या "git push < रिमोट >" git मिलान शाखाओं को धक्का देगा , अर्थात केवल वे स्थानीय शाखाएँ जिनके समतुल्य पहले से मौजूद दूरस्थ रिपॉजिटरी में आप पुश करते हैं। आप सभी शाखाओं--all को पुश करने के लिए git-push ("git push --all") के विकल्प का उपयोग कर सकते हैं, आप दिए गए सिंगल ब्रांच को पुश करने के लिए "git पुश < रिमोट > < ब्रांच >" का उपयोग कर सकते हैं, और आप "git push <" का उपयोग कर सकते हैं दूरस्थ > HEAD " वर्तमान शाखा को आगे बढ़ाने के लिए ।

उपरोक्त सभी मानते हैं कि Git कॉन्फ़िगर नहीं है जो remote.<remotename>.push कॉन्फ़िगरेशन चर के माध्यम से पुश करने के लिए है ।

लाने में शाखाएँ

नोट: यहां मैं Git शब्दावली का उपयोग करता हूं, जहां "लाने" का अर्थ है कि स्थानीय कार्यों के साथ उन परिवर्तनों को एकीकृत किए बिना दूरस्थ रिपॉजिटरी से परिवर्तन डाउनलोड करना। यह वही है जो " git fetch" और " hg pull" करता है।

यदि मैं इसे सही ढंग से समझता हूं, तो डिफ़ॉल्ट रूप से मर्क्यूरियल रिमोट रिपॉजिटरी से सभी हेड प्राप्त करता है, लेकिन आप सिंगल ब्रांच प्राप्त करने के लिए ब्रांच को " hg pull --rev <rev> <url>" या " hg pull <url>#<rev>" के माध्यम से निर्दिष्ट कर सकते हैं । आप संशोधन पहचानकर्ता, "नामित शाखा" नाम (चैंज में एम्बेडेड शाखा), या बुकमार्क नाम का उपयोग करके निर्दिष्ट कर सकते हैं। बुकमार्क नाम हालांकि (कम से कम वर्तमान में) स्थानांतरित नहीं होता है। सभी "नामित शाखाएं" संशोधन आपको स्थानांतरित होने के लिए मिलते हैं। "hg pull" उन शाखाओं के सुझावों को संग्रहीत करता है जो इसे अनाम, अनाम शीर्षों के रूप में प्राप्त करता है।

डिफ़ॉल्ट रूप से Git में ("git क्लोन" द्वारा निर्मित 'मूल' रिमोट के लिए, और "git रिमोट ऐड" का उपयोग करके बनाए गए रीमोट के लिए) " git fetch" (या " git fetch <remote>") दूरस्थ रिपॉजिटरी ( नाम स्थान से) से सभी शाखाएँ प्राप्त करता है refs/heads/, और उन्हें संग्रहीत करता है refs/remotes/नाम स्थान। इसका अर्थ है कि दूरस्थ 'मूल' (पूर्ण नाम: 'रेफ्स / हेड / मास्टर') नामक शाखा को दूरस्थ 'मूल' में संग्रहीत (सहेजा गया) 'मूल / मास्टर' दूरस्थ-ट्रैकिंग शाखा (पूर्ण नाम: 'refs / ) के रूप में संग्रहीत किया जाएगा। रिमोट / मूल / मास्टर ')।

आप Git में सिंगल ब्रांचgit fetch <remote> <branch> ला सकते हैं - Git FETCH_HEAD में रिक्वेस्ट ब्रांच (es) को स्टोर करेगा, जो मर्क्यूरियल अनाम हेड्स के समान है।

वे शक्तिशाली रिफस्पेक गिट सिंटैक्स के डिफ़ॉल्ट मामलों के उदाहरण हैं : उन रीस्पेक के साथ आप निर्दिष्ट कर सकते हैं और / या कॉन्फ़िगर कर सकते हैं कि कौन सी शाखाएं प्राप्त करना चाहते हैं, और उन्हें कहां संग्रहीत करना है। उदाहरण के लिए, "सभी शाखाएँ प्राप्त करें" मामले को '+ refs / heads / * द्वारा दर्शाया गया है: refs / remotes / origin / *' Wildcard refspec, और "fetch single branch" 'refs / heads / <शाखा "के लिए आशुलिपि है। । Refspecs का उपयोग स्थानीय रेफरी के नामों के लिए दूरस्थ रिपॉजिटरी में शाखाओं (refs) के नामों को मैप करने के लिए किया जाता है। लेकिन आपको रीटच के बारे में बहुत कुछ जानने की जरूरत नहीं है, जो कि Git के साथ प्रभावी रूप से काम करने में सक्षम है (मुख्य रूप से "git Remote" कमांड के लिए धन्यवाद)।

^{व्यक्तिगत राय: मुझे व्यक्तिगत रूप से लगता है कि मर्क्यूरियल में "नामित शाखाएं" (चेंज नाम मेटाडेटा में एम्बेडेड) के साथ अपने वैश्विक नामस्थान के साथ विशेष रूप से एक वितरित संस्करण नियंत्रण प्रणाली के लिए गुमराह डिजाइन हैं । उदाहरण के लिए, चलो ऐसा मामला लेते हैं जहां ऐलिस और बॉब दोनों ने अपनी रिपॉजिटरी, शाखाओं में "फॉर-जो 'नाम की" नामित शाखा "का उपयोग किया है, जिनमें कुछ भी सामान्य नहीं है। जो के भंडार में हालांकि उन दो शाखाओं को एक ही शाखा के रूप में गलत माना जाएगा। इसलिए आप किसी तरह शाखा नाम के टकराव से बचाते हुए सम्मेलन में आए हैं। यह Git के साथ कोई समस्या नहीं है, जहां ऐलिस से जो की रिपॉजिटरी 'फॉर-जो' शाखा 'एलिस / फॉर-जो' होगी, और बॉब से यह 'बॉब / फॉर-जो' होगी।}

मर्क्यूरियल की "बुकमार्क शाखाओं" में वर्तमान में कोर वितरण तंत्र की कमी है।

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

नामकरण संशोधन

Git में नामकरण संशोधन ( git Rev-parse manpage में वर्णित उदाहरण ) के कई तरीके हैं :

• पूर्ण SHA1 ऑब्जेक्ट नाम (40-बाइट हेक्साडेसिमल स्ट्रिंग), या ऐसा विकल्प जो रिपॉजिटरी के भीतर अद्वितीय है
• एक प्रतीकात्मक रेफरी नाम, उदाहरण के लिए 'मास्टर' ('मास्टर' शाखा का उल्लेख), या 'v1.5.0' (टैग का उल्लेख करते हुए), या 'मूल / अगला' (रिमोट-ट्रैकिंग शाखा का संदर्भ)
• ^मानदंड में संशोधन के लिए एक प्रत्यय का अर्थ है किसी प्रतिबद्ध वस्तु का पहला अभिभावक, ^nमर्ज कमिट का n-th अभिभावक। ~nपैरामीटर में संशोधन के लिए प्रत्यय का अर्थ है सीधे प्रथम-पैरेंट लाइन में कमिट का n-th पूर्वज। उन प्रत्ययों को जोड़ा जा सकता है, प्रतीकात्मक संदर्भ से पथ निर्दिष्ट संशोधन करने के लिए, जैसे 'पु ~ 3 ^ ^ ~ 3 ~'
• "Git वर्णन" का आउटपुट, अर्थात एक निकटतम टैग, वैकल्पिक रूप से एक डैश और उसके बाद कई कमिट, एक डैश, एक 'g' और एक संक्षिप्त वस्तु का नाम, उदाहरण के लिए 'v1.6.5.1-75- g5bf8097 '।

यहाँ उल्लेखित नहीं होने के कारण, रिफ़्लो में संशोधन संशोधन भी हैं। प्रत्येक ऑब्जेक्ट को पकड़ें, यह प्रतिबद्ध हो, टैग, पेड़ या बूँद का SHA-1 पहचानकर्ता हो; निर्दिष्ट संशोधन में पेड़ (निर्देशिका) या बूँद (फ़ाइल सामग्री) को संदर्भित करने के लिए 'अगला: दस्तावेज़' या 'अगला: README' जैसे विशेष वाक्यविन्यास है।

मर्क्यूरियल में नाम बदलने के कई तरीके भी हैं (उदाहरण के लिए hg मैनपेज में):

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

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

सबसे हाल के संशोधन को हिट में जीआईएडी, और मर्क्यूरियल में "टिप" नाम दिया गया है; Git में कोई शून्य संशोधन नहीं है। मर्क्यूरियल और गिट दोनों की कई जड़ें हो सकती हैं (एक से अधिक पेरेंटलेस कमिट हो सकती हैं; यह आमतौर पर पूर्व में अलग-अलग प्रोजेक्ट का परिणाम होता है)।

यह भी देखें: एलिजा के ब्लॉग (नए) पर कई अलग-अलग प्रकार के संशोधन निर्दिष्ट लेख।

^{व्यक्तिगत राय: मुझे लगता है कि संशोधन संख्या अधिक है (कम से कम वितरित विकास और / या nonlinear / शाखा इतिहास के लिए)। सबसे पहले, एक वितरित संस्करण नियंत्रण प्रणाली के लिए उन्हें या तो रिपॉजिटरी के लिए स्थानीय होना पड़ता है, या केंद्रीय नंबरिंग प्राधिकरण के रूप में एक विशेष तरीके से कुछ रिपॉजिटरी के इलाज की आवश्यकता होती है। दूसरा, बड़ी परियोजनाएं, जिनमें लंबा इतिहास है, 5 अंकों की सीमा में संशोधन की संख्या हो सकती है, इसलिए वे 6-7 वर्ण संशोधन पहचानकर्ताओं को छोटा लाभ प्रदान करते हैं, और सख्त आदेश देते हैं जबकि संशोधन केवल आंशिक रूप से आदेश दिए जाते हैं (मेरा मतलब यहां है संशोधन n और n + 1 को माता-पिता और बच्चे होने की आवश्यकता नहीं है)।}

संशोधन पर्वतमाला

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

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

यह Mercurial 1.6 के साथ तय किया गया है, जिसमें नई सामयिक संशोधन रेंज है , जहां 'A..B' (या 'A :: B') को ऐसे परिवर्तनों के समूह के रूप में समझा जाता है, जो X के वंशज हैं और Y के पूर्वज हैं। , मेरा अनुमान है, Git में '--ancestry-path A..B' के बराबर।

Git में भी A...Bसंशोधन के सममित अंतर के लिए अंकन है ; इसका अर्थ है A B --not $(git merge-base A B), जिसका अर्थ है कि सभी ए या बी में से पहुंचने योग्य है, लेकिन उन सभी से आने वाले सभी कॉमिट को छोड़कर (सामान्य पूर्वजों से पहुंच योग्य)।

नाम बदलता है

मर्क्यूरियल फ़ाइल का नाम बदलने से निपटने के लिए नाम बदलने का उपयोग करता है । इसका मतलब यह है कि इस तथ्य के बारे में जानकारी कि एक फ़ाइल का नाम बदला गया था, कमिट समय में सहेजा गया है; मर्क्यूरियल में यह जानकारी फाइललॉग (फाइल रिवॉलॉग) मेटाडेटा में "एन्हांस्ड डिफरेंट " फॉर्म में सेव होती है । इसका परिणाम यह है कि आपको hg rename/ hg mv... का उपयोग करना होगा या आपको hg addremoveसमानता आधारित नाम का पता लगाने के लिए दौड़ना याद रखना होगा ।

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

Git और Mercurial दोनों --followको एक फ़ाइल का इतिहास दिखाते समय नाम बदलने के लिए विकल्प का उपयोग करने की आवश्यकता होती है । git blame/ में फ़ाइल का लाइन-वार इतिहास दिखाते हुए दोनों नाम बदल सकते हैं hg annotate।

Git में git blameकमांड कोड मूवमेंट को फॉलो करने में सक्षम होता है, साथ ही एक फाइल से दूसरे फाइल में कोड (या कॉपी करना) भी होता है, भले ही कोड मूवमेंट फाइल के नाम का हिस्सा न हो। जहां तक ​​मुझे पता है कि यह फीचर Git (लेखन के समय, अक्टूबर 2009) के लिए अद्वितीय है।

नेटवर्क प्रोटोकॉल

Mercurial और Git दोनों को एक ही फाइल सिस्टम पर रिपॉजिटरी से लाने और आगे बढ़ाने के लिए समर्थन है, जहां रिपॉजिटरी URL रिपॉजिटरी का एक फाइल सिस्टम पथ है। दोनों को बंडल फ़ाइलों से प्राप्त करने के लिए समर्थन भी है ।

SSH के माध्यम से और HTTP प्रोटोकॉल के माध्यम से मर्क्यूरियल समर्थन प्राप्त करना और धकेलना। SSH के लिए गंतव्य मशीन पर एक सुलभ शेल खाता और स्थापित / उपलब्ध hg की एक प्रति की आवश्यकता होती है। HTTP एक्सेस के लिए hg-serveया Mercurial CGI स्क्रिप्ट रनिंग की आवश्यकता है, और Mercurial को सर्वर मशीन पर स्थापित करने की आवश्यकता है।

Git दूरस्थ रिपॉजिटरी तक पहुंचने के लिए उपयोग किए जाने वाले दो प्रकार के प्रोटोकॉल का समर्थन करता है:

• "स्मार्ट" प्रोटोकॉल , जिसमें एसएसएच के माध्यम से और कस्टम गिट के माध्यम से पहुंच शामिल है: // प्रोटोकॉल (द्वारा git-daemon), सर्वर पर स्थापित जीएटी की आवश्यकता होती है। उन प्रोटोकॉल में विनिमय क्लाइंट और सर्वर से मिलकर होता है जो इस बात पर बातचीत करते हैं कि उनके पास क्या वस्तुएं हैं, और फिर एक पैकफाइल का निर्माण और भेजना। आधुनिक गिट में "स्मार्ट" HTTP प्रोटोकॉल के लिए समर्थन शामिल है।
• "गूंगा" प्रोटोकॉल , जिसमें HTTP और FTP (केवल लाने के लिए) और HTTPS (WebDAV के माध्यम से पुश करने के लिए), सर्वर पर git स्थापित करने की आवश्यकता नहीं है, लेकिन उन्हें आवश्यकता है कि रिपॉजिटरी में अतिरिक्त जानकारी उत्पन्न होती है git update-server-info(आमतौर पर एक हुक से चलने वाली) )। एक्सचेंज में ग्राहक को कमिट चेन चलने और आवश्यकतानुसार ढीली वस्तुएं और पैकफाइल्स डाउनलोड करने की सुविधा होती है। नकारात्मक पक्ष यह है कि यह सख्ती से आवश्यकता से अधिक डाउनलोड करता है (जैसे कि कोने के मामले में जब केवल एक पैकेट होता है तो यह केवल कुछ संशोधनों को लाने पर भी पूरे डाउनलोड हो जाता है), और इसे समाप्त करने के लिए कई कनेक्शनों की आवश्यकता हो सकती है।

विस्तार: स्क्रिप्टबिलिटी बनाम एक्सटेंशन (प्लगइन्स)

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

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

Git निर्भर करता है और इसे [रिपॉजिटरी] फॉर्मेट और [नेटवर्क] प्रोटोकॉल के आसपास बनाया जाता है। भाषा बाँधने के बजाय अन्य भाषाओं में गिट के आंशिक (पूर्ण या पूर्ण) पुन : कार्यान्वयन हैं (उनमें से कुछ आंशिक रूप से कार्यान्वयन हैं, और आंशिक रूप से git आदेशों के आसपास आवरण): JGit (जावा, इजीट, एक्लिप्स गिट प्लगिन द्वारा प्रयुक्त), ग्रिट (रूबी) , ड्यूलविच (पायथन), गिट # (C #)।

---

टी एल; डॉ

Comments

क्या जोड़ा जा सकता है कि hg इतिहास के पुनर्लेखन को हतोत्साहित करने की बहुत कोशिश करता है (यह केवल एक्सटेंशन के साथ किया जा सकता है: mq, histedit, rebase), जबकि git इसे आउट-ऑफ-द-बॉक्स करता है (और यह समुदाय के भाग जैसा दिखता है यहां तक ​​कि इसे प्रोत्साहित करता है)।

— टोनफा

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

— डस्टिन

@ याकूब: नामित शाखाएं कुछ ऐसी हैं जो गिट में मौजूद नहीं हैं। यह सीधे तौर पर डिस्क्रिप्शन में एक फील्ड है (और यह इतिहास का हिस्सा है, इसलिए यह अपरिवर्तनीय है जब तक कि आप हैश इत्यादि नहीं बदलते)। Git शाखाओं की तरह कुछ बुकमार्क हैं ("हेड नामित नाम") लेकिन वे वर्तमान में रिमोट ट्रांसफ़रेबल नहीं हैं (आप खींचते समय रिमोट बुकमार्क आयात नहीं करते हैं)। stevelosh.com/blog/entry/2009/8/30/… इसे बहुत अच्छी तरह से समझाता है।

— टोनफा

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

— स्टीव लैश

@SteveLosh: आपको लगता है कि मर्क्यूरियल में बहुत सारी अनाम शाखाएँ होना एक अच्छी बात है, लेकिन मेरे लिए यह बहुत ही भयानक है। आप उन सबको अलग कैसे बताएंगे? और आपको लगता है कि Git में शाखाओं का नामकरण कुछ भारी कठिनाई है, लेकिन यदि आपके पास शाखा बनाने का कोई उद्देश्य है तो आपके पास एक तैयार नाम है। यदि आपके पास कोई उद्देश्य नहीं है, तो शाखा न करें। मैं यह देखने में विफल हूं कि मर्क्यूरियल यहां कैसे कोई लाभ प्रदान करता है। मुझे केवल दर्द और भ्रम दिखाई देता है।

— चिह्न

Answer 2

मुझे लगता है कि आप यह महसूस कर सकते हैं कि उन दो वीडियो के द्वारा उन प्रणालियों के समान या अलग क्या हैं:

लिनस टॉर्वाल्ड्स ऑन गिट ( http://www.youtube.com/watch?v=4XpnKHJAok8 )
ब्रायन ओ'सूलीवन मर्क्यूरियल पर ( http://www.youtube.com/watch?v=JExtkqzEo3Y )

दोनों डिजाइन में बहुत समान हैं लेकिन कार्यान्वयन में बहुत भिन्न हैं।

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

वे यह भी कहते हैं कि गिट HTTP पर धीमा है, लेकिन इसका अपना नेटवर्क प्रोटोकॉल और सर्वर है।

Git Mercurial की तुलना में SVN मोटी क्लाइंट के रूप में बेहतर काम करता है। आप एक SVN सर्वर के खिलाफ खींच और धक्का दे सकते हैं। यह कार्यक्षमता अभी भी मर्क्यूरियल में विकास के तहत है

Mercurial और Git दोनों में बहुत अच्छे वेब होस्टिंग समाधान उपलब्ध हैं (BitBucket और GitHub), लेकिन Google कोड केवल Mercurial का समर्थन करता है। वैसे, उनके पास Mercurial और Git की बहुत विस्तृत तुलना है जो उन्होंने यह तय करने के लिए किया था कि किसका समर्थन करना है ( http://code.google.com/p/support/wiki/DVCSAnalysis )। इसमें बहुत सारी अच्छी जानकारी है।

Comments

मैं उस Google कोड पृष्ठ पर सभी टिप्पणियों को पढ़ने की सलाह दूंगा। जानकारी कुछ पक्षपातपूर्ण महसूस करती है और मेरे अनुभव से अच्छी तरह मेल नहीं खाती है। मुझे hg पसंद है, और एक-एक साल तक इसका बड़े पैमाने पर इस्तेमाल किया । मैं अब लगभग विशेष रूप से git का उपयोग करता हूं। ऐसी चीजें हैं जिन्हें मुझे पूरा करने की आवश्यकता है जो git आसान बनाती है और hg लगभग असंभव बना देती है (हालांकि कुछ इसे "जटिलता" के माध्यम से कॉल करना पसंद करते हैं) बेसिक git बेस hg जितना आसान है।

— डस्टिन

डस्टिन, शायद उन "गैट आसान, एचजी इतने ज्यादा नहीं" मामलों में से कुछ को सूचीबद्ध करते हैं?

— ग्रीग लिंड

@knittl नहीं यह नहीं है। मुख्य रूप से क्योंकि यह उनके लिए एक दर्द है क्योंकि यह एक स्मार्ट http प्रोटोकॉल (Google के अधिकांश फ्रंट-एंड http-based हैं) का अभाव है।

— टोनफा

@tonfa: Git के लिए स्मार्ट HTTP प्रोटोकॉल वर्तमान में विकसित किया जा रहा है (जैसे: इसमें git मेलिंग सूची में पैच हैं, और वे git.it रिपॉजिटरी में 'pu' = प्रस्तावित अपडेट शाखा में हैं)।

— जकूब नारबस्की

अब तक Google कोड Git का भी समर्थन करता है।

— प्रेमिका किरजे

Answer 3

मैंने कुछ समय पहले मर्क्यूरियल के ब्रांचिंग मॉडल के बारे में एक ब्लॉग प्रविष्टि लिखी थी, और इसमें जीआईटी के ब्रांचिंग मॉडल की तुलना शामिल थी। शायद आपको यह दिलचस्प लगे: http://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-mercurial/

Comments

@ सेव लव: मैं इस ब्लॉग प्रविष्टि के बारे में टिप्पणी करना चाहता था (अनाम शाखा उर्फ ​​डिटैचड एचएएडी के बारे में, और गीट-लाईच सभी शाखाओं को लाने के बारे में, एक नहीं), लेकिन मुझे 500 सर्वर त्रुटि मिली।

— याकूब नारबस्की

@Jakub NarJbski मुझे यकीन है कि समस्या आपके नाम में गैर- ASCII चरित्र है। मुझे पूरा यकीन है कि मैं एक अन्य साइट पर एक ही समस्या में भाग गया था और यह पता चला कि यूनिकोड पर पायथन आस्किम बाइंडिंग चोक। मैं एक नजर मार लूगां।

— स्टीव लॉश

@ सेव लोश: एक जानकारी के लिए धन्यवाद, "अनइडीकोडिंग" के बाद मेरा नाम मैं टिप्पणी पोस्ट करने में सक्षम था। मर्क्यूरियल में ब्रांचिंग का बहुत अच्छा वर्णन (लेकिन मुझे अभी भी लगता है कि यह हीन है ;-))

— जैकब नारबस्की

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

— वॉरेन डेव

Answer 4

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

जैसा कि अन्य यहां ध्यान देंगे, बहुत सारे और बहुत से छोटे अंतर हैं। शाखाओं के साथ बात बड़ी भिन्न है।

Comments

मर्क्यूरियल में चार प्रकार की शाखाओं के बारे में अच्छी व्याख्या के

— मार्टिन

Answer 5

Git बनाम Mercurial पर एक नज़र डालें : कृपया पैट्रिक थॉमसन द्वारा ब्लॉग पोस्ट को आराम दें , जहां वह लिखते हैं:
Git MacGyver है , Mercurial है जेम्स बॉन्ड

ध्यान दें कि यह ब्लॉग पोस्ट 7 अगस्त 2008 से है, और दोनों एससीएम में बहुत सुधार हुआ है।

Answer 6

अजगर में मर्क्यूरियल लगभग पूरी तरह से लिखा गया है। Git का कोर C में लिखा गया है (और तेजी से होना चाहिए, Mercurial का) और sh, perl, tcl में लिखे गए उपकरण और मानक GNU बर्तनों का उपयोग करता है। इस प्रकार इसे इन सभी बर्तनों और दुभाषियों को सिस्टम में लाने की आवश्यकता है जो उन्हें शामिल नहीं करते हैं (जैसे विंडोज)।

दोनों SVN के साथ काम करते हैं, हालाँकि AFAIK svn समर्थन विंडोज पर गिट के लिए टूट गया है (हो सकता है कि मैं सिर्फ अशुभ / लंगड़ा हूं, जो जानता है)। ऐसे एक्सटेंशन भी हैं जो git और Mercurial के बीच अंतर करने की अनुमति देते हैं।

मर्क्यूरियल में अच्छा विजुअल स्टूडियो इंटीग्रेशन है । पिछली बार जब मैंने जाँच की थी, Git के लिए प्लगइन काम कर रहा था, लेकिन बेहद धीमी गति से।

वे मूल कमांड सेट बहुत समान हैं (init, क्लोन, ऐड, स्टेटस, कमिट, पुश, पुल आदि)। तो, मूल वर्कफ़्लो समान होगा। इसके अलावा, दोनों के लिए TortoiseSVN जैसे ग्राहक हैं।

मर्क्यूरियल के लिए एक्सटेंशन अजगर में लिखा जा सकता है (कोई आश्चर्य की बात नहीं!) और गिट के लिए उन्हें किसी भी निष्पादन योग्य रूप (निष्पादन योग्य बाइनरी, शेल स्क्रिप्ट आदि) में लिखा जा सकता है। कुछ एक्सटेंशन पागल शक्तिशाली हैं, जैसे git bisect।

Comments

Mercurial core को C FYI में भी लिखा जाता है (लेकिन यह शायद git से छोटा कोर है)।

— टोनफा

मैं बिना किसी परेशानी के विंडोज पर git-svn का उपयोग करता हूं। वह सिग्विन का उपयोग कर रहा है ( यदि आप मुझसे पूछें तो विंडोज पर गिट का उपयोग करने का एकमात्र सही तरीका है)। Msysgit के लिए बात नहीं कर सकते।

— दान मोल्डिंग

@ डैन मोल्डिंग: हाँ, मैंने msysgit के साथ समस्याओं का अनुभव किया है। हो सकता है कि साइबरविन पोर्ट की कोशिश करने की आवश्यकता हो (मुझे पहले साइबरविन का उपयोग करने का कुछ खराब अनुभव था, इसलिए मैंने इसे टाल दिया)। सलाह के लिए धन्यवाद!

— big_george

उपयोगकर्ता डेटा संग्रहीत करने के लिए मैं व्यक्तिगत रूप से रजिस्ट्री में साइबरविन की घुसपैठ को नापसंद करता हूं। USB कुंजी को चलाने के लिए इसे पाने के लिए यह एक PITA है और जब मैं अपनी USB कुंजी से जा सकता हूं, तो स्थानीय सी: \ ड्राइव कॉपी को तब तक सिंक्रनाइज़ रखना चाहिए जब मैं इसे चलाना चाहता हूं। : - /

— क्रिस के

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

— स्टुअर्ट एलिस

Answer 7

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

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

Comments

यदि आप कमांड लाइन का उपयोग करना पसंद नहीं करते हैं, तो TortoiseGit भी है। (लेकिन इसके लिए एमएससिट की आवश्यकता है।)

— बेन जेम्स

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

— जैकब स्टेनली

Answer 8

सब कुछ पढ़ने के बाद, मर्क्यूरियल आसान है (जो मुझे अभी भी विश्वास है कि आखिरकार, सभी इंटरनेट समुदाय की राय है), जब मैंने Git और Mercurial के साथ काम करना शुरू किया तो मुझे लगा कि मेरे लिए अनुकूल होने के लिए Git अपेक्षाकृत सरल है (मैंने शुरू कर दिया) कमांड लाइन से काम करते समय मर्क्यूरियल विद टोर्टोइसेग), मुख्यतः क्योंकि गिट कमांड को मेरे अनुसार उचित नाम दिया गया था और संख्या में कम हैं। मर्क्यूरियल में प्रत्येक कमांड के लिए अलग नामकरण होता है जो एक अलग काम करता है, जबकि Git कमांड स्थिति के अनुसार बहुउद्देशीय हो सकता है (उदाहरण के लिए,checkout)। जबकि Git तब कठिन था, अब अंतर शायद ही पर्याप्त है। YMMV .. TortoiseHg जैसे एक अच्छे GUI क्लाइंट के साथ, यह सच है कि Mercurial के साथ काम करना बहुत आसान था और मुझे थोड़ा भ्रमित करने वाली आज्ञाओं को याद नहीं रखना था। मैं विस्तार में नहीं जा रहा हूं कि एक ही कार्रवाई के लिए हर कमांड कैसे भिन्न होती है, लेकिन यहां दो व्यापक सूचियां हैं: 1 मर्क्यूरियल की अपनी साइट से और दूसरी विकी से ।

╔═════════════════════════════╦════════════════════════════════════════════════════════════════════════════════════════════════╗
║           Git               ║                Mercurial                                                                       ║
╠═════════════════════════════╬════════════════════════════════════════════════════════════════════════════════════════════════╣
║ git pull                    ║ hg pull -u                                                                                     ║
║ git fetch                   ║ hg pull                                                                                        ║
║ git reset --hard            ║ hg up -C                                                                                       ║
║ git revert <commit>         ║ hg backout <cset>                                                                              ║
║ git add <new_file>          ║ hg add <new_file> (Only equivalent when <new_file> is not tracked.)                            ║
║ git add <file>              ║ Not necessary in Mercurial.                                                                    ║
║ git add -i                  ║ hg record                                                                                      ║
║ git commit -a               ║ hg commit                                                                                      ║
║ git commit --amend          ║ hg commit --amend                                                                              ║
║ git blame                   ║ hg blame or hg annotate                                                                        ║
║ git blame -C                ║ (closest equivalent): hg grep --all                                                            ║
║ git bisect                  ║ hg bisect                                                                                      ║
║ git rebase --interactive    ║ hg histedit <base cset> (Requires the HisteditExtension.)                                      ║
║ git stash                   ║ hg shelve (Requires the ShelveExtension or the AtticExtension.)                                ║
║ git merge                   ║ hg merge                                                                                       ║
║ git cherry-pick <commit>    ║ hg graft <cset>                                                                                ║
║ git rebase <upstream>       ║ hg rebase -d <cset> (Requires the RebaseExtension.)                                            ║
║ git format-patch <commits>  ║ hg email -r <csets> (Requires the PatchbombExtension.)                                         ║
║   and git send-mail         ║                                                                                                ║
║ git am <mbox>               ║ hg mimport -m <mbox> (Requires the MboxExtension and the MqExtension. Imports patches to mq.)  ║
║ git checkout HEAD           ║ hg update                                                                                      ║
║ git log -n                  ║ hg log --limit n                                                                               ║
║ git push                    ║ hg push                                                                                        ║
╚═════════════════════════════╩════════════════════════════════════════════════════════════════════════════════════════════════╝

Git आंतरिक रूप से प्रतिबद्ध फ़ाइलों के हर संस्करण का रिकॉर्ड सहेजता है, जबकि Hg केवल उन परिवर्तनों को सहेजता है जिनमें छोटे पदचिह्न हो सकते हैं। Gg ने Hg की तुलना में इतिहास को बदलना आसान बना दिया है, लेकिन फिर से यह एक नफरत-या-प्यार-यह सुविधा है। मुझे पूर्व के लिए Hg और बाद के लिए Git पसंद है।

एचजी में मुझे जो याद है वह गिट की सबमॉडल सुविधा है। एचजी के पास सबप्रॉप्ट है लेकिन यह बिल्कुल गिट सबमॉड्यूल नहीं है।

दोनों के आस-पास का इकोसिस्टम भी किसी की पसंद को प्रभावित कर सकता है: Git को अधिक लोकप्रिय होना चाहिए (लेकिन यह बहुत ही मामूली है), Git में GitHub है जबकि Mercurial में BitBucket है , Mercurial के पास TortoiseHg है, जिसके लिए Git के लिए एक समकक्ष नहीं देखा गया है।

प्रत्येक के अपने फायदे और नुकसान हैं, उनमें से किसी के साथ आप हारने वाले नहीं हैं।

Answer 9

की जाँच करें स्कॉट चैकोन पद एक समय पहले से।

मुझे लगता है कि git में "अधिक जटिल" होने की प्रतिष्ठा है, हालांकि मेरे अनुभव में यह होने की तुलना में अधिक जटिल नहीं है। IMO, git मॉडल को समझने का तरीका आसान है (टैग में कमिट्स होते हैं (और शून्य या अधिक पेरेंट कमिट करने के लिए पॉइंटर्स होते हैं) जिसमें पेड़ों में बूँद और अन्य पेड़ होते हैं ... किया जाता है)।

यह सिर्फ मेरा अनुभव नहीं है कि मर्क्यूरियल से अधिक भ्रमित नहीं है। मैं इस मामले पर फिर से स्कॉट चाकोन के ब्लॉग पोस्ट को पढ़ने की सलाह दूंगा ।

Comments

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

— टोनफा

खैर, यह सरलीकृत मॉडल टैगिंग को नजरअंदाज करता है जो कि hg में व्यवहारिक रूप से अव्यवस्थित है (हालांकि मैं तर्क देता हूं कि git टैग थोड़ा भ्रमित करने वाला है क्योंकि यह डिफ़ॉल्ट रूप से टैग ऑब्जेक्ट नहीं बनाता है)। ऑन-डिस्क प्रारूप दोनों परियोजनाओं के लिए विशेष रूप से महंगा था, जिसमें बहुत सारे फ़ाइलनामों का इतिहास था।

— डस्टिन

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

— मार्टिन गीस्लर

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

— मार्टिन गीसेलर

मार्टिन गीस्लर मैं तर्क दूंगा कि मर्क्यूरियल में टैग के लिए नियम आवश्यक हैं, क्योंकि यह ट्रांसपोर्ट के लिए संस्करण-नियंत्रित फ़ाइल का उपयोग करता है, टैग को गैर-संस्करण बनाने के लिए विशेष नियमों पर परत के साथ, कुछ भी लेकिन आसानी से समझ में आता है।

— जैकब नार Jakबस्की

Answer 10

मैंने अपनी वर्तमान नौकरी में एक वर्ष से थोड़ा अधिक समय के लिए Git का उपयोग किया है, और इससे पहले, मेरी पिछली नौकरी में एक वर्ष के लिए Mercurial का उपयोग किया था। मैं उपयोगकर्ता के दृष्टिकोण से एक मूल्यांकन प्रदान करने जा रहा हूं।

सबसे पहले, दोनों को संस्करण नियंत्रण प्रणाली वितरित की जाती है। वितरित संस्करण नियंत्रण प्रणालियों को पारंपरिक संस्करण नियंत्रण प्रणालियों से मानसिकता में बदलाव की आवश्यकता होती है, लेकिन एक बार उन्हें समझने के बाद वास्तव में कई मायनों में बेहतर काम करते हैं। इस कारण से, मैं Git और Mercurial दोनों को Subversion, Perforce, आदि से बहुत बेहतर मानता हूं। वितरित संस्करण नियंत्रण प्रणालियों और पारंपरिक संस्करण नियंत्रण प्रणालियों के बीच अंतर Git और Mercurial के बीच के अंतर से बहुत बड़ा है।

हालांकि, Git और Mercurial के बीच महत्वपूर्ण अंतर भी हैं जो प्रत्येक को उपयोग के मामलों के अपने सबसेट के अनुकूल बनाते हैं।

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

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

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

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

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

Answer 11

एक अंतर पूरी तरह से खुद डीवीसीएस से असंबंधित है:

Git सी डेवलपर्स के साथ बहुत लोकप्रिय हो रहा है। Git लिनक्स कर्नेल के लिए डी-फैक्टो रिपॉजिटरी है और यही कारण है कि यह C डेवलपर्स के साथ इतना लोकप्रिय है। यह उन लोगों के लिए विशेष रूप से सच है जिनके पास केवल लिनक्स / यूनिक्स दुनिया में काम करने की लक्जरी है।

Java डेवलपर Git के ऊपर Mercurial का पक्ष लेते हैं। संभवतः इसके दो कारण हैं: एक यह है कि कई बड़े जावा प्रोजेक्ट मर्क्यूरियल पर होस्ट किए जाते हैं, जिसमें जेडीके भी शामिल है। एक और बात यह है कि मर्क्यूरियल की संरचना और स्वच्छ प्रलेखन जावा शिविर से आने वाले लोगों से अपील करता है, जबकि ऐसे लोग गिट असंगत कमांड कमांड का नामकरण और प्रलेखन में कमी पाते हैं। मैं यह नहीं कह रहा हूं कि यह वास्तव में सच है, मैं कह रहा हूं कि लोगों को उनके सामान्य निवास स्थान से कुछ करने की आदत है और फिर वे उस से DVCS का चयन करते हैं।

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

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

(नहीं, मेरे पास अपने दावों का बैकअप लेने के लिए उपयोग के आंकड़े नहीं हैं .. यह सब मेरी अपनी विषयवस्तु पर आधारित है)