मुख्य अंतर यह है कि (जैसा कि पहले से ही अन्य प्रतिक्रियाओं में कहा गया था) सीवीएस (पुराना) केंद्रीकृत संस्करण नियंत्रण प्रणाली है, जबकि गिट वितरित किया जाता है।
यदि आप एकल मशीन (एकल खाते) पर एकल डेवलपर के लिए संस्करण नियंत्रण का उपयोग करते हैं, तो भी Git और CVS के बीच कुछ अंतर हैं:
रिपॉजिटरी की स्थापना । .gitआपकी परियोजना की शीर्ष निर्देशिका में निर्देशिका में भंडार भंडार ; CVS को विभिन्न परियोजनाओं (मॉड्यूल) के लिए संस्करण नियंत्रण जानकारी संग्रहीत करने के लिए केंद्रीय स्थान CVSROOT स्थापित करने की आवश्यकता होती है। उपयोगकर्ता के लिए उस डिज़ाइन का परिणाम यह है कि संस्करण नियंत्रण में मौजूदा स्रोतों को आयात करना उतना ही सरल है जितना कि Git में "git init && git add। && git कमिट", जबकि यह CVS में अधिक जटिल है।
परमाणु संचालन । क्योंकि सीवीएस शुरुआत में प्रति-फ़ाइल आरसीएस संस्करण नियंत्रण प्रणाली के आसपास स्क्रिप्ट का एक सेट था, सीवीएस में कमिट (और अन्य संचालन) परमाणु नहीं हैं; यदि रिपॉजिटरी पर एक ऑपरेशन बीच में बाधित हो जाता है, तो रिपॉजिटरी को असंगत स्थिति में छोड़ा जा सकता है। Git में सभी ऑपरेशन परमाणु हैं: या तो वे पूरे के रूप में सफल होते हैं, या वे बिना किसी बदलाव के विफल हो जाते हैं।
परिवर्तन । सीवीएस में परिवर्तन प्रति फ़ाइल है, जबकि परिवर्तन (कमिट) में वे हमेशा पूरे प्रोजेक्ट को संदर्भित करते हैं। यह बहुत महत्वपूर्ण प्रतिमान बदलाव है । इसके परिणामों में से एक यह है कि Git को पलटना (ऐसा परिवर्तन जो पूर्ववत् करता है) या पूरे परिवर्तन को पूर्ववत करना बहुत आसान है ; अन्य परिणाम यह है कि CVS में आंशिक चेकआउट करना आसान है, जबकि वर्तमान में Git में यह असंभव है। तथ्य यह है कि परिवर्तन प्रति फ़ाइल हैं, एक साथ समूहीकृत सीवीएस में प्रतिबद्ध संदेशों के लिए जीएनयू चेंगलॉग प्रारूप का आविष्कार किया गया; Git उपयोगकर्ता (और कुछ Git उपकरण उम्मीद करते हैं) अलग-अलग कन्वेंशन का उपयोग करते हैं, जिसमें सिंगल लाइन डिस्क्रिमिनेशन (संक्षेप) में परिवर्तन होता है, उसके बाद खाली लाइन, उसके बाद परिवर्तनों का अधिक विस्तृत विवरण होता है।
नामकरण संशोधन / संस्करण संख्या । इस तथ्य से जुड़ा एक और मुद्दा यह है कि सीवीएस में परिवर्तन प्रति फाइलों में होता है: संस्करण संख्या (जैसा कि आप कभी-कभी कीवर्ड विस्तार में देख सकते हैं , नीचे देखें) जैसे 1.4 दर्शाता है कि कितनी बार दी गई फ़ाइल को बदल दिया गया है। एक पूरे के रूप में एक परियोजना के प्रत्येक संस्करण को पकड़ें (प्रत्येक कमिट) में SHA-1 आईडी द्वारा दिया गया अपना अनूठा नाम है; आमतौर पर पहले 7-8 अक्षर एक कमिट की पहचान करने के लिए पर्याप्त होते हैं (आप वितरित संस्करण नियंत्रण प्रणाली में संस्करणों के लिए सरल नंबरिंग योजना का उपयोग नहीं कर सकते हैं - जिसमें केंद्रीय नंबरिंग प्राधिकरण की आवश्यकता होती है)। CVS में आपके द्वारा टैग का उपयोग करने पर परियोजना की स्थिति का उल्लेख करते हुए संस्करण संख्या या प्रतीकात्मक नाम है; यदि आप किसी प्रोजेक्ट के कुछ संस्करण के लिए 'v1.5.6-rc2' जैसे नाम का उपयोग करना चाहते हैं तो Git में भी यही सच है ... लेकिन Git में टैग का उपयोग करना बहुत आसान है।
आसान शाखा । सीवीएस में शाखाएं मेरी राय में जटिल हैं, और इससे निपटने के लिए कठिन हैं। आपको संपूर्ण रिपॉजिटरी शाखा के लिए एक नाम रखने के लिए शाखाओं को टैग करना होगा (और यहां तक कि कुछ मामलों में विफल हो सकता है, अगर मुझे सही ढंग से याद है, प्रति फ़ाइल हैंडलिंग के कारण)। इस तथ्य को जोड़ें कि CVS में मर्ज ट्रैकिंग नहीं है , इसलिए आपको या तो याद रखना होगा, या मैन्युअल रूप से टैग्स और ब्रांचिंग पॉइंट्स को टैग करना होगा, और शाखाओं को मर्ज करने के लिए "cvs अपडेट -j" के लिए मैन्युअल रूप से सही जानकारी की आपूर्ति करनी होगी, और यह ब्रांचिंग के लिए बनाता है। उपयोग करने के लिए अनावश्यक कठिन होना। Git में ब्रांच बनाना और विलय करना बहुत आसान है; Git को सभी आवश्यक जानकारी अपने आप याद हो जाती है (इसलिए एक शाखा को मिलाना "git merge branchname " के रूप में आसान है ) ... यह था, क्योंकि वितरित विकास स्वाभाविक रूप से कई शाखाओं तक ले जाता है।
इसका मतलब है कि आप विषय शाखाओं का उपयोग करने में सक्षम हैं , अर्थात अलग-अलग सुविधा शाखा में कई चरणों में एक अलग सुविधा विकसित करें।
नाम बदलें (और प्रतिलिपि) ट्रैकिंग । सीवीएस में फ़ाइल नाम का समर्थन नहीं किया जाता है, और मैनुअल नाम बदलने से इतिहास दो में टूट सकता है, या अमान्य इतिहास हो सकता है जहां आप नाम बदलने से पहले किसी प्रोजेक्ट की स्थिति को सही ढंग से पुनर्प्राप्त नहीं कर सकते हैं। Git सामग्री और फ़ाइल नाम की समानता के आधार पर अनुमानी नाम का पता लगाने का उपयोग करता है (यह समाधान अभ्यास में अच्छी तरह से काम करता है)। आप फ़ाइलों की प्रतिलिपि का पता लगाने का भी अनुरोध कर सकते हैं। इस का मतलब है कि:
- निर्दिष्ट जांच करते समय आपको जानकारी मिलेगी कि कुछ फ़ाइल का नाम बदल दिया गया था,
- विलय को सही ढंग से नाम में लेता है (उदाहरण के लिए यदि फ़ाइल का केवल एक शाखा में नाम बदला गया था)
- "git blame", (cvs एनोटेट) के बराबर (बेहतर), एक फ़ाइल सामग्री के लाइन-वार इतिहास को दिखाने के लिए एक उपकरण, कोड नाम का भी अनुसरण कर सकता है।
बाइनरी फाइलें । CVS में केवल बाइनरी फ़ाइलों (उदाहरण के लिए चित्र) के लिए एक बहुत ही सीमित समर्थन है, जिससे उपयोगकर्ताओं को बाइनरी फ़ाइलों को स्पष्ट रूप से जोड़ते समय (या बाद में "cvs व्यवस्थापक" का उपयोग करते हुए, या आवरणों के माध्यम से स्वचालित रूप से ऐसा करने के लिए आवश्यक है कि फ़ाइल नाम के आधार पर), मैनिंजिंग से बचने के लिए एंड-ऑफ-लाइन रूपांतरण और कीवर्ड विस्तार के माध्यम से बाइनरी फ़ाइल। Git स्वचालित रूप से उसी तरह से सामग्री के आधार पर बाइनरी फ़ाइल का पता लगाता है जैसे CNU भिन्न होता है और अन्य उपकरण इसे करते हैं; आप gitattributes तंत्र का उपयोग करके इस पहचान को ओवरराइड कर सकते हैं। इसके अलावा द्विआधारी फाइलें अप्राप्य मैन्बलिंग के खिलाफ सुरक्षित हैं 'डिफ़ॉल्ट रूप से सुरक्षित करने के लिए धन्यवाद' (और तथ्य यह है कि आपको अंत-लाइन रूपांतरण का अनुरोध करना होगा, हालांकि यह वितरण के आधार पर डिफ़ॉल्ट रूप से चालू हो सकता है), और वह (सीमित) कीवर्ड: विस्तार Git में एक सख्त 'ऑप्ट-इन' है।
कीवर्ड विस्तार । CVS (डिफ़ॉल्ट रूप से) की तुलना में Git कीवर्ड का एक बहुत ही सीमित सेट प्रदान करता है। यह दो तथ्यों के कारण होता है: Git में परिवर्तन प्रति भंडार के अनुसार होते हैं और प्रति फ़ाइल नहीं होते हैं, और Git उन फ़ाइलों को संशोधित करने से बचता है, जो दूसरी शाखा में जाने पर या इतिहास के अन्य बिंदु पर रिवाइंड करने पर नहीं बदलती। यदि आप Git का उपयोग करके संशोधन संख्या को एम्बेड करना चाहते हैं, तो आपको लिनक्स बिल्ड कर्नेल स्रोतों और Git स्रोतों में GIT-VERSION-GEN स्क्रिप्ट के उदाहरण के बाद अपने बिल्ड सिस्टम का उपयोग करके ऐसा करना चाहिए।
संशोधन करना । क्योंकि वितरित VCS में जैसे कि Git एक्ट ऑफ पब्लिशिंग एक कमिट बनाने से अलग है, कोई अन्य उपयोगकर्ताओं को असुविधाजनक किए बिना इतिहास के अप्रकाशित हिस्से को बदल सकता है (संपादित कर सकता है, फिर से लिख सकता है)। विशेष रूप से यदि आप कमिट मैसेज में टाइपो (या अन्य त्रुटि), या कमिट में बग देखते हैं, तो आप बस "git कमिट - मेमेंड" का उपयोग कर सकते हैं। सीवीएस में यह संभव नहीं है (कम से कम भारी हैकरी के बिना नहीं)।
अधिक उपकरण । Git CVS की तुलना में बहुत अधिक उपकरण प्रदान करता है। अधिक महत्वपूर्ण में से एक " गिट बिसेक्ट " है जिसका उपयोग एक कमिट (संशोधन) खोजने के लिए किया जा सकता है जिसने बग की शुरुआत की; यदि आपके कमिट छोटे और स्व-निहित हैं, तो यह पता लगाना आसान है कि बग कहाँ है।
यदि आप कम से कम एक अन्य डेवलपर के साथ सहयोग कर रहे हैं, तो आपको Git और CVS के बीच निम्नलिखित अंतर भी मिलेंगे:
मर्ज करने से पहले प्रतिबद्ध Git CVS, मर्ज-पहले- (या अपडेट-तब-कमिट ) की तरह कम -से-मर्ज का उपयोग करता है । यदि आप फ़ाइलों का संपादन कर रहे थे, तो नई प्रतिबद्ध (नया संशोधन) बनाने की तैयारी कर रहे थे कि किसी अन्य ने उसी शाखा पर नई कमेटी बनाई और यह अब रिपॉजिटरी में है, सीवीएस आपको काम करने की अनुमति देने से पहले अपनी वर्किंग डायरेक्टरी को अपडेट करने और विवादों को हल करने के लिए मजबूर करता है। गित के साथ ऐसा नहीं है। आप पहले अपने राज्य को संस्करण नियंत्रण में सहेजते हैं, फिर आप अन्य डेवलपर परिवर्तनों को मर्ज करते हैं। आप दूसरे डेवलपर से मर्ज करने और विवादों को सुलझाने के लिए भी कह सकते हैं।
यदि आप रैखिक इतिहास पसंद करते हैं और मर्ज से बचते हैं, तो आप हमेशा "git rebase" (और "git pull --rebase") के माध्यम से कम -मर्ज- री-कॉम्पट वर्कफ़्लो का उपयोग कर सकते हैं , जो CVS के समान है जिसमें आप शीर्ष पर अपने परिवर्तनों को दोहराते हैं। अद्यतन स्थिति के। लेकिन आप हमेशा पहले करते हैं।
सेंट्रल रिपॉजिटरी की कोई आवश्यकता नहीं है Git के साथ एकल केंद्रीय स्थान की आवश्यकता नहीं है जहां आप अपने परिवर्तन करते हैं। प्रत्येक डेवलपर की अपनी रिपॉजिटरी हो सकती है (या बेहतर रिपॉजिटरी: निजी वह जिसमें वह / वह विकास करता है, और सार्वजनिक नंगे जहां वह / वह उस हिस्से को प्रकाशित करता है जो तैयार है), और वे एक दूसरे के रिपॉजिटरी से खींच / निकाल सकते हैं, सममित फैशन। दूसरी ओर बड़ी परियोजना के लिए सामाजिक रूप से परिभाषित / नामांकित केंद्रीय भंडार होना आम बात है जहां से हर कोई (इससे परिवर्तन प्राप्त करें) खींचता है।
जब बड़ी संख्या में डेवलपर्स के साथ सहयोग की आवश्यकता होती है तो अंत में गिट कई और संभावनाएं प्रदान करता है। नीचे एक परियोजना में ब्याज और स्थिति के विभिन्न चरणों के लिए गिट में सीवीएस के बीच अंतर हैं (सीवीएस या गिट का उपयोग करके संस्करण नियंत्रण के तहत):
दुबका हुआ । यदि आप किसी परियोजना से नवीनतम परिवर्तन प्राप्त करने में रुचि रखते हैं, ( आपके परिवर्तनों का कोई प्रसार नहीं है ), या निजी विकास कर रहे हैं (मूल परियोजनाओं में वापस योगदान किए बिना); या आप अपनी खुद की परियोजना के आधार पर विदेशी परियोजनाओं का उपयोग करते हैं (परिवर्तन स्थानीय हैं और उन्हें प्रकाशित करने का कोई मतलब नहीं है)।
Git यहां कस्टम अनौपचारिक प्रोटोकॉल के माध्यम से गुमनाम अनएन्थेंटेड रीड-ओनली एक्सेस का समर्थन करता है git://, या यदि आप फ़ायरवॉल ब्लॉक करने के पीछे हैं DEFAULT_GIT_PORT(9418) तो आप सादे HTTP का उपयोग कर सकते हैं।
सीवीएस के लिए सबसे आम समाधान (जैसा कि मैं इसे समझता हूं) रीड-ओनली एक्सेस के लिए (2401) पर 'प्रेवर्स' प्रोटोकॉल के लिए अतिथि खाता हैCVS_AUTH_PORT , जिसे आमतौर पर "अनाम" कहा जाता है और खाली पासवर्ड के साथ। क्रेडेंशियल $HOME/.cvspassफ़ाइल में डिफ़ॉल्ट रूप से संग्रहीत होते हैं , इसलिए आपको इसे केवल एक बार प्रदान करना होगा; फिर भी, यह थोड़ा अवरोध है (आपको अतिथि खाते का नाम जानना होगा, या सीवीएस सर्वर संदेशों पर ध्यान देना होगा) और झुंझलाहट।
फ्रिंज डेवलपर (पत्ती योगदानकर्ता) । ओएसएस में आपके परिवर्तनों के प्रचार का एक तरीका ईमेल के माध्यम से पैच भेजना है । यह सबसे आम समाधान है यदि आप (अधिक या कम) आकस्मिक डेवलपर हैं, एकल परिवर्तन, या एकल बगफिक्स भेज रहे हैं। Btw। पैच भेजने की समीक्षा बोर्ड (पैच रिव्यू सिस्टम) या इसी तरह के माध्यम से हो सकती है, न केवल ईमेल के माध्यम से।
Git यहां उपकरण प्रदान करता है जो प्रेषक (क्लाइंट) और अनुचर (सर्वर) दोनों के लिए इस प्रचार (प्रकाशन) तंत्र में मदद करते हैं। उन लोगों के लिए जो ईमेल के माध्यम से अपने परिवर्तन भेजना चाहते हैं, " git rebase " (या "git pull --rebase") उपकरण अपस्ट्रीम संस्करण के शीर्ष पर अपने स्वयं के परिवर्तनों को फिर से खेलना है, इसलिए आपके परिवर्तन वर्तमान संस्करण के शीर्ष पर हैं (ताज़ा हैं ), और कमिट मैसेज (और ऑथरशिप) के साथ ईमेल बनाने के लिए " git फॉर्मेट-पैच ", (विस्तृत) यूनिफाइड डिफ फॉर्मेट (और आसान रिव्यू के लिए प्लसस्टैट) के रूप में बदलाव। अनुचर इस तरह के ईमेल को " git am " का उपयोग करके सभी जानकारी (प्रतिबद्ध संदेश सहित) को संरक्षित करने के लिए सीधे चालू कर सकता है ।
सीवीएस ऐसे कोई उपकरण प्रदान नहीं करता है: आप परिवर्तन उत्पन्न करने के लिए "cvs diff" / "cvs rdiff" का उपयोग कर सकते हैं, और परिवर्तन लागू करने के लिए GNU पैच का उपयोग कर सकते हैं, लेकिन जहाँ तक मुझे पता है कि लागू संदेश को स्वचालित करने का कोई तरीका नहीं है। CVS का उपयोग क्लाइंट <-> सर्वर फ़ैशन में किया जाना था ...
लेफ्टिनेंट । यदि आप किसी प्रोजेक्ट (सबसिस्टम) के अलग-अलग हिस्से के मेंटेनर हैं, या अगर आपके प्रोजेक्ट का विकास लिनक्स कर्नेल के विकास में उपयोग किए जाने वाले "ट्रस्ट ऑफ नेटवर्क" वर्कफ़्लो का अनुसरण करता है ... या सिर्फ अगर आपके पास अपना पब्लिक रिपॉजिटरी है, और आपके द्वारा किए गए परिवर्तन। पैच श्रृंखला के रूप में ईमेल के माध्यम से भेजने के लिए प्रकाशित करना चाहते हैं , आप परियोजना के अनुरक्षक (मुख्य) को अनुरोध भेज सकते हैं ।
यह वितरित संस्करण नियंत्रण प्रणालियों के लिए विशिष्ट समाधान है , इसलिए निश्चित रूप से सीवीएस इस तरह के सहयोग का समर्थन नहीं करता है। यहां तक कि "गिट अनुरोध-पुल" नामक एक उपकरण भी है जो आपके भंडार से खींचने के अनुरोध के साथ अनुचर को भेजने के लिए ईमेल तैयार करने में मदद करता है। "गिट बंडल" के लिए धन्यवाद, आप इस तंत्र का उपयोग सार्वजनिक रिपॉजिटरी के बिना भी कर सकते हैं, ईमेल या स्नीकरनेट के माध्यम से परिवर्तनों का बंडल भेजकर। GitHub जैसी Git होस्टिंग साइटों में से कुछ को यह सूचित करने के लिए समर्थन है कि कोई आपकी परियोजना पर काम कर रहा है (कुछ काम प्रकाशित किया है) (बशर्ते कि वह / वह एक ही Git होस्टिंग साइट का उपयोग करता है), और PM-ing एक प्रकार का पुल अनुरोध।
मुख्य विकासकर्ता , अर्थात कोई व्यक्ति जो अपने परिवर्तनों को सीधे प्रकाशित करता है (मुख्य / विहित भंडार के लिए)। यह श्रेणी वितरित संस्करण नियंत्रण प्रणालियों के लिए व्यापक है, क्योंकि केंद्रीय रिपॉजिटरी में लिखने के एक्सेस के साथ कई डेवलपर्स केवल संभावित वर्कफ़्लो नहीं हैं (आप एकल अनुचर हो सकते हैं जो कैनोनिकल रिपॉजिटरी में परिवर्तन को धक्का देते हैं, लेफ्टिनेंट / उप-निर्धारक का एक सेट जिसमें से वह / वह पत्तों के डेवलपर्स की व्यापक रेंज, जो मेल के माध्यम से या तो अनुचर / परियोजना मेलिंग सूची, या लेफ्टिनेंट / सबमेनटेनर्स में से एक को मेल के माध्यम से पैच भेजते हैं।
Git के साथ आपके पास बदलावों को प्रकाशित करने के लिए SSH प्रोटोकॉल (git प्रोटोकॉल में लिपटे) का उपयोग करने का विकल्प है , जैसे "git shell" (सुरक्षा में मदद करने के लिए, शेल खातों की पहुंच को सीमित करना) या Gitosis (अलग शेल खातों की आवश्यकता के बिना एक्सेस का प्रबंधन करना) ), और साधारण HTTP प्रमाणीकरण के साथ WebDAV के साथ HTTPS ।
सीवीएस के साथ कस्टम अनएन्क्रिप्टेड (सादा पाठ) प्रेक्षक प्रोटोकॉल, या दूरस्थ शेल (जहां आपको वास्तव में एसएसएच का उपयोग करना चाहिए ) का उपयोग करके अपने परिवर्तनों को प्रकाशित करने के लिए एक विकल्प है, जो कि केंद्रीकृत संस्करण नियंत्रण प्रणाली के लिए आपके परिवर्तनों (कमिट बनाने) का अर्थ है। ठीक है, आप SSH का उपयोग करके 'pserver' प्रोटोकॉल को भी टनल कर सकते हैं, और इसमें थायर पार्टी टूल्स को स्वचालित किया जा सकता है ... लेकिन मुझे नहीं लगता कि यह Gitosis जितना आसान है।
सामान्य वितरित संस्करण नियंत्रण प्रणाली में, जैसे कि Git, संभावित वर्कफ़्लोज़ का अधिक व्यापक चयन प्रदान करता है। केंद्रीयकृत संस्करण नियंत्रण प्रणाली जैसे सीवीएस के साथ, आवश्यकता के अनुसार, आपको रिपॉजिटरी के लिए प्रतिबद्ध पहुंच वाले लोगों के बीच अंतर करना होगा, और उन लोगों के बिना ... और सीवीएस बिना लोगों के योगदान (पैच के माध्यम से) स्वीकार करने में मदद करने के लिए कोई भी उपकरण प्रदान नहीं करता है। पहुँच।
संस्करण नियंत्रण के बारे में अनुभाग में ओपन सोर्स सॉफ्टवेयर का निर्माण करने में कार्ल फोगल बताता है कि उन क्षेत्रों पर बहुत सख्त, कठोर और कठोर नियंत्रण प्रदान नहीं करना बेहतर है, जहां किसी को सार्वजनिक रिपॉजिटरी में बदलाव करने की अनुमति है; तकनीकी प्रतिबंधों की तुलना में सामाजिक प्रतिबंधों (जैसे कोड समीक्षा) पर भरोसा करना बेहतर है (इसके लिए); वितरित संस्करण नियंत्रण प्रणालियाँ उस IMHO को और भी कम कर देती हैं ...
HTH (आशा है कि मदद करता है)