Git को इतना प्रचार क्यों मिला? ... जबकि अन्य नहीं? [बन्द है]


124

हाल के वर्षों में, Git के आसपास प्रचार बहुत बढ़ा। हर कोई गिट के बारे में जानता है, कोई भी विकल्प के बारे में नहीं जानता है।

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

इस पोस्ट का मुद्दा इस घटना को बेहतर ढंग से समझने की कोशिश करना है।

कैसे आता है Git को केक का सारा हिस्सा? क्या उन्होंने किसी तरह बेहतर विपणन का उपयोग किया? क्या इसलिए कि इसका समुदाय अधिक है ... अहम ... "क्रिया"? क्या यह "लिनुस" नाम के कारण है? क्या इसकी वजह उसकी गीदड़ छवि है?

आपकी क्या राय है?


63
आप संभवतः लिनुस
टॉर्वाल्ड्स की

4
मुझे नहीं पता, मुझे लगता है कि वे मुझे लगभग बराबर मात्रा में उजागर कर चुके हैं ... हालांकि मैंने hg से पहले git के बारे में सुना था। लेकिन हाँ, Torvalds एक सेलिब्रिटी है, इसलिए वह जो कुछ भी शामिल है वह ध्यान आकर्षित करने की संभावना है।
पर्पल

13
मुझे GitHub पसंद है ... बस इतना ही
cnd

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

8
@ मार्कटप्प भगवान, मार्क! लगता है कि सभी की अच्छी चर्चा हो रही थी और तब आपको साथ आना पड़ा और सभी को पुलिस ने बाहर निकाला। काश, मैं StackOverflow जैसी साइट के बारे में जानता जो चर्चा की अनुमति देता।
थियोडोर आर। स्मिथ

जवाबों:


86

मेरा मानना ​​है कि GitHub या Gitorious जैसी सेवाएं एक बड़ा कारक है। यह लोगों के लिए महत्वपूर्ण है कि वे अपने सामान को कहीं और होस्ट कर सकते हैं और विशेष रूप से GitHub इसके लिए एक महान सेवा है।

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


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

11
वहाँ भी गूगल कोड और स्रोत है hg के लिए
विन्यासकर्ता

7
Git को Github द्वारा बढ़ाया जाता है जो अन्य रिपॉजिटरी को छाया में रखता है। Bitbucket के कुछ फायदे हैं (नि: शुल्क निजी रिपॉजिटरी) लेकिन UI Github की तुलना में खराब है
iandotkelly

2
मैं GitHub से बात करने के लिए अकेले मर्क्यूरियल का उपयोग करता हूं ... hggit plugin ( hg-git.github.com ) समुदाय से टूल को डिकूप करना संभव बनाता है। लेकिन शायद सामुदायिक उपकरणों से नहीं।
बानपुल्ला

1
CodePlex Mercurial का भी समर्थन करता है।
ग्रांट पॉलिन

86

मुझे इसके बहुत से उत्तर दिखाई देते हैं जो एक या दूसरे एससीएम के बारे में सुनते समय लेखक की भावनाओं पर निर्भर करता है। दूसरों का कहना है कि यह सब सरासर किस्मत थी। मेरा मानना ​​है कि इतिहास में किस्मत का पता लगाया जा सकता है।

मैं इतिहास के बारे में बात करूंगा।

समान मुद्दे को हल करने के लिए Git और Mercurial एक साथ बनाए गए थे। उन दिनों में, लिनक्स कर्नेल को बिटकेपर का उपयोग करने से रोकने के लिए मजबूर किया गया था , एक मालिकाना वितरित एससीएम जो इसे 3 वर्षों से उपयोग कर रहा था। इसका कारण यह था कि BitKover के पीछे की कंपनी BitMover के CEO लैरी मैकवाय ने अपने सॉफ्टवेयर को लिनक्स डेवलपर्स के लिए मुफ्त में देना बंद कर दिया था, क्योंकि लिनक्स समुदाय के अंदर किसी ने इसे रिवर्स-इंजीनियर किया था।

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

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

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

आज, वे दोनों प्रसिद्ध हैं। कौन सा सबसे प्रसिद्ध है यह कहना असंभव है। Google कोड ने हाल ही में Git को एकीकृत किया, जबकि इसमें लंबे समय तक Mercurial था। कई बड़ी और प्रसिद्ध परियोजनाएं या तो उपयोग होती हैं।

मुझे लगता है कि मेरा क्या मतलब है, जब बहुत कारण है कि आपने एक परियोजना क्यों शुरू की है, यह लोकप्रियता हासिल करना कठिन है, लेकिन अभी भी संभव है।

बाजार एक और SCM है जो GNU दुनिया में बहुत प्रसिद्ध है, लेकिन इतना बाहर नहीं है, क्योंकि यह GNU समुदाय को संतुष्ट करने के इरादे से बनाया गया था। सॉफ्टवेयर अक्सर वे जाते हैं जहां उनके निर्माता जाना चाहते हैं, और आगे नहीं।

दूसरी ओर, वितरित एससीएम स्पष्ट विजेता हैं। मुझे वहां व्यापक रूप से उपयोग नहीं किए गए कई गैर-वितरित एससीएम दिखाई देते हैं।


5
मैं वास्तव में इस इतिहास की सराहना करता हूं।
१२:०४ पर जुवेरन

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

7
"मुझे वहां बहुत से गैर-वितरित गैर-वितरित SCM दिखाई नहीं देते हैं।" यह इस बात पर निर्भर करता है कि आप उद्योग में कहां हैं। Perforce, ClearCase, और svn अभी भी बहुत व्यापक रूप से उपयोग किए जाते हैं, बस खुले स्रोत की दुनिया में इतना (svn को छोड़कर) नहीं है। ओह, हां, और विजुअल सोर्स सेफ और एमएस टीम जो भी है-विंडोज की दुकानों में है।
बॉब मर्फी

13
"रिवर्स इंजीनियरिंग" से, आपका मतलब सर्वर से टेलनेट करना और "सहायता" टाइप करना है
वैकल्पिक

3
मैं इसे डीवीसीएस और सीवीसीएस दोनों के बारे में सामान्य रूप से कहूंगा: "ताओ के सभी सॉफ्टवेयर पार्टेक को डर नहीं होना चाहिए।" "रेडमंड से सॉफ्टवेयर भी शामिल है?" "ओह, गश, घड़ी देखो। क्लास खारिज कर दी।"
बॉब मर्फी 21

77

लिनस टोरवाल्ड्स

लिनुस गिट का एक बड़ा वकील है और इसे सालों तक कोर लाइनक्स ग्रुप में प्रमोट किया और इसे वहीं से उगाया गया। मैं हिम्मत करता हूं कि यह पूरी तरह से लिनस के * निक्स समुदाय के प्रभाव के कारण है।

व्यक्तिगत रूप से मैं अभी भी तोड़फोड़ का उपयोग करता हूं, लेकिन यह उपयोगिता के बजाय वरीयता से है।


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

6
न केवल वह इसका एक बड़ा वकील है - वह वह है जिसने इसके मूल संस्करणों को बनाया, इससे पहले कि वह इसे
जूनियो हमानो

44
क्या? आप तोड़फोड़ क्यों पसंद करेंगे?
विन्यासकर्ता

11
क्या आपका मतलब यह नहीं है कि आप अभी भी आदत या जड़ता से बाहर तोड़फोड़ का उपयोग करते हैं, बजाय वरीयता या उपयोगिता के? इसलिए मैं अभी भी इसका उपयोग कर रहा हूं, और मुझे भी हममें से अधिकांश पर शक है ...
कोडी ग्रे

7
@deadalnix: क्योंकि लिनक्स, और लिनक्स, में किसी भी अन्य ओपन सोर्स प्रोजेक्ट द्वारा बेजोड़ फैनबॉय की भीड़ है। वे गिट के लिए एक बहुत प्रभावी सड़क टीम के रूप में कार्य करते हैं।
टॉम एंडरसन

34

संस्करण नियंत्रण प्रणाली के साथ सामान्य दर्द बिंदु शाखा विलय है

आपको यह आज़माने की ज़रूरत है जब यह समझने के लिए काम नहीं करता है कि यह कितना दर्दनाक हो सकता है और शाखाओं के साथ स्वतंत्र रूप से काम करने के लिए काम करना कितना महत्वपूर्ण है।

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

मैं लगभग एक साल पहले की स्थिति में था, जहां मुझे hg और git के बीच चयन करना था, और उपरोक्त मर्जिंग git चुनने में एक महत्वपूर्ण कारक था। दूसरा यह था कि एक्लिप्स संगठन स्विच करने के लिए आया था, इसलिए एक्लिप्स टूलिंग जावा परियोजनाओं के लिए अच्छा था। ग्रहण 3.7 के रिलीज के साथ ऐसा हुआ है। हम इस पर शायद 6-9 महीने पहले थे।

विभिन्न आवश्यकताओं के लिए hg बस के रूप में उपयोगी हो सकता है। सूर्य ने बहुत ही सावधानीपूर्वक जांच के आधार पर इसे अपने VCS के लिए चुना । आप श्वेत पत्र ढूंढ सकते हैं और देख सकते हैं कि उनके तर्क क्या थे।


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


5
+1 यह सभी शाखाओं में है। यह विश्लेषण मर्क्यूरियल की तुलना में गिट की विलय शक्ति पर चर्चा करता है।
अमेलियो वाज़केज़-रीना

19
@AmV: कृपया मोटे यूआरएल पोस्ट न करें।
कोड़ी ग्रे


4
मुझे यकीन नहीं है कि मैं आपकी बात यहां देखूंगा। आप कह रहे हैं कि वे ब्रांचिंग में समान रूप से अच्छे हैं (Git कुछ नहीं करता है जो Mercurial नहीं कर सकता है), लेकिन क्योंकि आपको अच्छी ब्रांचिंग की आवश्यकता है, इसलिए आपने Git को चुना?
जुल्फ

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

23

यह कहने के बजाय कि git या mercurial बेहतर क्यों है और इसके लोकप्रिय होने का एकमात्र कारण है, मैं समुदाय पर ध्यान केंद्रित करने जा रहा हूं।

जैसा कि मैंने पहले प्रकाश डाला था , गिट समुदाय बहुत जोर से और अभिमानी है। अधिकांश अपने कीमती कार्यक्रम का सख्ती से बचाव करेंगे। Git बनाम Mercurial युद्ध के अधिकांश मैंने देखा कि git लोगों द्वारा शुरू किया गया था जो सोच रहे थे कि पृथ्वी पर हर कोई पवित्र रिट का उपयोग क्यों नहीं कर रहा है। Whygitisbetterthanx.com जैसी साइटें भी परिचय में इस अहंकार को दर्शाती हैं, जो दूसरों को फँसाने के लिए लिखी गई है।

मैं हर किसी को इस तरह से नहीं कह रहा हूं, लेकिन ज्यादातर समय जब मैंने git लोगों, प्रो-गिट वेबसाइटों और प्रो-git ब्लॉगों का सामना किया है, तो मुझे लगा कि जैसे git को एक व्यवहार्य DVCS के रूप में पेश करने के बजाय मेरे गले से नीचे उतारा जा रहा है प्रणाली।


इसके विपरीत, अन्य डीवीसीएस समुदाय उतने जोर से नहीं हैं। मुझे पता नहीं था कि मर्क्यूरियल तब तक मौजूद है जब तक मैंने "व्हाट्स द बेस्ट डीवीसीएस?" एसओ पर सवाल। जबकि git हर जगह दिखाई देता है, अन्य DVCS को खोजने में समय लगता है।


16
क्या दूसरों को घमंडी नहीं कहना अभिमानी है?

21
@ थोरबजोरन: यह है। सिवाय जब मैं यह करता हूं; तब यह सही है।
टॉम एंडरसन

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

5
@ back2dos: यह बहुत घमंडी है कि यह दावा करता है कि "Git हर चीज से बेहतर है"। और इसके समर्थन तर्क की काफी बड़ी मात्रा में गलत या गलत है, या बाहर पार कर गया है, और अभी तक यह किसी भी तरह कभी अपने निष्कर्ष नहीं बदलता है।
jalf

5
@Agos: और लगभग सभी जो Git के लिए अद्वितीय नहीं हैं । वे सिर्फ अन्य उत्पादों को बाहर करने के लिए गोलपोस्ट को स्थानांतरित करते हैं।
Aaronaught

14

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

बेहतर विंडोज़ सपोर्ट की वजह से ज़्यादातर डेवलपर्स से मैं एचजी को पसंद करने के लिए बात करता हूं। यदि हम लिनक्स डेवलपर्स थे तो यह एक अलग कहानी हो सकती है।

आपको "बाज़ार" भी याद आ रहा है जो असली "भूल गए डीवीसीएस" है।

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


6
... पूरी तरह से सहमत हैं: "बाजार" जो असली "भूल गए डीवीसीएस" है।
डेगनीज

सहमत हूँ लेकिन एक्सपोज़र hg का भट्ठा / joel से अधिक हाल ही में लिनस से एक्सपोज़र गिट है। hg कैचअप खेल रहा है
jk।

2
वहाँ वास्तव में काफी कुछ "भूल गए डीवीसीएस" हैं, हालांकि उनमें से कई को शायद "कम प्रोफ़ाइल", "केंद्रित" या "आला" के रूप में वर्णित किया जाएगा।
जॉन गेन्स जूनियर

13

यह एक विनम्र राय है, लेकिन दो मापदंडों के कारण git को यह सब प्रचार मिल सकता है:

  1. यह बहुत कुशल है
  2. यह प्रयोग करने में मजेदार है (कुछ विशिष्ट कंप्यूटर वैज्ञानिक तरीके से)

इसके अलावा, git को github जैसा कुछ किलर ऐप मिला, और कुछ बहुत लोकप्रिय परियोजनाओं ने इसका उपयोग करने का फैसला किया, जिससे इसे बहुत दृश्यता मिली।


4
1. क्या कुछ क्षेत्र में व्यापारिक अक्षमता है? दरअसल, लंबे समय के लिए, यह http पर अधिक कुशल था, यही वजह है कि पिछले हफ्ते घोषित किए गए गिट समर्थन की तुलना में Google कोड ने इसे 2 साल से अधिक समय तक शामिल किया, और केवल http पर हाल ही में समान रूप से अच्छा हो गया। 2. ठीक 3। वहाँ बराबर bitbucket.org है
dagnelies

1
क्या मैंने यह कहा था कि भावात्मक अक्षम था? मैंने कभी इसका इस्तेमाल नहीं किया, इसलिए मैं बता सकता हूं।
थिबॉल्ट जे

4
यह सभी imho पर प्रश्न को संबोधित नहीं करता है, कम से कम "जबकि अन्य नहीं था" भाग
jk।

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

4
@ MartínMarconcini "आखिरकार मैं इस उद्देश्य के लिए गया था" से आपका क्या मतलब है? git खाली फ़ोल्डर का समर्थन नहीं करता है।
मैक्स नानसी

12

यहां काम पर तीन कारक हैं, "बीटा गीक मीडिया", "समय सही है", और "नेता का पालन करें"

बीटा गीक मीडिया

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

समय सही है

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

फ़ॉलो द लीडर

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

  • Git : लिनक्स, पर्ल, jQuery, रूबी ऑन रेल्स, एक्लिप्स, ग्नोम, केडीई, क्यूटी, एक्स
  • मर्क्यूरियल : जावा, मोज़िला, पायथन
  • बाज़ार : उबंटू, एमएसीएस

Git में अधिक "बड़े ड्रॉ" प्रोजेक्ट हैं, जो इस प्रकार उपयोग करते हैं, इस प्रकार अधिक लोग git से परिचित होते हैं, और अधिक git ट्यूटोरियल लिखे जाते हैं।


1
आप सही हो सकते हैं, लेकिन आपकी "बड़ी ड्रॉ" सूची थोड़ी भ्रामक / पक्षपाती है। बाज़ार की साइट को देखते हुए, वे कुछ अन्य प्रमुख परियोजनाओं को सूचीबद्ध करते हैं: MySQL, Bugzilla, Debian, GNU सभी बहुत व्यापक रूप से ज्ञात लोगों की तरह लगते हैं। एचजी सूची के रूप में अच्छी तरह से थोड़ा बड़ा है।
जुल्फ

@jalf: ऐसी सूची व्यक्तिपरक होनी चाहिए। मैंने अपना खुद का लिनक्स और गनोम संकलित किया है, लेकिन कभी भी मोज़िला या एमएसीएस नहीं। दूसरों का सटीक विपरीत तरीका हो सकता है। सवाल वास्तव में "कितने लोग इस परियोजना को स्रोत नियंत्रण से खींचेंगे"? मैंने उन लोगों को सूचीबद्ध किया है जो मुझे सबसे अधिक संभावना है जो लोगों को वर्तमान स्रोत को खींचने के लिए vcs स्थापित करने के लिए प्रेरित करते हैं।
सीन मैकमिलन

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

12

यह मुख्य रूप से सिर्फ स्व-सुदृढ़ प्रचार है। गिट सबसे लोकप्रिय है, इसलिए इसे सबसे अधिक प्रचार मिलता है, जिसके कारण यह अधिक लोकप्रिय हो जाता है।

Git, Hg और Bzr सभी पूरी तरह से अच्छे DVCS सिस्टम हैं, लेकिन लोगों की एक भयावह संख्या Git के साथ DVCS की बराबरी करती है, और यह सोचती है कि DVCS की सभी प्यारी विशेषताएं Git के लिए अद्वितीय हैं। और इसलिए वे Git का उपयोग करते हैं, और Git की सिफारिश करते हैं, और कहते हैं कि "Git बेहतर है क्योंकि यह ऑक्टोपस मर्ज कर सकता है" (So Bazaar), या "Git बेहतर है क्योंकि इसे वितरित किया जाता है" (इसलिए यह कोई DVCS है, इसलिए नाम ), या "गिट बेहतर है क्योंकि यह ब्रांचिंग और मर्जिंग को आसान बनाता है" (फिर, यह हर डीवीसीएस का सच है)।

अफसोस की बात है, क्योंकि मुझे लगता है कि विकल्प के रूप में अच्छी तरह से पेशकश करने के लिए बहुत कुछ है, और मुझे लगता है कि लोगों ने अपनी अनूठी शक्तियों के लिए गिट को चुना, क्योंकि वे सोचते हैं कि डीवीसीएस == गिट।

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


11

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


7

वास्तव में मुझे लगता है कि प्रचार सभी DSVCs के बारे में है।

लेकिन git के पैरोकार सिर्फ और सिर्फ मुखर हैं, अपनी टिप्पणियों में ईमानदार होने के लिए अक्सर अधिक आक्रामक होते हैं और हर जगह इस बारे में बात करना पसंद करते हैं।

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

बाज़ार के बारे में निश्चित रूप से बात नहीं की जाती है क्योंकि केवल कुछ बड़ी ज्ञात परियोजनाएँ ही इसका उपयोग करती हैं और Canonical के अलावा कोई अन्य बड़ी कंपनी इसका उपयोग करने के लिए नहीं जानी जाती है। उदाहरण के लिए Google (git, mercurial, svn) और बड़े ओपन-सोर्स प्रोजेक्ट्स से तुलना करें और आप देख सकते हैं कि वास्तव में इसके बारे में बात क्यों नहीं की गई है। जीवाश्म एक और ऐसा है जो देवों के आला के लिए दिलचस्प है, इसलिए मुझे लगता है कि यह केवल उन लोगों द्वारा सुने जाने के लिए सामान्य और ठीक है जो वे प्रदान की गई सुविधाओं की खोज करते हैं (जैसे एम्बेडेड विकी, मुद्दा ट्रैकिंग और मंच)।

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

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

कोई वास्तविक युद्ध नहीं है, बस दिलचस्प किस्म के उपकरण हैं।


मैं चाहता हूँ कि प्रचार सामान्य रूप से DVCS'es के बारे में था, लेकिन मैंने जो कुछ भी देखा है, उसमें से प्रचार Git के बारे में है, और ज्यादातर लोग सोचते हैं कि DVCS और Git मूल रूप से एक ही चीज़ है।
jalf

6

मुझे पता है कि इस सवाल के बहुत सारे उत्तर पहले से ही हैं, लेकिन मुझे लगा कि मैं थोड़ा और परिप्रेक्ष्य जोड़ सकता हूं।

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

  1. कार्यक्षमता का एक बहुत कुछ है जो यकीनन कोर VCS का हिस्सा होना चाहिए, नहीं है। इतिहास के एक मोड़ प्रदर्शन करने की क्षमता, एक पेजर के माध्यम से लंबे आउटपुट को चलाने के लिए, या "कॉलोकेटेड" शाखाएं (जैसे, जीआईटी-शैली रिपॉजिटरी) को प्लगइन्स के रूप में आपूर्ति की जाती है।
  2. बहुत सारे प्लगइन्स सभी स्थिर नहीं हैं। उदाहरण के लिए, कोलोकेटेड शाखाओं की कार्यक्षमता सर्वर साइड पर अच्छी तरह से काम नहीं करती है (कम से कम, मैंने इसे काम करने के लिए कभी नहीं किया है, यह यह कहते हुए त्रुटि हो जाती है कि दिए गए पथ पर शाखा मौजूद नहीं है जब यह होता है आपके सामने वहीं है और आप खूनी चीज़ देख सकते हैं)।
  3. इसका कोई "क्लोन" ऑपरेशन नहीं है, आप एक समय में एक शाखाएं खींचते हैं। आपको अतिरिक्त कार्य करना होगा यदि आप एक भंडार चाहते हैं ताकि आप कुशलतापूर्वक नई शाखाओं को खींच सकें।
  4. कुछ परियोजनाओं के लिए, यह दर्द से धीमा है। "Bzr ब्रांच lp: mysql" कभी-कभी आज़माएँ।
  5. इसमें हुक के लिए मजबूत समर्थन का अभाव है; आप bzr प्लगइन्स लिख सकते हैं जो हुक प्रदान करते हैं, लेकिन सर्वर-साइड मनमाना हुक स्क्रिप्ट के लिए एक मानक तरीका नहीं है।

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

  1. git clone अपेक्षाकृत तेज़ संचालन है, और आपको उन सभी शाखाओं के बारे में जानकारी देता है जो आपके द्वारा क्लोन किए गए भंडार में मौजूद हैं।
  2. अतिरिक्त दूरस्थ रिपॉजिटरी को जोड़ना दर्दरहित है, और इसलिए यदि आप चाहें तो कई अलग-अलग रिपॉजिटरी को कई शाखाओं को ट्रैक कर सकते हैं।
  3. प्रो Git किताब है ऑनलाइन उपलब्ध ई-पुस्तक पाठक के लिए सहित और कई प्रारूपों में, उपकरणों और यह एक कठिन पढ़ा नहीं है।
  4. git बाज़ार की तुलना में विस्तार करना बहुत आसान लगता है, और आपको इसे करने के लिए किसी एक विशेष API का उपयोग करने की आवश्यकता नहीं है। (एनबी: यह एक उल्टा और नकारात्मक पक्ष है।)
  5. git में द्वि-अंतर्ग्रहण अंतर्निहित है, और मैं उस सुविधा की उपयोगिता पर पर्याप्त जोर नहीं दे सकता।
  6. GitHub बल्कि अच्छा है।
  7. gitosisप्रणाली भी काफी अच्छा है। मुझे यह भी पता नहीं है कि बाज़ार में एक प्लगइन के अलावा अन्य इसे कैसे लागू करेंगे, और मैं कल्पना नहीं कर सकता कि यह कुशल के रूप में कहीं भी होगा।

लंबी कहानी छोटी: मैंने बहुत लंबे समय से bzr का उपयोग किया है, लेकिन git जल्दी ही मेरे लिए अपनी अजीबता साबित कर रहा है।


5

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

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

मेरा मानना ​​है कि आप मर्क्यूरियल में समान काम कर सकते हैं, लेकिन किसी कारण से मर्क्यूरियल डॉक्यूमेंटेशन (जो मैंने पढ़ा है) लगभग हमेशा रिपॉजिटरी क्लोन बनाकर ब्रांचिंग दिखाता है।

(मैं दैनिक git का उपयोग करता हूं। मेरे पास भाड़े के साथ बहुत कम अनुभव है, मैंने इसके साथ खेला है और कुछ ट्यूटोरियल का पालन किया है)


2
मैंने hg में हर समय 'नामित' शाखाओं का उपयोग किया। यह उनका अच्छा समर्थन करता है। hg branch foo, फिर hg up fooबाद में ... साधारण विकास के लिए क्लोन-फॉर-ब्रांच में कुछ मजबूत कमजोरियां हैं।
पॉल नाथन

हम्म, इसलिए आप कह रहे हैं कि Gg, Hg से बेहतर है क्योंकि Hg उस सुविधा का समर्थन करता है जिसके बारे में आप परवाह करते हैं, Hg समुदाय एक वैकल्पिक दृष्टिकोण को बेहतर मानता है?
:

1
1: मुझे आश्चर्य है: एचजी प्रलेखन में "शाखा द्वारा क्लोनिंग" पर ध्यान क्यों दें (उदाहरण के लिए देखें hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html और mercurial.selenic। com / गाइड )? मेरे लिए, प्रति शाखा में एक रिपॉजिटरी का होना ही गन्दा लगता है। 2: मैं यह नहीं कह रहा कि git बेहतर है, मेरा जवाब इस बात पर अधिक है कि मेरे लिए (एक Hg नौसिखिए) दोनों के बीच अंतर की तरह दिखता है। यह अंतर तकनीकी से अधिक सांस्कृतिक प्रतीत होता है, क्योंकि Hg "समान भंडार के भीतर शाखा" का भी समर्थन करता है।
कोडपे

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

4

मुझे नहीं पता कि मैंने पिछले कुछ हफ्तों में कितने ऐसे रैंट्स देखे हैं, लेकिन वे सभी इस तथ्य पर विचार करते हैं कि मर्क्यूरियल और / या बाज़ार Git से बेहतर हैं। प्रयोज्य एक सामान्य विषय लगता है। हां, CVS और तोड़फोड़ का उपयोग करने के बाद Git सीखना आश्चर्यजनक रूप से कठिन था, लेकिन इस बिंदु पर मैं इसे किसी भी अन्य VCS के लिए व्यापार नहीं करना चाहता जब तक कि यह एक और प्रतिमान बदलाव का गठन नहीं करता । और सुविधाओं की एक तालिका की ओर इशारा करते हुए मुझे बहुत कम के बारे में बताने जा रहा है कि यह कितना लचीला, सुरक्षित, सुरक्षित या सहज है। उदाहरण के लिए, डिफ़ॉल्ट रूप से git-diff रंगों और पेजर का उपयोग करता है। यकीन है कि मैं diff ... | colordiff | less -Rया कुछ के साथ एक ही प्राप्त कर सकते हैं , लेकिन यह स्पष्ट होना चाहिए कि क्यों एक दूसरे से बेहतर है।


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

3

निष्पक्ष होने के लिए, मुझे लगता है कि git बनाम केंद्रीकृत अधिवक्ताओं git बनाम केंद्रीकृत अधिवक्ताओं की तुलना में कम और दूर हैं। हालांकि, कारण संक्षेप में आसान हैं:

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

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

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

मुझे नहीं लगता कि यह कहना उचित है कि प्रचार, या लिनस के समर्थन के कारण ही git लोकप्रिय है। शायद यह कोशिश कर रहे कई लोगों के लिए खाता है, लेकिन वे इसके साथ चिपके रहते हैं और इसे बढ़ावा देते हैं क्योंकि यह उनके लिए शुद्ध और सरल काम करता है।




1

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


1

बस मेरे 2 my - मैंने विकल्पों पर पकड़ को चुना क्योंकि यह एक मूल भाषा या अति-शैक्षणिक उच्च स्तरीय भाषा के बजाय C में लिखा गया है। लाभ यह है कि यह तेज और कुशल है और मैं वास्तव में RTFS कर सकता हूं अगर मुझे बग या व्यवहार का सामना करना पड़ता है जो मैं समझा नहीं सकता। यह छोटे स्व-होस्ट किए गए विकास परिवेशों पर उपयोग करना भी संभव बनाता है जिसमें विशाल व्याख्याकार / रनटाइम्स शामिल नहीं हैं, जिसका अर्थ है कि मैं सीधे जीआईटी रेपो से खींच सकता हूं और ऐसे सिस्टम पर संकलन कर सकता हूं बजाय नवीनतम स्रोत प्राप्त करने के लिए और rsync।


1
यही कारण था कि मैंने गिट का चयन किया है, क्योंकि यह अजगर के बजाय एक संकलित भाषा में लिखा गया है, और इसकी वजह से मैं बस कुछ अन्य उपकरणों के साथ मिलकर अपने USB पेन में git का एक पोर्टेबल संस्करण रख सकता हूं।
कोयोटे

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

1

आपको यह पढ़ने में दिलचस्पी हो सकती है कि GNOME डेस्कटॉप प्रोजेक्ट ने hg और bzr पर git को क्यों चुना, जब उसने कुछ साल पहले svn से स्थानांतरित होने का फैसला किया था। पाठ्यक्रम के रास्ते में कई गर्म धार्मिक चर्चाएं हुईं, लेकिन यह गनोम विकी पृष्ठ उन विशेष समुदाय पर लागू होने वाले पेशेवरों और विपक्षों को अच्छी तरह से बताता है।


0

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

दी गई Xcode 4 केवल कुछ महीनों के लिए ही रही है, और Gits की पिछली सफलता पर कोई प्रभाव नहीं डालती है, लेकिन हम सभी जानते हैं कि Apple कितने कम समय में लोकप्रिय हो सकता है।


-1

मैं वर्तमान में hg (भट्ठा) से git (github) पर स्विच कर रहा हूं। मैंने अभी एक वर्ष के लिए भट्ठा का उपयोग किया है। मेरे लिए hg का कोई नुकसान नहीं है। मुझे वह सब कुछ करना है जो मुझे करना है। तो यह बहुत अच्छा है।

मैं अभी क्यों उपयोग कर रहा हूँ?

अभी केवल तीन कारण हैं।

  1. gitHub उन gists प्रदान करता है जो महान हैं
  2. gitHub महान सामाजिक सुविधाएँ प्रदान करता है
  3. डेवलपर प्रस्तुतियाँ और कार्यशालाएँ करते हुए मैंने हमेशा hg और git पर अपने नमूने प्रकाशित किए। Git पर मैं hg की तुलना में लगभग 10 गुना अधिक आगंतुक हूँ !!

मुझे लगता है कि तीसरा सबसे महत्वपूर्ण है।

Thorsten


-2

शुद्ध भाग्य मुझे लगता है, अब तक यह साबित करना लगभग असंभव है कि कुछ काम क्यों किया और अन्य नहीं किया। लिनुस कुछ और शानदार बना सकते हैं और कोई सफलता नहीं है।

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