मर्क्यूरियल को Git से ज्यादा आसान क्यों माना जाता है?


204

जब तुलनाओं को देखते हैं, तो मुझे लगता है कि उनके फीचर सेट के बीच 1: 1 मैपिंग हो सकती है। फिर भी, एक अक्सर उद्धृत कथन है कि "मर्क्यूरियल आसान है"। इस कथन का आधार क्या है? (यदि कोई)


21
अजीब, मैंने कभी नहीं सुना कि मर्क्यूरियल आसान था। मुझे Git के लिए और अधिक प्रलेखन मिला (धारणा हो सकती है) इसलिए मैंने यह सीखा।
निक

16
क्योंकि यह लिनुस द्वारा बनाया गया था?
जॉब

124
यहाँ पवित्र युद्ध क्षेत्र में पहुँचना, लेकिन मुझे Git की तुलना में Mercurial का उपयोग करना आसान लगा, क्योंकि एक Windows उपयोगकर्ता के रूप में, मैंने Mercurial द्वारा स्वागत किया, और Git द्वारा एक सनकी और हारे हुए व्यक्ति की तरह व्यवहार किया। मुझे पता है कि मैं एंथ्रोपोमोर्फिफ़िंग सॉफ्टवेयर हूं, और मुझे पता है कि दोनों विंडोज़ के तहत ठीक उपयोग किए जाने के लिए पूरी तरह से सक्षम हैं, लेकिन यह उन दोनों द्वारा दी गई धारणा है।
कार्सन 63000


11
मुझे आश्चर्य है कि अगर Github मौजूद नहीं था, या उस पर कई हाई-प्रोफाइल प्रोजेक्ट नहीं थे तो कितने लोग Git का उपयोग कर रहे होंगे?
क्रिस एस

जवाबों:


240

बिंदु में मामला: चलो कहते हैं कि आप अपने पिछले सभी कमिटों पर उपयोगकर्ता नाम बदलना चाहते हैं। मुझे विभिन्न कारणों से कई बार ऐसा करने की आवश्यकता है।

Git संस्करण

git filter-branch --commit-filter '
        if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
        then
                GIT_COMMITTER_NAME="<New Name>";
                GIT_AUTHOR_NAME="<New Name>";
                GIT_COMMITTER_EMAIL="<New Email>";
                GIT_AUTHOR_EMAIL="<New Email>";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD

व्यापारिक संस्करण:

Author.convert.list फ़ाइल:

<oldname>=<newname>

कमांड लाइन:

hg convert --authors authors.convert.list SOURCE DEST

अब, कौन सा उपयोग करना आसान है?


नोट: मैंने 2 साल पूरी तरह से जीआईटी के साथ काम करने में बिताए, इसलिए यह "मुझे इससे नफरत नहीं है, मैं इसे 2 सेकंड में नहीं मिला" शेख़ी।

मेरे लिए, यह प्रयोज्यता है। Git बहुत ही लिनक्स है जो चीजों को करने के एक लाइन के तरीके के साथ उन्मुख है। इसका मतलब है कि कमांड लाइन, मैन पेज और इसे अपने लिए तैयार करना। यह एक बहुत गरीब GUI था (ध्यान दें: मैं लगभग एक साल पहले से msysGit के इस बंद कर रहा हूँ), कि बस मेरे रास्ते में लाने के लिए लग रहा था। मैं मुश्किल से इसका इस्तेमाल कर सका

कमांड लाइन बदतर थी। विंडोज पर लिनक्स उन्मुख कार्यक्रम होने के नाते, इसका उपयोग करना बहुत मुश्किल था। एक देशी बंदरगाह के बजाय वे बस मिनगॉव (थिंक सागविन) के साथ लिपटे रहते हैं, जो इसके साथ काम करना अधिक कठिन बना देता है। MinGW विंडोज कमांड प्रॉम्प्ट नहीं है, और बस अलग कार्य करता है। यह पागल है कि यह गिट के साथ काम करने का एकमात्र तरीका है। यहां तक ​​कि लिनक्स में भी ऐसा लगता था कि सीधे कमांड लाइन के साथ काम करना एकमात्र तरीका था। RabbitVCS जैसी परियोजनाओं ने कुछ मदद की, लेकिन बहुत शक्तिशाली नहीं थे।

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

मैं एक जगह से भी नफरत करता हूं जो बहुत सारे ओएसएस गिट उपयोगकर्ताओं को घूमने लगता है: जीथूब। जब आप पहली बार एक जीथब पृष्ठ पर जाते हैं, तो यह आपको हर उस चीज से जोड़ देता है जो आप संभवतः कर सकते हैं। मेरे लिए, एक प्रोजेक्ट git पृष्ठ अराजक, डरावना और अत्यधिक शक्तिशाली दिखता है। यहां तक ​​कि परियोजना क्या है, इसकी व्याख्या भी नीचे की ओर धकेल दी जाती है। गितुब वास्तव में उन लोगों को चोट पहुँचाता है जिनके पास पहले से ही पूरी वेबसाइट नहीं है। इसका मुद्दा ट्रैकर भी भयानक और भ्रामक है। सुविधा अधिभार।

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


दूसरी ओर मर्क्यूरियल किंडर अप्रोच की ओर जाता है। उनका अपना होम पेज नए उपयोगकर्ताओं के लिए Git की तुलना में बहुत अधिक अनुकूल लगता है । एक साधारण Google खोज में 5th परिणाम TortoiseHg है, जो Mercurial के लिए बहुत अच्छा GUI है। उनका संपूर्ण दृष्टिकोण पहले सादगीपूर्ण प्रतीत होता है, बाद में शक्ति।

मर्क्यूरियल के साथ मेरे पास SSH बकवास नहीं है (SSH विंडोज पर नरक है), मेरे पास बेवकूफ जटिल कमांड नहीं हैं, मेरे पास एक पंथ उपयोगकर्ता नहीं है, मेरे पास पागलपन नहीं है। मर्क्यूरियल सिर्फ काम करता है।

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

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

मर्क्यूरियल भी पहली बार थोड़े सेटअप के साथ काम करता है। किसी भी OS पर मैं सिर्फ TortoiseHg इंस्टॉल कर सकता हूं और सभी सुविधाएं प्राप्त कर सकता हूं जो मुझे अलग-अलग Guis के लिए शिकार किए बिना (मुख्य रूप से संदर्भ मेनू आदेश) चाहिए। इसके अलावा लापता SSH की स्थापना कर रहा है (गाइड के आधे लोग पुट्टी, प्लिंक और पेजेंट का उपयोग करने के लिए कहते हैं, जबकि अन्य आधे ssh-keygen का उपयोग करने के लिए कहते हैं)। नए उपयोगकर्ताओं के लिए, TortoiseHg सेटअप में मिनटों का समय लेता है जबकि Git 30 मिनट से लेकर एक घंटे तक का समय लेता है।

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

मर्क्यूरियल सिर्फ काम करता है, पहली बार, हर बार। मेरे रास्ते में Git हो जाता है और केवल मैं ही इसका उपयोग करता हूं।


6
टिप्पणीकार: टिप्पणियां स्पष्टीकरण मांगने के लिए होती हैं, न कि विस्तारित चर्चा के लिए। यदि आपके पास एक समाधान है, तो एक उत्तर छोड़ दें। यदि आपका समाधान पहले से ही पोस्ट किया गया है, तो कृपया इसे बढ़ाएँ। यदि आप अन्य लोगों के साथ इस प्रश्न पर चर्चा करना चाहते हैं, तो कृपया चैट का उपयोग करें । अधिक जानकारी के लिए FAQ देखें ।

1
IntelliJ IDEA और Xcode 4 का अपने संबंधित प्लेटफॉर्म पर Git के साथ अद्भुत एकीकरण है और दिन-प्रतिदिन के कार्यों के लिए आपको कमांड लाइन का उपयोग कभी नहीं करना है।

4
मैं यह जोड़ना चाहूंगा कि जब आप खिड़कियों पर जीआईटी का उपयोग करना चाहते हैं तो कछुआगेट बहुत बेहतर है। आपको अभी भी SSL कुंजी से निपटना है और स्थापना प्रक्रिया सुचारू नहीं है, लेकिन जब यह आसानी से काम करता है।
अर्क

2
Git के एक्सटेंशन्स मुझे व्यक्तिगत रूप से विंडोज़ पर TortoiseHG की तुलना में नेविगेट करने और काम करने में बहुत आसान लगते हैं, और मैंने केवल 1 कमांड लाइन का उपयोग किया है।
कलड्रेक्स

1
मैं इस लाइन से चकित हूँ: "मिनगव विंडोज कमांड प्रॉम्प्ट नहीं है, और बस अलग काम करता है। यह पागल है कि यह गिट के साथ काम करने का एकमात्र तरीका है।" मैं विंडोज कमांड लाइन से चलने के लिए msysgit इंस्टॉलेशन और विकल्प 2 का उपयोग करता हूं। यह बढ़िया काम करता है। कुछ चीजें हैं जो काम नहीं करती हैं (जैसे कैरट, डॉस में एक लाइन-कंटीन्यूएशन कैरेक्टर), लेकिन उन लोगों के लिए विकल्प हैं (जैसे टिल्ड) जो ठीक काम करते हैं। मैं कमांड-लाइन उत्साही नहीं हूं (या कम से कम मैं इससे पहले कि मैं Git सीखना शुरू नहीं कर रहा था) लेकिन कमांड लाइन के साथ Git का उपयोग करना वास्तव में आसान है। क्या मैं कुछ भूल रहा हूँ?
कियूरेलसा

80

Git vs Mercurial

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

Git अवधारणाओं

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


73
तो मर्क्युरियल केवल उन्नत कार्यक्षमता को छुपाता है, जबकि GIT छुपाता सभी कार्यक्षमता ... ;-)
भय

4
Git करता अधिक शक्ति है। उदाहरण के लिए git के HEAD ~ 1 के बराबर कोई नहीं है । मर्क्यूरियल में p (x) है जो शाखाओं के बीच फैला है, कितना बेकार है। Hg में कोई स्टेज नहीं है। धक्का देने पर सभी शाखाओं को धक्का देना होगा। मर्क्यूरियल सिर्फ उतना लचीला नहीं है, यहां तक ​​कि सभी प्लगइन्स जैसे कि हेवेडिट, शेल्फ और रिबेस। गिट की कमांड लाइन भी बेहतर है, यह उपयोगकर्ता को संकेत देता है, मर्क्यूरियल नहीं करता है। मैं काम पर इस थोड़ा अपंग डीवीसीएस का उपयोग करने के लिए मजबूर हूं और मैं ऐसी स्थितियों में आ गया हूं जहां मर्क्यूरियल में वह शक्ति है जो मुझे चाहिए।
कीओ

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

22
@ कीयो: पुश करते समय आपको मर्क्यूरियल के साथ सभी शाखाओं को धकेलना नहीं पड़ता है। आप एक विशिष्ट शाखा ( hg push --branch BRANCH) या एक विशिष्ट संशोधन ( hg push --rev REV) तक बढ़ा सकते हैं । कृपया hg help pushअधिक विकल्पों के लिए देखें ।
रीजेंट

1
FYI करें, कोई भी रिकॉर्ड एक्सटेंशन का उपयोग करके स्टेजिंग क्षेत्र का काफी उपसमुच्चय प्राप्त कर सकता है । ओटीओएच, मुझे लगता है कि शेल्टर एक्सटेंशन (बाजर से "शेल्व" कमांड के बाद तैयार किया गया है, और "गिट स्टैश" के करीब) स्टेजिंग क्षेत्र का उपयोग करने के अधिकांश उद्देश्यों में बेहतर है।
ब्रैंडज़ी

47

संदर्भ: मैं दैनिक आधार पर मर्क्यूरियल (काम के लिए) और गिट (साइड प्रोजेक्ट और ओपन सोर्स के लिए) दोनों का उपयोग करता हूं। मैं मुख्य रूप से दोनों के साथ टेक्स्ट-आधारित टूल का उपयोग करता हूं (आईडीई नहीं) और मैं मैक पर हूं।

सामान्य तौर पर, मुझे मर्क्यूरियल के साथ काम करना आसान लगता है। कुछ चीजें जो मुझे लगती हैं, वे मर्क्यूरियल को आसान बनाती हैं:

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

6
सूचकांक का उल्लेख करने के लिए +1; मुझे लगता है कि अनुक्रमणिका और इसके अंतःक्रियाएं वह चीज हैं जो कि गुणन की तुलना में सीखने में अधिक कठिन बनाती है।
शॉन मैकमिलन

18
hgके बराबर gitशाखाओं वास्तव में कहा जाता है bookmarks। जहाँ तक मुझे पता है, hgशाखाओं में एक समान नहीं है git
हांक गे

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

6
@ कीयो - मेरे अनुभव में, gitब्रांचिंग ब्रांचिंग का सबसेट है hg। में hgआप कर सकते हैं दोनों का नाम और बेनाम (सांस्थितिक) शाखाओं, और यहां तक कि के रूप में एक ही तरह से अनाम शाखाओं प्रबंधन कर सकते हैं gitबुकमार्क का उपयोग। मैंने वास्तव में मंचन क्षेत्र में कभी नहीं देखा है। मैं बहुत अधिक अवांछित बदलावों को झेलना चाहता हूं और फिर यह सुनिश्चित करना चाहता हूं कि मेरा कोड संकलित करने से पहले मेरे परीक्षणों का संकलन और पूर्ण करता है। मैं तब अन-शेल्व कर सकता हूं और जारी रख सकता हूं। इसके अलावा, चार्ल्स बेली की "मसाजिंग हंक्स" (p90 +) मुझे डराता है * 8 '): accu.org/content/conf2011/accu2011LT_fri_share_v2.pdf
मार्क बूथ

7
@ कीयो: मर्क्यूरियल में, निजी शाखाओं को 'बुकमार्क' कहा जाता है: रूट रिवीजन के लिए अपडेट hg bookmark keyo-stuff, चीजों को करना, hg commitऔर फिर अंततः hg push -B keyo-stuff। यदि आपको संशोधन संख्या पसंद नहीं है, तो उनका उपयोग न करें; मर्क्यूरियल एक हैश को स्वीकार करेगा कहीं भी यह एक संशोधन संख्या को स्वीकार करेगा, मुझे लगता है। मुझे कहना है, आपकी टिप्पणियों में सुविधाओं की कमी के लिए मर्क्यूरियल को कोसना, यह वास्तव में अज्ञानी और थोड़ा आक्रामक के रूप में आया है; आप Git उपयोगकर्ताओं के स्टीरियोटाइप के लिए बहुत अच्छा नहीं कर रहे हैं!
टॉम एंडरसन

29

यह बहुत व्यक्तिपरक है और एक व्यक्ति से दूसरे व्यक्ति पर निर्भर करता है, लेकिन हां, मैं यह कहूंगा कि वीसीएस के लिए पूरी तरह से नया है या "पुराने स्कूल" के वीसीएस में से किसी एक से आने वाले व्यक्ति को मर्क्यूरियल आसान लगेगा।

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

बस जवाब पूरा करने के लिए; मैं git का उपयोग करता हूं, लेकिन जब कोई "उनके लिए नया" के लिए VCS की सिफारिश करता है, तो मैं लगभग हमेशा Mercurial की सिफारिश करता हूं। मुझे याद है, जब यह पहली बार मेरे हाथ में आया, तो यह बहुत सहज लगा। यह मेरा अनुभव है कि मर्क्यूरियल जीआईटी से कम wtf / मिनट का उत्पादन करता है।


+1 के लिए "कम wtf / मिनट" -1 के लिए "यह बहुत व्यक्तिपरक है"। यह बहुत व्यक्तिपरक नहीं है ... मुझे नहीं पता कि लोग अभी भी क्यों सोचते हैं कि यूआई के अंतर व्यक्तिपरक हैं। अगर मैं मर्क्यूरियल और md5 हैश को इसकी आज्ञा देता हूं, तो आप यह तर्क नहीं करेंगे कि कुछ लोगों को मूल से अधिक md5 हैश अधिक सहज मिल सकता है? (मुझे आशा नहीं है)। यही हाल गिट का है। यदि आप अपने अनुभव को मर्क्यूरियल की तुलना में काफी अधिक रखते हैं, तो Git केवल मर्क्यूरियल से आसान है।
weberc2

17

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


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

9

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

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

जीआईटी / व्यापारिक जटिलता के लिए एक काउंटर उदाहरण: अच्छा जीआईटी समर्थन मैक पर एक्सकोड में बनाया गया है। GIT की तुलना में Mercurial के साथ XCode का उपयोग करना कम आसान है।

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

आसानी से उपयोग कुछ ऐसा नहीं है जो आसान हो। यह वहाँ है, और मुझे नहीं लगता कि यह पूरी तरह से व्यक्तिपरक है, लेकिन हमारे पास अच्छा उद्देश्य माप तकनीक नहीं है। उपयोग में आसानी के लिए इकाइयाँ क्या होंगी? मिल्ली-आइपॉड?

मैं 100% प्रो-म्यूरियल और 100% एंटी-गिट होने के लिए इतना पक्षपातपूर्ण नहीं हूं। मैं अभी मर्क्यूरियल पर, विंडोज पर और लिनक्स पर अधिक सहज हूं, और जब मैं अधिक मैक काम करना शुरू करता हूं, तो मुझे उम्मीद है कि मैं XCode + GIT के साथ रहने की कोशिश करूंगा।

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


7

कुछ चीजें हैं जो IMO नए उपयोगकर्ताओं को Git से दूर रखने की संभावना है:

  1. Git संस्कृति अधिक कमांड-लाइन केंद्रित है। हालांकि दोनों उपकरण कमांड लाइन पर बहुत अधिक ध्यान केंद्रित करते हैं (जैसा कि मैंने कई बार कहा है, कमांड लाइन निर्देश शक्तिशाली और अधिक धाराप्रवाह हो सकते हैं, लेकिन वे एक अच्छी विपणन रणनीति नहीं हैं ) यह गिट के मामले में बहुत अधिक है। जबकि Mercurial में TortoiseHg में de facto standard GUI टूल है, जो Mercurial होमपेज पर विंडोज उपयोगकर्ताओं के लिए डिफ़ॉल्ट डाउनलोड विकल्प है, Git में कई प्रतिस्पर्धी GUI फ्रंट एंड्स (TortoiseGit, Git एक्सटेंशन्स, gitk, आदि) हैं, जो अच्छी तरह से विज्ञापित नहीं हैं। Git वेबसाइट पर, और वैसे भी सभी पूरी तरह से नजर रखते हैं। (लाल लेबल पर काला पाठ! C'mon, TortoiseGit, आप इससे बेहतर कर सकते हैं!) Git समुदाय में बहुत अधिक व्यापक रवैया यह है कि जो लोग GUI उपकरण का उपयोग करते हैं, वे उचित सॉफ़्टवेयर डेवलपर नहीं हैं।

  2. Git में कई आउट-ऑफ-द-बॉक्स डिफॉल्ट हैं जो उन्नत उपयोगकर्ताओं के लिए एकदम सही समझ में आता है, लेकिन नए उपयोगकर्ताओं के लिए डराना नहीं होने पर आश्चर्य की संभावना है। उदाहरण के लिए, यह स्वचालित रूप से विलय (जैसे उदाहरण के लिए, गिट पुल स्वचालित रूप से विलय और जहां संभव होता है) जैसे कार्यों के बारे में अधिक आक्रामक है। पूरी तरह से स्वचालित मर्ज के लिए एक मामला है , लेकिन अधिकांश अनुभवहीन उपयोगकर्ता विलय से घबरा जाते हैं, और उन्हें अपने स्रोत कोड पर अपनी पूरी शक्ति प्राप्त करने से पहले अपने उपकरणों में विश्वास हासिल करने का अवसर देने की आवश्यकता होती है।

  3. प्रलेखन और निहित जटिलता:

    $ hg help log | wc -l
    64
    $ git help log | wc -l
    912
    

3
वास्तव में, मैं एक ऐसी मदद को प्राथमिकता देता हूं जो 912 लाइनों की मदद से लंबी होती है जो कि 64 है।
डायसस्टर

10
वास्तव में, मैं एक यूआई पसंद करता हूं जो इतना सहज और सहज है कि आपको पहले स्थान पर मदद की आवश्यकता नहीं है।
jammycakes

2
मुझे GUI और मदद दोनों चाहिए। :) जो मुझे सहज लगता है वह किसी और के लिए गड़बड़ है।
डायसस्टर

1
ज़रूर, लेकिन जब मदद जरूरी हो, तो उसका पालन करना आसान होना चाहिए।
जम्मीकेश

3
मैंने एक नई सादृश्य के बारे में सोचा है; Git C ++ (माफ करना लिनुस!) जैसा है और मर्क्यूरियल पास्कल की तरह है। जो निहित है और केवल पास्कल (या मर्क्यूरियल) में एक ही तरीके से किया जा सकता है, C ++ (और गिट) में उन्नीस विभिन्न तरीकों से किया जा सकता है। कुछ लोग अधिक बटन और लीवर के साथ पावरटूल पसंद करते हैं, और गिट वह है।
वारेन पी

3

एक बात मैं सोच सकता हूं

git add .
git commit -am "message"

बनाम

hg ci -Am "message"

git commit -aनई बनाई गई फ़ाइलों को नहीं जोड़ता hg ci -Aहै, जिसका अर्थ है कि git के साथ दो आदेशों की आवश्यकता वाले कुछ को Mercurial में एक कमांड के साथ किया जा सकता है। फिर, "कम टाइपिंग" का मतलब जरूरी नहीं है कि "अधिक उपयोगकर्ता के अनुकूल" हो।


11
मुझे अक्सर लगता है कि मेरे वर्कफ़्लो में, स्वचालित रूप से नई फ़ाइलों को जोड़ना वास्तव में अवांछनीय है। मैं पसंद करने आया हूं कि कैसे git commit -aकाम करता है क्योंकि यह नियंत्रित करने के लिए क्या आसान बनाता है और किसी दिए गए कमिट के लिए जोड़ा नहीं जाता है। (यह वास्तव में असामान्य नहीं है कि हर व्यक्ति के लिए अलग-अलग svn ci
मार्गनिर्देशों

3
पर्याप्त रूप से उचित है, लेकिन मेरा मानना ​​है कि hg ciबिना -Aध्वज के बराबर होता है git commit -a। मैंने hg की तुलना में बहुत अधिक git का उपयोग किया है, इसलिए मैं 100% निश्चित नहीं हूं।
झाउ माओ

मैंने जाँच की है, hg ci== git commit -a
झाउ माओ

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

1
तुम क्यों "जोड़ देंगे।" और फिर "गिट कमिटम"? क्या सब कुछ पहले से ही इंडेक्स में नहीं जोड़ा जाएगा?
जेकोबेंगल

3

क्योंकि यह है।

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.