प्रोग्रामिंग छात्रों के लिए कौन सा DVCS (git या hg) आसान है? [बन्द है]


25

संदर्भ का एक सा: मैं कॉलेज के तीसरे वर्ष में हूँ। छात्रों को 4. टीमों में विभाजित किया गया है। लगभग सभी लोग खिड़कियों के नीचे काम कर रहे होंगे (मेरे जैसे कुछ लोग जो लिनक्स पर हैं) को छोड़कर। स्कूल के पाठ्यक्रम के हिस्से के रूप में, हम जल्द ही एक वास्तविक ग्राहक के लिए एक परियोजना पर काम करना शुरू कर देंगे, लेकिन मैं और एक अन्य टीम सोच रहे हैं कि हमारे कोड को एक दूसरे के साथ साझा करने के लिए कौन सा तरीका सबसे अच्छा होगा।

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

मेरे विचार: मैंने सुना है कि Mercurial + TortoiseHg का विंडोज़ के तहत बेहतर एकीकरण है, लेकिन मैं सोच रहा हूं कि क्या अनाम प्रमुखों की अवधारणा उन्हें भ्रमित कर सकती है, भले ही मैं उन्हें समझाऊं। दूसरी ओर, मुझे लगता है कि शुरुआत के लिए git शाखाओं को समझना आसान है (प्रत्येक प्रोग्रामर के लिए काम का स्पष्ट विभाजन), लेकिन खिड़कियों के नीचे भी काम नहीं करता है।


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

1
समानांतर में काम करने वाले कई योगदानकर्ताओं से विलय के योगदान को प्रबंधित करने के लिए भिखारी से DVCS का उपयोग सबसे सरल तरीका होने की संभावना है। यदि आप गुमनाम सिर को भ्रमित करते हैं, तो उनका उपयोग न करें (शाखाओं के नाम पर व्यापारिक समर्थन)।
स्टीफन सी। स्टील

2
समय फिर से इस ब्लॉग पोस्ट से लिंक करने के लिए? Git एक हैरियर कूद जेट है
sbi

1
मैं कभी नहीं समझ पाया कि पूरे "सीखने के लिए बहुत कठिन" क्यों मायने रखता है। ठीक है, इसलिए यह जानने में 20 मिनट लगते हैं कि कैसे प्रतिबद्ध और शाखा और जैसे कि 10 का विरोध ... बड़ा सौदा?
वैकल्पिक

1
देखो (उनमें से एक) hginit.com के माध्यम से जाते हैं और उनकी प्रतिक्रियाओं के आधार पर कार्रवाई करते हैं।
chelmertz

जवाबों:


49

बिना किसी शक के मर्क्यूरियल।

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

हाथ में अंक:

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

  2. अगर कोई "आपके बाद Git अधिक शक्तिशाली है ..." चर्चा शुरू करता है, तो वह बहुत ज्यादा यह सब कह रहा है। 95% उपयोगकर्ताओं के लिए मर्क्यूरियल अधिक सहज लगता है। सूचकांक की कमी से शुरू होकर, इसके अधिक सहज विकल्पों (विकल्प स्विच सुसंगत हैं) के लिए, SHA1 हैश के बजाय इसके स्थानीय संख्या के लिए (जो कभी सोचा था कि SHA1 हैश उपयोगकर्ता के अनुकूल हैं!)

  3. मर्क्यूरियल की शाखाएं गिट्स से कम शक्तिशाली नहीं हैं। कुछ अंतरों का वर्णन करते हुए पोस्ट करें। कुछ पिछले संशोधन में वापस जाना "अपडेट-पुराने-संशोधन" जितना ही सरल है। वहां से शुरू; बस एक नई प्रतिबद्धता है। यदि कोई इनका उपयोग करना चाहे तो नामित शाखाएँ भी उपलब्ध हैं।

अब, मुझे पता है कि ये सभी विवरण हैं, और उन्हें सीखा जा सकता है और सब कुछ, लेकिन बात यह है ... ये चीजें जोड़ते हैं। और अंत में, एक दूसरे की तुलना में सरल और अधिक सहज लगता है। और संस्करण नियंत्रण प्रणाली को सीखने के लिए कुछ खर्च नहीं करना चाहिए - आप प्रोग्रामिंग सीखने और फिर प्रोग्राम करने के लिए वहां हैं; VCS एक उपकरण है।

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


4
"वीसीएस एक उपकरण है" के लिए। मैंने "छोटी चीजों" को एक कारक के रूप में नहीं माना था, लेकिन यह सच है कि जब आप छोटी समस्याओं को यहां जोड़ते हैं और वे एक वास्तविक उपद्रव बन सकते हैं।
ग्रेगरी एरिक सैंडरसन

8
"संस्करण नियंत्रण प्रणाली कुछ ऐसी नहीं होनी चाहिए जो सीखने में समय बिताए।" यह बकवास का भार है। आपको हमेशा अपने उपकरण सीखने में समय बिताना चाहिए। आप अपना कंपाइलर सीखने में समय बिताते हैं; लेकिन VCS आपके प्रोग्रामिंग के लिए उतना ही महत्वपूर्ण है जितना कि आपका कंपाइलर।
जेस्पर

9
+1। विशेष रूप से 'विंडोज़ पर द्वितीय श्रेणी के नागरिक' तर्क इस स्थिति में बिल्कुल महत्वपूर्ण है।
tdammers

+1 के लिए "डब्ल्यूटीएफ (एस) / मिनट" ( ऑसन्यूज़ / स्टॉरी / 19266 / WTFs_m )। ये बच्चे निपुणता सीखेंगे :-)
रॉस पैटरसन

1
@ मर्क यह सिर्फ एक शब्दावली अंतर का परिणाम है ... Git में एक शाखा वास्तव में सिर्फ एक नाम है।
वैकल्पिक

10

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

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


खुद को "कंसोल जंकी" होने के नाते मैंने कछुआ {Svn, Git, Hg} ऐप्स का इस्तेमाल कभी नहीं किया है, इससे पहले कि मुझे नहीं पता था कि कछुआ का ब्रांच ग्राफ था। मुझे लगता है कि बाहर की जाँच के लिए जाना होगा
ग्रेगरी एरिक सैंडरसन

4

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

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

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


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

+1; जीवाश्म थोड़ा ज्ञात है, लेकिन यह काम करने में इतना आसान है और इतना आत्म-निहित है (डीवीएससी + विकी + टिकट + वेबसर्वर) कि यह पूरे टीआरसी या यहां तक कि जीथब के लिए एक वास्तविक विकल्प है।
जेवियर

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

Mercurial ने hg सर्व कार्यक्षमता में भी निर्मित किया है। यह एक बग ट्रैकर और विकी को याद करता है। लेकिन उसके बाद भी bitbucket.com
जोहान्स रुडोल्फ

3

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

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

मेरी राय में, नए उपयोगकर्ताओं को सीखना आसान है। यह सरल चीजों को आसान बनाता है, और खतरनाक लोगों को कठिन बनाता है। Git खतरनाक संचालन को आसान बनाता है (करने में आसान, जरूरी नहीं कि सही तरीके से करना आसान हो!)।

Winodows के लिए TortoiseHg इंटरफ़ेस बहुत अच्छा है, और व्यापारिक उपयोग करने के पक्ष में एक और तर्क है।


2

मेरी व्यक्तिगत प्राथमिकता गिट के लिए है।

हालाँकि, जैसा कि कुछ लोग विंडोज़ का उपयोग कर रहे हैं और शानदार hginit ट्यूटोरियल मौजूद है, मैं उन्हें मर्क्यूरियल सिखाने की सलाह दूंगा।


Hginit का उल्लेख करने के लिए +1। हालांकि, प्रो गिट बहुत अच्छा है।
तमसे सजेलेई

@ TamásSzelei, धन्यवाद, मैंने पहले प्रो Git नहीं देखा था।
dan_waterworth

0

जैसा कि कई लोगों ने सुझाव दिया है, कछुए के माध्यम से मर्क्यूरियल में प्रवेश के लिए बहुत कम बाधा है।

विंडोज पर उन लोगों के लिए यह एक एकल संस्थापक के बजाय दो संस्थापक (और सामान की एक पूरी लोड वे के बारे में जानने के लिए नहीं चाहते हो सकता है) है और THG यूजर इंटरफेस ज्यादा से ज्यादा पॉलिश TortoiseGit + Msysgit

अनाम सिर

अगर आपको लगता है कि वे गुमनाम सिर से भ्रमित होंगे, तो उनके उपयोग को प्रोत्साहित न करें। अधिकांश hgपुस्तकें एक संतुलित दृष्टिकोण लेती हैं और दोनों सामयिक और नामित शाखाओं को पढ़ाती हैं, और पाठक को यह निर्धारित करने देती हैं कि उनके उपयोग के लिए सबसे उपयुक्त है।

नामित शाखाएँ

एक बात मैं वास्तव में में याद आती है gitहै hgके नाम पर रखा गया शाखाओं ताकि एक विकल्प नहीं है,। gitजब आप उन पर काम कर रहे होते हैं तो शाखाएं ठीक होती हैं, लेकिन एक बार जब आप उस कार्य को दूसरी शाखा में विलय कर देते हैं, तो आप उन परिवर्तनों के संदर्भ में बहुत कुछ खो देते हैं।

में hgआप एक शाखा कहा जाता है बना सकते हैं Jira#1234और हमेशा उस के साथ जुड़े संशोधन के सभी प्राप्त कर सकेंगे ठीक । में git, एक बार अपने शाखा में विलय कर दिया है और रेफरी को नष्ट कर दिया है, तो आप अनुमान लगाने के लिए जो संशोधन संशोधन के पेड़ के टोपोलॉजी से ठीक का हिस्सा थे की है। यहां तक ​​कि अगर आप रेफरी को नहीं हटाते हैं, तब भी आप केवल उस शाखा पर अंतिम कमिटमेंट जानते हैं, न कि यह कि कौन से पूर्वज कमिट की उस श्रृंखला का हिस्सा थे।

बुकमार्क

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

यह दोनों दुनिया के लिए सबसे अच्छा हो सकता है - उन्हें gitवर्कफ़्लो सीखने को मिलता है , लेकिन सरल hgकमांड का उपयोग करने के लिए मिलता है ।

सूचकांक / कैश / स्टेजिंग क्षेत्र

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

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

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


आपके द्वारा किए जाने के बाद आपको git शाखा को हटाना नहीं है; यह केवल प्रथा है। इसके अलावा -1 इंडेक्स के गलत इस्तेमाल के लिए - आप इसका इस्तेमाल बुरे कामों के मंचन के लिए नहीं करते हैं, आप इसे कमिट्स की एक बड़ी श्रृंखला के आंशिक चरणों का उपयोग करने के लिए करते हैं। आमतौर पर ऐसा रिबेस के दौरान होता है जब आप अपना इतिहास साफ़ कर रहे होते हैं।
वैकल्पिक

@mathepic - यदि आप शाखा के नाम नहीं हटाते हैं, और अपनी सभी स्थानीय 'फिक्स' शाखाओं को रिमोट तक पुश करते हैं, तो आप बड़ी संख्या में रेफ के साथ समाप्त होने जा रहे हैं, जैसे आप पुरानी शाखाओं के ढेर के साथ समाप्त होते हैं svn में। में hgइन शाखा के नाम हमेशा सांस्थितिकी स्थानीय कर रहे हैं, ताकि आप केवल उन्हें देख अगर तुम उन्हें देखने के लिए।
मार्क बूथ

@mathepic - आपके -1 के अनुसार, मुझे लगता है कि आप जो मैं कह रहा हूं उसका गलत मतलब निकाल रहे हैं। मैं कल्पना नहीं कर सकता कि कोई जानबूझकर बुरा क्यों करेगा, लेकिन गिट के साथ इसे दुर्घटना से करना आसान है। यदि आप भूल जाते हैं कि फ़ाइल फ़ाइल में cएक संशोधित इंटरफ़ेस लागू करती है iऔर गलती से भी इसके iबिना प्रतिबद्ध है, cतो इससे पहले कि आप cअपने संकलन करने के लिए चारों ओर पहुँच गए हैं, अगर कोई आपके परिवर्तनों को खींचता है । यदि आप इसके बजाय stash / compile / प्रतिबद्ध वर्कफ़्लो का उपयोग करते हैं, तो यह गलती बस होने वाली नहीं है क्योंकि आपका स्वयं का बिल्ड पहले टूट जाएगा। मैंने अपना उत्तर स्पष्ट करने का प्रयास किया है।
मार्क बूथ
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.