क्या मुझे SVN या Git का उपयोग करना चाहिए? [बन्द है]


321

मैं एक नई वितरित परियोजना शुरू कर रहा हूं। क्या मुझे SVN या Git का उपयोग करना चाहिए, और क्यों?


5
हाँ, git मैक पर काम करता है। यदि आप इसे स्थापित करने के लिए macports का उपयोग करते हैं, तो यह एक मैक फ्रंट एंड को कमिट और इंटरफेस ब्राउज़ करने के लिए भी इंस्टॉल करेगा।
सेठ जॉनसन


3
@ और - क्योंकि आप मोनो-डिवेलप का उपयोग कर सकते हैं - मैं वॉल्ट से एसवीएन पर स्विच करता हूं ताकि मैं अपने मैक या पीसी पर .NET सॉफ्टवेयर विकसित कर सकूं। वॉल्ट के लिए कोई क्लाइंट नहीं था, लेकिन SVN :-) के लिए था
schmoopy

यह भी देखें richappsconsulting.com/blog/blog-detail/…
0101

4
गिठुब / बिटबकेट + सार्केट्री = स्वर्ग! - sourcetreeapp.com
thecodeassassin

जवाबों:


253

एसवीएन एक रेपो और बहुत सारे ग्राहक हैं। Git एक ग्राहक के साथ बहुत से रेपो है, प्रत्येक उपयोगकर्ता के साथ। यह एक ऐसे बिंदु पर विकेंद्रीकृत है जहां लोग बाहरी सर्वर पर चीजों को धक्का दिए बिना स्थानीय रूप से अपने स्वयं के संपादन को ट्रैक कर सकते हैं।

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

इस बीच आपके पास TortoiseGit , GitExtensions (और यदि आप अपने "केंद्रीय" gitub पर रिपॉजिटरी, अपने स्वयं के क्लाइंट - विंडोज के लिए GitHub ) को होस्ट करते हैं ।

यदि आप SVN से बाहर निकलना चाह रहे हैं, तो आप बाज़ार का मूल्यांकन थोड़ा कर सकते हैं । यह संस्करण नियंत्रण प्रणालियों की अगली पीढ़ी में से एक है जिसमें यह वितरित तत्व है। यह GOS की तरह POSIX पर निर्भर नहीं है इसलिए देशी विंडोज बिल्ड हैं और इसमें कुछ शक्तिशाली ओपन सोर्स ब्रांड हैं।

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


24
एचजी (बुध)
जोएल

24
अक्टूबर 2008 के बाद से चीजें बहुत बेहतर हो गई हैं। आप TortoiseGit को स्थापित कर सकते हैं, MSysGit के नवीनतम पोर्टेबल संस्करण को पकड़ सकते हैं, और TortoiseGit को बता सकते हैं कि इसे कहां खोजना है। मैं आज अपने बड़े svn रेपो को लेने के लिए आज गया क्योंकि svn के घटिया समर्थन ने आखिरकार मुझे पागल कर दिया।
हम

4
2 साल आगे बढ़ते हुए अब हमारे पास कुछ अच्छे विंडोज़ टूल हैं। वर्तमान में मैं MSysGit के साथ netbeans का उपयोग कर रहा हूं। मैंने कछुआगीत के साथ भी शुभकामनाएँ दी हैं। मुझे लगता है कि उत्पादन में इसका इस्तेमाल किया जाना काफी अच्छा है। यह ध्यान में रखते हुए कि तोड़फोड़ गिट में सरल संघर्षों का प्रबंधन करना कितना कठिन है, एक बहुत बड़ा सुधार है।
कीओ

24
हम विंडोज पर Git का भारी उपयोग करते हैं और लंबे समय तक करते हैं। विंडोज पर गिट बिल्कुल शानदार है।
चार्ली फूल

13
@ ओली आपके जवाब (विंडोज़ git क्लाइंट के बारे में जासूसी) को यहां और आपके अनुभव के आधार पर अपडेट करना अच्छा रहेगा। वर्तमान उत्तर पक्षपाती लगता है कि इसे लिखे हुए 2-3 साल बीत चुके हैं।
अमित

111

"विंडोज पर अच्छा नहीं होने" की इस अवधारणा को मैंने कभी नहीं समझा; मैं विशेष रूप से विंडोज के तहत विकसित करता हूं और मुझे कभी भी गिट के साथ कोई समस्या नहीं हुई है।

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


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

7
@ रोमन: ठीक है, सिग्विन पोर्ट शायद ही मूल win32 पोर्ट के समान है। मुझे उम्मीद है कि Cygwin पोर्ट बहुत कम अच्छी तरह से जांचा हुआ है ...
SamB

49
"शायद आप कभी भी उपयोग करेंगे" से अधिक विशेषताएं मेरी पुस्तक में एक लाल झंडा है
बीटी

26
@ बीटी "लाल झंडा" मैं असहमत हूं। मैं अक्सर खुद को यह चाहता हूँ कि वहाँ कुछ करने का एक तरीका था और थोड़ी खोज के बाद मुझे पता चला कि कुछ कमांड्स हैं जो मुझे नहीं पता था कि बस यही करते हैं। मैं अपनी विंडोज़ मशीन पर भी GIT का उपयोग करता हूं और अभी तक कोई बड़ी समस्या नहीं है।
16:123 पर परीक्षण123

@ test123 लेकिन फिर वे "आप शायद [n] कभी उपयोग करें" की विशेषताएं नहीं हैं क्योंकि आपने वास्तव में उनका उपयोग करना समाप्त कर दिया है।
mulllhausen

77

यहाँ एक उत्तर की एक प्रति है जिसे मैंने कुछ डुप्लिकेट प्रश्न से बनाया है जिसके बाद Git बनाम SVN (सितंबर 2009) के बारे में हटा दिया गया है

बेहतर? सामान्य लिंक WhyGitIsBetterThanX के अलावा , वे अलग हैं:

एक एक सेंट्रल वीसीएस है जो शाखाओं के लिए सस्ती कॉपी पर आधारित है और अन्य टैग्स (Git) एक वितरित VCS है जो संशोधनों के ग्राफ पर आधारित है। VCS की मुख्य अवधारणाएँ भी देखें ।


उस पहले हिस्से ने कुछ गलत सूचनाओं वाली टिप्पणियों को उत्पन्न किया, जिसमें कहा गया था कि दो कार्यक्रमों (एसवीएन और गिट) का मूल उद्देश्य एक ही है, लेकिन उन्हें काफी अलग तरीके से लागू किया गया है। SVN और Git के बीच मूलभूत अंतर
को स्पष्ट करने के लिए , मुझे rephrase दें:

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

  • Git एक फ़ाइल सामग्री प्रबंधन (फ़ाइलों को मर्ज करने के लिए बनाया गया एक उपकरण) है, जो एक वास्तविक संस्करण नियंत्रण प्रणाली में विकसित होता है , जो DAG ( डायरेक्टेड एसाइक्लिक ग्राफ ) पर आधारित होता है, जहाँ शाखाएँ डेटा के इतिहास का हिस्सा होती हैं (और डेटा ही नहीं) ), और जहां टैग एक सच्चे मेटा-डेटा हैं।

यह कहने के लिए कि वे "मौलिक रूप से" अलग नहीं हैं क्योंकि आप एक ही चीज़ को प्राप्त कर सकते हैं, एक ही समस्या को हल कर सकते हैं, वह है ... इतने सारे स्तरों पर सादा झूठ।

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

अभी भी उस पुराने (हटाए गए) जवाब पर टिप्पणी जोर देकर कहते हैं:

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

, जिसके लिए मैंने उत्तर दिया:

"प्रतिस्थापन" ... दिलचस्प शब्द ( कंप्यूटर प्रोग्रामिंग में प्रयुक्त )।
बेशक, गेट शायद ही एसवीएन का एक उपप्रकार है।

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

आप निश्चित रूप से (हमेशा) एसआईएन को Git द्वारा प्रतिस्थापित नहीं कर सकते हैं "" उस प्रोग्राम के किसी भी वांछनीय गुण को बदलने के बिना (शुद्धता, कार्य प्रदर्शन, ...) "(जो उपर्युक्त प्रतिस्थापन योग्य परिभाषा का संदर्भ है ):

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

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

सामान्य अंत-लक्ष्य एक ही हो सकता है, लेकिन आप उन्हें उसी तरह से उपयोग नहीं कर सकते हैं, और न ही आप समस्या के एक ही वर्ग (गुंजाइश या जटिलता में) को हल कर सकते हैं।


10
मैं आपसे असहमत नहीं हूं कि git और svn मौलिक रूप से अलग हैं, लेकिन मैं आपके कई बिंदुओं पर असहमत हूं। sv को cvs को बदलने के लिए लिखा जा सकता है, लेकिन वे किसी भी तरह से संबंधित नहीं हैं, जबकि cvs को RCS के शीर्ष पर स्क्रिप्ट के रूप में शुरू किया गया है, इसलिए इसका सीधा संबंध है। फिर भी, आप जिस व्यक्ति को उद्धृत कर रहे हैं, वह पूरी तरह से सही है, वे दोनों मौलिक रूप से फाइलों के संशोधनों, कार्यान्वयन और उस प्रक्रिया को प्रबंधित करते हैं जिसमें ऐसा होता है (या यह कैसे होता है) कार्यान्वयन विवरण हैं। यह CRC और SHA1 के बीच अंतर की तरह है, मौलिक रूप से बहुत अलग है लेकिन वे एक ही काम करते हैं।
एरिक फनकेनबस

37

SVN के 2 प्रमुख लाभ जो शायद ही कभी उद्धृत किए जाते हैं:

  1. बड़ी फ़ाइल का समर्थन। कोड के अलावा, मैं अपने होम डायरेक्टरी को प्रबंधित करने के लिए SVN का उपयोग करता हूं। एसवीएन एकमात्र वीसीएस (वितरित या नहीं) है जो मेरी ट्रू-क्रिप्ट फ़ाइलों पर चोक नहीं करता है (कृपया मुझे सही करें अगर कोई और वीसीएस है जो 500 एमबी + फ़ाइलों को प्रभावी ढंग से संभालता है)। ऐसा इसलिए है क्योंकि अलग-अलग तुलनाओं को प्रवाहित किया जाता है (यह एक बहुत ही आवश्यक बिंदु है)। Rsync अस्वीकार्य है क्योंकि यह 2-तरफ़ा नहीं है।

  2. आंशिक भंडार (उपखंड) चेकआउट / चेकइन। Mercurial और bzr इसका समर्थन नहीं करते हैं, और git का समर्थन सीमित है। यह टीम के माहौल में खराब है, लेकिन अमूल्य है अगर मैं अपने होम डायर से दूसरे कंप्यूटर पर कुछ जांचना चाहता हूं।

बस मेरे अनुभव।


6
"कृपया मुझे सही करें अगर कोई और VCS है जो 500MB + फ़ाइलों को प्रभावी ढंग से संभालता है" - बेशक!
जेम्स क्रीज

8
पेर्स = गैर मुक्त। इसके अलावा, सभी प्लेटफ़ॉर्म के लिए Perforce उपलब्ध नहीं है।
WhyNotHugo

4
क्यों नहीं SVN रेपो ट्रूक्रिप्टेड कंटेनर डालें? आप यह भी देख सकते हैं कि हालांकि ssh, और सर्वर को उस विशेष रीपो को किसी अन्य truecrypt फ़ाइल में संग्रहीत करने के लिए कॉन्फ़िगर करें। इसका अतिरिक्त लाभ यह है कि आप उस रेपो का आंशिक चेकआउट कर सकते हैं।
WhyNotHugo

1
@ ह्यूगो जहां तक ​​मुझे पता है, Perforce क्लाइंट विंडोज, यूनिक्स, लिनक्स वेरिएंट, मैक, एमिगा, बीओएस, साइगविन, एचपीयूएक्स, आईबीएम एएस / 400, ओएस / 2, डीईसी वीएमएस और नॉवेल सर्वर सर्वर के लिए उपलब्ध है। क्या सूची से कुछ प्रासंगिक प्लेटफ़ॉर्म गायब है?
eis

1
हां, OpenBSD (और मुझे यह अनुभव से पता था, इसे Google की आवश्यकता नहीं थी)। मुझे लगता है कि यह मैमो पर काम नहीं करेगा, हालांकि मैं गलत हो सकता हूं (और हां, मैं मैमो पर गिट का उपयोग करता हूं)।
WhyNotHugo

25

अधिक शोध करने के बाद, और इस लिंक की समीक्षा करें: https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

(नीचे कुछ अर्क):

  • यह अविश्वसनीय रूप से तेज है। मेरे द्वारा उपयोग किया गया कोई भी अन्य SCM इसके साथ बनाए रखने में सक्षम नहीं है, और मैंने बहुत उपयोग किया है, जिसमें सबवर्सन, पेरफोर्स, डार्क्स, बिटकीपर, क्लियरकेस और सीवीएस शामिल हैं।
  • यह पूरी तरह से वितरित है। रिपॉजिटरी मालिक यह तय नहीं कर सकता कि मैं कैसे काम करता हूं। मैं अपने लैपटॉप पर डिस्कनेक्ट होने के दौरान शाखाएं बना सकता हूं और बदलाव कर सकता हूं, फिर बाद में किसी भी अन्य रिपॉजिटरी की संख्या के साथ सिंक्रनाइज़ कर सकता हूं।
  • कई मीडिया पर सिंक्रनाइज़ेशन हो सकता है। एक SSH चैनल, HTTP पर WebDAV के माध्यम से, FTP द्वारा, या संदेश के प्राप्तकर्ता द्वारा लागू किए जाने वाले पैच धारण करने वाले ईमेल भेजकर। एक केंद्रीय भंडार आवश्यक नहीं है, लेकिन इसका इस्तेमाल किया जा सकता है।
  • शाखाएँ तोड़फोड़ की तुलना में सस्ती हैं। एक शाखा बनाना उतना ही सरल है जितना कि डिस्क पर 41 बाइट फ़ाइल लिखना। किसी शाखा को हटाना उस फ़ाइल को हटाने के समान सरल है।
  • तोड़फोड़ शाखाओं के विपरीत अपने पूरे इतिहास के साथ ले जाते हैं। एक अजीब प्रतिलिपि प्रदर्शन करने और कॉपी के माध्यम से चलने के बिना। तोड़फोड़ का उपयोग करते समय मैंने हमेशा शाखा पर एक फ़ाइल के इतिहास को देखने के लिए अजीब पाया जो शाखा बनने से पहले हुई थी। #git: भाला से: मुझे पेज में SVN के बारे में एक बात समझ में नहीं आती है। मैंने एक शाखा बनाई जिसमें मैंने SVN किया और इतिहास को ब्राउज़ करते हुए पूरे इतिहास को शाखा में एक फ़ाइल दिखाया
  • Git में शाखा विलय सरल और अधिक स्वचालित है। तोड़फोड़ में आपको यह याद रखने की आवश्यकता है कि आपके द्वारा विलय किया गया अंतिम संशोधन क्या था जिससे आप सही मर्ज कमांड उत्पन्न कर सकते हैं। Git यह स्वचालित रूप से करता है, और हमेशा इसे सही करता है। इसका मतलब है कि दो शाखाओं को एक साथ विलय करने पर गलती करने की कम संभावना है।
  • शाखा विलय को भंडार के उचित इतिहास के हिस्से के रूप में दर्ज किया गया है। यदि मैं दो शाखाओं को एक साथ मर्ज करता हूं, या यदि मैं एक शाखा को उस ट्रंक में वापस मिलाता हूं, जहां से यह आया है, तो मर्ज ऑपरेशन को मेरे द्वारा किए जाने वाले प्रजनन इतिहास के हिस्से के रूप में दर्ज किया गया है और जब। यह विवाद करना मुश्किल है कि लॉग में सही होने पर मर्ज किसने किया।
  • भंडार बनाना एक तुच्छ कार्य है: mkdir foo; सीडी फू; git init यह बात है। जिसका मतलब है कि मैं इन दिनों हर चीज के लिए एक जीआईटी रिपॉजिटरी बनाता हूं। मैं प्रति कक्षा एक रिपॉजिटरी का उपयोग करता हूं। उन रिपॉजिटरी में से अधिकांश डिस्क में 1 एमबी से कम के होते हैं क्योंकि वे केवल लेक्चर नोट्स, होमवर्क असाइनमेंट और मेरे लाटेक्स उत्तरों को स्टोर करते हैं।
  • रिपॉजिटरी के आंतरिक फ़ाइल प्रारूप अविश्वसनीय सरल हैं। इसका मतलब है कि मरम्मत करना बहुत आसान है, लेकिन इससे भी बेहतर है क्योंकि यह भ्रष्ट होने के लिए बहुत सरल है। मुझे नहीं लगता कि किसी ने कभी भी एक जीआई रिपॉजिटरी को भ्रष्ट कर दिया है। मैंने देखा है कि तोड़फोड़ fsfs के साथ ही भ्रष्ट है। और मैंने अपने कोड को तोड़फोड़ के bdb बैकेंड पर भरोसा करने के लिए कई बार खुद बर्कले डीबी को भ्रष्ट देखा है।
  • Git का फाइल फॉर्मेट डाटा को कंप्रेस करने में बहुत अच्छा है, इसके बावजूद यह बहुत ही सरल फॉर्मेट है। मोज़िला परियोजना का सीवीएस भंडार लगभग 3 जीबी है; यह तोड़फोड़ के fsfs प्रारूप में लगभग 12 जीबी है। Git में यह लगभग 300 MB है।

यह सब पढ़ने के बाद, मुझे यकीन है कि Git जाने का रास्ता है (हालाँकि सीखने की थोड़ी सी मात्रा मौजूद है)। मैंने विंडोज प्लेटफॉर्म पर भी Git और SVN का इस्तेमाल किया है।

मुझे यह सुनकर अच्छा लगेगा कि ऊपर पढ़ने के बाद दूसरों को क्या कहना है?


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

1
@ ईडविनबक वकार के खाते में नहीं जाने पर भी, नेटवर्क समय के साथ परीक्षण में भी, इस बात को ध्यान में रखते हुए कि यह तेजी से होता है: git-scm.com/about/small-and-fast
Sqeaky

आपका "एक रिपॉजिटरी बनाना एक तुच्छ ऑपरेशन है" बिंदु अत्यधिक महत्वपूर्ण है, विशेष रूप से विंडोज पर: एसवीएन की तुलना में, यह बहुत जल्दी से इंटरकनेक्टेड डिस्ट्रीब्यूटेड रेपो के झुंड का अनुकरण करना आसान है, सभी एक केंद्रीय (-बारे) - रेपो के साथ बँधा हुआ है। यह एसवीएन (विंडोज एसवीएन सर्वर एप्लिकेशन को स्थापित करना आदि) के अनुरूप करना है। इसके अलावा (विचित्र रूप से) मुझे Git OS के पार अधिक सुसंगत लगता है: कमांड लाइन बहुत अच्छी तरह से डिज़ाइन की गई है और इस प्रकार अधिकांश समय (और लगभग OSs के बीच समान) बनाम विभिन्न SVN देशी क्लाइंट / सर्वर ऐप ...
शिवन ड्रैगन

1
आपके द्वारा संदर्भित विकि लेख गलतियों से भरा है। इसलिए, आपका उत्तर गलत है। Downvoted। विकी पर एक वार्ता पृष्ठ है जो svnvsgit.com को बताता है कि तुलना गलत क्यों है।
बरहप

अविश्वसनीय रूप से तेज? मैंने ciforth प्रोजेक्ट को एक स्थानीय cvs से github में स्थानांतरित कर दिया है। यह एक सरल परियोजना है लेकिन 10,000 लाइनों की एक बड़ी मुख्य स्रोत फ़ाइल है। अगर मैं इस फ़ाइल पर दोष का उपयोग करने की कोशिश करता हूं तो एक समय समाप्त हो जाता है। ज़्यादातर अगर कोई तेज़ बोलने से संतुष्ट नहीं है, और इस तरह के क्वालीफ़ायर का इस्तेमाल करने पर ज़ोर देता है, तो यह एक संतुलित राय नहीं है, जिससे मुझे आपके कहने पर संदेह हो सकता है। Groetjes अल्बर्ट
Albert van der Horst

12

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

मेरा मानना ​​है कि यह एक अपेक्षाकृत कम समय होगा जब Git विंडोज पर काम करता है और साथ ही यह Unix और Mac OS X (जब से मैंने पूछा है) पर काम करता है।

विंडोज के लिए सबवर्सन में उत्कृष्ट उपकरण होते हैं, जैसे कि एक्सप्लोरर एकीकरण के लिए TortoiseSVN और Visual Studio एकीकरण के लिए AnkhSVN।


11

मजेदार बात यह है: मैं प्रोजेक्ट्स को तोड़फोड़ के प्रस्ताव में होस्ट करता हूं, लेकिन उन्हें Git Clone कमांड के जरिए एक्सेस करता हूं।

कृपया Google कोड प्रोजेक्ट पर विकास के साथ पढ़ें

यद्यपि Google कोड मूल रूप से तोड़फोड़ बोलता है, आप आसानी से विकास के दौरान Git का उपयोग कर सकते हैं। "Git svn" की खोज से यह पता चलता है कि यह प्रथा व्यापक है, और हम आपको इसके साथ प्रयोग करने के लिए प्रोत्साहित करते हैं।

Svn रिपोजिटरी पर Git का उपयोग करने से मुझे लाभ मिलता है:

  1. मैं कई मशीनों पर वितरित कर सकता हूं , कमिंग और उनसे और खींचने के लिए
  2. मेरे पास दूसरों की जाँच के लिए एक केंद्रीय backup/public svn भंडार है
  3. और वे अपने स्वयं के लिए गिट का उपयोग करने के लिए स्वतंत्र हैं

3
बस एक नोट: जुलाई 2011 तक, Google कोड मूल रूप से Git का समर्थन करता है।
जेरेमी सलवेन

9

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


9

यदि आपकी टीम पहले से ही cvs या svn जैसे संस्करण और स्रोत नियंत्रण सॉफ्टवेयर्स से परिचित है, तो, एक सरल और छोटी परियोजना के लिए (जैसे कि आप यह दावा करते हैं), मैं आपको SVN से चिपके रहने की सलाह दूंगा। मैं svn के साथ वास्तव में सहज हूं, लेकिन वर्तमान ई-कॉमर्स परियोजना के लिए मैं django पर काम कर रहा हूं, मैंने गिट पर काम करने का फैसला किया है (मैं svn-mode में git का उपयोग कर रहा हूं, अर्थात, एक केंद्रीकृत रेपो के साथ जिसे मैं धक्का देने और खींचने के लिए करता हूं कम से कम एक अन्य डेवलपर के साथ सहयोग करने के लिए)। अन्य डेवलपर एसवीएन के साथ सहज है, और जबकि अन्य के अनुभव भिन्न हो सकते हैं, हम दोनों को इस छोटे से प्रोजेक्ट के लिए एक बहुत बुरा समय आ गया है। (हम दोनों कट्टर लिनक्स उपयोगकर्ता हैं, अगर यह बिल्कुल भी मायने रखता है।)

सचमुच में, आपका माइलेज अलग अलग हो सकता है।


8

निश्चित रूप से svn, चूंकि विंडोज़ दुनिया में सबसे अच्छा-एक द्वितीय श्रेणी का नागरिक है git( अधिक विवरण के लिए http://en.wikipedia.org/wiki/Git_(software)#Portability देखें)।

अद्यतन: टूटी हुई लिंक के लिए क्षमा करें, लेकिन मैंने URI के साथ काम करने के लिए SO पाने की कोशिश की है जिसमें कोष्ठक शामिल हैं। [लिंक अब ठीक किया गया। -ईडी]


1
FYI करें: कोण कोष्ठक में URL संलग्न करें, या कोष्ठक को 28% और 29% के साथ बदलें।
फीलो

1
क्या URL- एन्कोडिंग [] (सिंटैक्स) के लिए काम करेगा?
हांक गे

16
यह गलत FUD है। विंडोज पर गिट शानदार है। और SVN हर जगह बहुत बुरा है।
चार्ली फूल

6
उन सभी के लिए जो मुझे नीचा दिखा रहे हैं, कृपया वापस जाएं और लगभग 2008 की डेवलपर टिप्पणियों को देखें: यह बहुत स्पष्ट है कि लिनुस और गिरोह ने विंडोज का समर्थन करने की परवाह नहीं की। यह ठीक है: मैं वास्तव में इसे या तो नहीं करना चाहता, और मेरा सॉफ्टवेयर लगभग उतना ही जटिल नहीं है जितना कि VCS जो कि फाइलसिस्टम से POSIXish व्यवहार की अपेक्षा करता है। यदि आप संदर्भ को देखें तो यह मेरे कथन को FUD के रूप में वर्णित करना अनुचित लगता है।
हांक गे

2
शायद 2008 में git विंडोज पर खराब था, लेकिन मैं 2009 से msysgit का उपयोग कर रहा हूं और यह त्रुटिपूर्ण रूप से काम करता है। इसमें GitHub के समकक्ष डेस्कटॉप, gitk शामिल है।
दान डैस्कलेस्कु

8

मुख्य बिंदु यह है कि Git एक वितरित VCS और सबवर्सन एक केंद्रीकृत है। वितरित वीसीएस को समझना थोड़ा मुश्किल है, लेकिन इसके कई फायदे हैं। यदि आपको इस लाभ की आवश्यकता नहीं है, तो तोड़फोड़ बेहतर विकल्प हो सकता है।

एक और सवाल टूल-सपोर्ट का है। आपके द्वारा उपयोग किए जाने वाले उपकरणों के लिए कौन सा VCS बेहतर समर्थित है?

संपादित करें: तीन साल पहले मैंने इस तरह से उत्तर दिया:

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

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


मैं आशावादी हूं कि अप्रासंगिकता का क्षितिज कुछ वर्षों की तुलना में बहुत कम होगा।
ग्रेग हेविगेल

हां, संभवतः यह केवल एक वर्ष होगा। Git का एक गतिशील विकास-समुदाय है। लेकिन तोड़फोड़ भी की है। एक या दो साल में आपको इस प्रश्न का उत्तर देने के लिए दोनों को फिर से देखना होगा।
Mnementh

1
यह अब एक या दो साल बाद है। कैसा लग रहा है? :)
मेरलिन मॉर्गन-ग्राहम

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

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

6

मैं SVN के लिए विकल्प चुनूंगा क्योंकि यह अधिक व्यापक रूप से फैला हुआ है और बेहतर ज्ञात है।

मुझे लगता है, Git लिनक्स उपयोगकर्ता के लिए बेहतर होगा।


1
हालांकि, यह जल्दी से बदल रहा है। : SVN बाजार हिस्सेदारी खो देता है, जबकि GIT लाभ: उदाहरण के लिए wikivs.com/wiki/Git_vs_Subversion#Popularity या programmers.stackexchange.com/questions/136079/...
Zelphir Kaltstahl

@Zelphir: मैं 7 साल जल्दी फोन नहीं करूंगा, लेकिन हां, जीआईटी को बाजार में हिस्सेदारी हासिल है और यह विशेष रूप से फाइलों को मर्ज करने के लिए बेहतर है।
बुर्खर्ड

4

Git मूल रूप से विंडोज के तहत समर्थित नहीं है, बस अभी तक। यह Posix सिस्टम के लिए अनुकूलित है। हालाँकि Cygwin या MinGW चलाने से आप Git को सफल बना सकते हैं।

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


8
'देशी' को परिभाषित कीजिए। msysgit बस ठीक काम करता है
मिलन बाबुकोव

4

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

उस ने कहा, मुझे विजुअल स्टूडियो के एकीकरण और विभिन्न SCM प्रणालियों के बारे में कुछ भी पता नहीं है। मैं विशेष रूप से बेहतर SVN के साथ एकीकरण की कल्पना करता हूं।


4

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

मैंने जो नोट किया है वह यह है कि जब तक यह निर्यात नहीं किया जाता है, तब तक प्रत्येक एसवीएन परियोजना, बड़े आकार की परियोजना बन जाती है। जहां के रूप में, GIT प्रोजेक्ट (Git डेटा के साथ) आकार में बहुत हल्का है।

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

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

कोई भी जो मुझे यह तय करने में मदद कर सकता है कि क्या मुझे वास्तव में गिट के साथ जाना चाहिए?


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

3
नवीनतम svn क्लाइंट .svnको प्रत्येक उप-निर्देशिका में फ़ोल्डर की आवश्यकता नहीं होती है । ऐसा होने से पहले कॉपी करने की त्रुटि को "ठीक" करता है।
एडविन बक

4

यह इस स्तर तक नीचे आता है:

क्या आपका विकास रैखिक होगा? यदि ऐसा है, तो आपको तोड़फोड़ के साथ रहना चाहिए।

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


3

क्या आपने बज़्र की कोशिश की है ?

यह बहुत अच्छा है, सामंजस्यपूर्ण (जो लोग उबंटू बनाते हैं) ने इसे बनाया क्योंकि उन्हें बाजार पर कुछ और पसंद नहीं था ...


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

यह ओएस के साथ लगभग 100% समय था, कि लोगों ने "इसे [कोई सॉफ़्टवेयर] बनाया क्योंकि बाजार में कुछ और पसंद नहीं था"।
WhyNotHugo

@ ह्यूगो ओपन सोर्स के साथ, अगर उन्हें बाजार में कुछ और पसंद है, तो वे कुछ नया बनाने के बजाय इसमें योगदान करेंगे।
yingted

यह सवाल का जवाब नहीं है
अल्बर्ट वैन डेर होर्स्ट

@AlbertvanderHorst नहीं, यह सवाल नहीं है, तो SO के जंगली पश्चिम दिनों में इस सवाल का जवाब दिया गया था जब कोई भी बेहतर नहीं जानता था, और एक विकल्प की पेशकश की। मेरी जल्दबाजी में तर्क यह लगता है कि मैंने भी कैननिकल का नाम याद कर लिया है। मुझ पर शर्म की बात है!
उमर कूहीजी

3

क्या मुझे इस सवाल पर विस्तार करना चाहिए और पूछना चाहिए कि क्या Git MacOS पर अच्छा काम करता है?

टिप्पणी का जवाब: समाचार के लिए धन्यवाद, मैं इसे आज़माने के लिए उत्सुक हूं। मैं इसे अपने मैक पर घर पर स्थापित करूँगा।


1
हां, यह खूबसूरती से काम करता है। मैंने इसे MacPorts के माध्यम से स्थापित किया और इसका दैनिक उपयोग किया।
ग्रेग हेविगेल

ऐसा होता है। यह किसी भी POSIX- आधारित प्रणाली (यूनिक्स, लिनक्स, सोलारिस, बीएसडी, आदि) पर बहुत अच्छा है। यह वास्तव में सिर्फ विंडोज है जहां समस्या निहित है।
ओली

और git-gui और gitk शायद OS-X के समान लिनक्स और विंडोज के तहत काम करते हैं। TortoiseSVN के विपरीत, जो AFAIK केवल विंडोज़ है?
डेविड श्मित

@ डेविड शमित: अच्छी तरह से, tortoisesvn.tigris.org इसे "विंडोज शेल एक्सटेंशन फॉर सबवेर्शन" कहता है, इसलिए मैं ऐसा मानता हूँ, हाँ ;-)।
सामब

@ रॉबर्ट: ओएस एक्स पर आपके अनुभव कैसे थे?
डेविड श्मिट


2

एसवीएन विंडोज के तहत एक अच्छा विकल्प लगता है, जैसा कि अन्य लोगों द्वारा बताया गया है।

यदि आपका कोई विकासकर्ता GIT आज़माना चाहता है, तो वह हमेशा GIT-SVN का उपयोग कर सकता है जहाँ SVN रिपॉजिटरी को GIT रिपॉजिटरी में पुनः बनाया जाता है। फिर उसे जीआईटी के साथ स्थानीय रूप से काम करने में सक्षम होना चाहिए और फिर मुख्य रिपॉजिटरी में इसके परिवर्तनों को प्रकाशित करने के लिए एसवीएन का उपयोग करना चाहिए।


1

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

DVCS को वितरित करते समय आमतौर पर इसका मतलब है कि आप लोगों के लिए परिवर्तनों को आगे बढ़ाने के लिए सिर्फ एक केंद्रीय सर्वर बनाएंगे।

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