version control - मेरी टीम को स्रोत नियंत्रण क्यों अपनाना चाहिए?




version-control project-management (17)

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

इसलिए, आप लोग मुझे बता सकते हैं कि डेवलपर को स्रोत नियंत्रण का उपयोग क्यों करना चाहिए? इसके अतिरिक्त, आप Visual SourceSafe को छोड़कर किसी भी उपकरण का चयन क्यों करेंगे? मेरे पास वीएसएस का उपयोग करने का अनुभव नहीं है, लेकिन वह यह पूछने की संभावना है कि हम केवल माइक्रोसॉफ्ट के उपकरण का उपयोग क्यों नहीं करेंगे।

मैं यहां कई स्मार्ट प्रोग्रामर से राय सुनना चाहता हूं! मेरा पसंदीदा विकल्प एसवीएन या मर्कूरियल हैं दोनों अपने विंडोज संस्करणों के लिए अच्छा समर्थन करते हैं, और दोनों सीवीएस की तुलना में कम पुरातन हैं। इसके अलावा, एक स्व-घोषित ओपन सोर्स शिष्य के रूप में, मैं एक ओपन सोर्स टूल का सुझाव देना पसंद करता हूं। :)

धन्यवाद!

संपादित करें : इसे कम करने के लिए, आम तौर पर, अन्य डेवलपर्स के लिए वर्तमान अभ्यास फ़ोल्डर को नकल करना है, तिथि के साथ टैग और अपने दम पर रिकॉर्ड भी। आपको चित्र मिल जाएगा। अगर मेरा बॉस कहता है, "अगर यह काम करता है, तो उसे ठीक क्यों करें?"


आपकी टीम को स्रोत नियंत्रण क्यों नहीं अपनाना चाहिए?

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


इन कारणों से आपको स्रोत नियंत्रण का उपयोग करना होगा

1) आप किसी भी संस्करण के लिए रोलबैक कर सकते हैं

2) विभिन्न डेवलपर्स एक ही फाइल पर काम कर सकते हैं

3) सभी डेवलपर्स के पास एक ही कोड बेस तक पहुंच होगी

4) आप परिवर्तनों को ट्रैक कर सकते हैं

5) आप उन परिवर्तनों को वापस रोल कर सकते हैं जो काम नहीं करते हैं

6) स्रोत नियंत्रण निरंतर एकीकरण का आधार है और टीडीडी के साथ बड़े पैमाने पर मदद करता है

7) यदि आप स्रोत नियंत्रण का उपयोग नहीं करते हैं, तो आप धीरे-धीरे पागल हो जाएंगे क्योंकि फ़ाइलों को खोया / ओवरराइट किया जाता है और कुछ भी काम नहीं करता जितना चाहिए

वीएसएस सबसे खराब एससीसी आवेदन नहीं है, मैं इसे कई सालों से इस्तेमाल करता हूं और इसे नफरत करता हूं, लेकिन यह काम करता है, सरल है और बहुत से लोग इसे जानते हैं।


एक औपचारिक प्रस्तुति क्यों करते हैं?

टीम के आकार को मानते हुए कम से कम दो, एक वास्तविक दुनिया उदाहरण: दो (या अधिक, अधिक बेहतर) लोगों को कोड मिलता है, उनके परिवर्तन करते हैं और दिखाते हैं कि उन सभी परिवर्तनों को एकीकृत करने के लिए जो कुछ भी गैर स्रोत नियंत्रण का उपयोग करते हैं मतलब है कि आप का उपयोग करें

फिर स्रोत नियंत्रण का उपयोग करके एक ही परिदृश्य करें।

स्रोत नियंत्रण का उपयोग करके आप जो समय और दर्द की बचत करते हैं, वह स्वयं के लिए बात करेंगे


ऐसा लगता है कि ज्यादातर लोगों ने स्रोत नियंत्रण की प्रमुख विशेषता को कवर किया है लेकिन सबसे बड़ी सकारात्मकता में से एक को छोड़ दिया गया है। य़े हैं:

शाखाओं

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

बग ठीक करें

कभी-कभी आपको बग को हल करने की आवश्यकता होती है और इसे आपके कोड के मेनलाइन या ट्रंक संस्करण के रूप में दूर करते हैं। यह टेस्टिंग पर्यावरण या किसी भी कारण की समस्या में हल करने के लिए हो सकता है। यदि आपके पास एक संस्करण नियंत्रण उपकरण है तो आप बग को ठीक करने के लिए आसानी से एक नई शाखा (कुछ VSS बेकार है) बनाने में सक्षम होना चाहिए और यदि आवश्यक हो तो इसे मुख्य लाइन कोड में वापस मर्ज कर पाएं।

रखरखाव रिलीज

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

नयी विशेषता

कभी-कभी आपको अपने वर्तमान कोड को बनाए रखने के दौरान एक नए संस्करण का विकास करना होगा। उदाहरण के लिए आप v1.0 जारी करते हैं और बनाए रखते हैं लेकिन v1.0 को बनाए रखने के लिए v2.0 पर काम शुरू करने की आवश्यकता है। शाखाएं इस स्थिति को हल करने में सहायता करती हैं

टैगिंग / लेबलिंग

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


नीचे पंक्ति में चिपकाएं, यह बताएं कि यह पैसे से कैसे संबंधित है और आपका बॉस शायद सुनेंगे।

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

यदि आप एक से अधिक प्रोग्रामर हैं तो उपरोक्त दो बार चला जाता है, यह एकमात्र समझदार तरीका है एक ही कोडबेस पर एक साथ काम करने में सक्षम होने के लिए और भी अधिक समय बर्बाद किए बिना,

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


बस - तो आपके पास कोड का सच्चा इतिहास है - परिवर्तनों की जांच (बग के कारण), संस्करणों में वापस लौटने, ऑडिट आदि। बैकअप पर्याप्त नहीं है - आपके पास वर्तमान तस्वीर की एक प्रति है कभी भी एक फ़ाइल बदल और इच्छा है कि आप क्या याद रख सकते हैं?


मैं एसवीएन का उपयोग करने का सुझाव देता हूं, क्योंकि:

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

मैं वीएसएस का उपयोग नहीं करने का सुझाव देता हूं - कारणों के लिए इस पृष्ठ को देखें: http://www.highprogrammer.com/alan/windev/sourcesafe.html अधिक कारणों से।


मैं वाकई माफी चाहता हूं, लेकिन यदि आप विकास के वातावरण में [नियंत्रण] के स्रोत नियंत्रण के लिए बहस करना चाहते हैं, तो आप एक निराशाजनक स्थिति में हैं। यदि आपके बॉस को वास्तव में आश्वस्त होना चाहिए कि स्रोत नियंत्रण एक बेहतरीन प्रयास है, तो आपके बॉस सॉफ्टवेयर डेवलपर्स के एक समूह के प्रबंधक होने के लिए उपयुक्त नहीं हैं। किसी को प्रभावी ढंग से प्रबंधित करने के लिए, वास्तव में परिदृश्य की मूलभूत समझ को बहुत कम से कम पर रखना आवश्यक है। मैं यह भी नहीं सोच सकता कि क्या होने जा रहा है जब आपको वास्तव में किसी चीज के लिए बहस करने की आवश्यकता होती है जो तर्क के लायक है और एक प्रस्तुति को खत्म करना है।

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

काम पर, हम तोड़फोड़ का इस्तेमाल करते हैं, लेकिन कुछ डेवलपर (मेरे शामिल हैं) स्थानीय स्तर पर जीआईटी-एसवीएन पुल के माध्यम से जीआईटी का इस्तेमाल करते हैं निजी काम के लिए, मैं गिट का उपयोग करता हूं


यहां एक सरल वास्तविक जीवन उदाहरण है

कुछ साल पहले, मेरे मालिक कहते हैं, "फ़ीचर एक्सवाईजेड काम करने के लिए प्रयोग किया जाता है, और अब यह नहीं है। कोई नहीं जानता कि क्या हुआ। क्या आप इसे ठीक कर सकते हैं?"

अब मैंने पहले एक्सआईजेड की सुविधा के साथ काम नहीं किया है इसलिए फिक्सिंग में यह पता लगाने की कोशिश कर रहा है कि यह क्या करता है।

लेकिन हमारे पास स्रोत नियंत्रण है! इसलिए मैं यह करता हूं:

  • XYZ सुविधा का परीक्षण करने के लिए एक परीक्षण स्क्रिप्ट बनाएं: "यहां क्लिक करें, इसे टाइप करें, वहां क्लिक करें, आदि।"
  • वर्तमान संस्करण प्राप्त करें बनाएँ। परीक्षा। सुविधा XYZ टूटा हुआ है
  • एक हफ्ते पहले संस्करण प्राप्त करें बनाएँ। परीक्षा। सुविधा XYZ काम करता है
  • उन दोनों के बीच आधे रास्ते संस्करण प्राप्त करें बनाएँ। परीक्षा। सुविधा XYZ काम करता है
  • पिछला एक और मौजूदा एक के बीच आधे रास्ते संस्करण प्राप्त करें बनाएँ। परीक्षा। सुविधा XYZ टूटा हुआ है

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

इसलिए मैंने साइड इफेक्ट निकाल दिया, परीक्षण किया ... और लो और देखिए, सुविधा XYZ फिर से काम करती है।

स्रोत नियंत्रण के बिना , आप ऐसा कभी नहीं कर सकते आपको एक चीज या किसी अन्य को बदलने के लिए चारों ओर घूमना पड़ेगा, जो उस चीज़ पर जादुई ढंग से हिट करने की उम्मीद करता है जो एक्सवाईजेड को फिर से काम करता है।

स्रोत नियंत्रण के साथ , आप बस संस्करणों के माध्यम से अपना रास्ता जांचते हैं, उस सटीक कोड को इंगित करते हैं जिससे समस्या का कारण बनता है, और इसे ठीक कर सकता है।


सरल: यदि कोड स्रोत में सुरक्षित नहीं है, तो यह मौजूद नहीं है

सबवर्सन वीएसएस से नि: शुल्क और बेहतर है, लेकिन वीएसएस निश्चित रूप से बेहतर है और कुछ नहीं।


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

इसके अतिरिक्त, एक अच्छा स्रोत नियंत्रण प्रणाली जैसे एसवीएन कई डेवलपर्स को एक ही फाइल पर काम करने के लिए अनुमति देगा और ये प्रत्येक अंतर पेश करने के लिए शक्तिशाली उपकरण प्रदान करेंगे।


इसलिए, आप लोग मुझे बता सकते हैं कि डेवलपर को स्रोत नियंत्रण का उपयोग क्यों करना चाहिए?

  • यह एक पूरी टीम के उपयोग के लिए एक विधि प्रदान करता है; हर कोई एक ही 'जमीन के नियमों' के तहत चल रहा है
  • बदलाव क्रमबद्ध बनाम अराजक हैं, विकास के समय की बचत।
  • परिवर्तनों को ट्रैक करने की क्षमता जवाबदेही को बढ़ावा देती है और सामग्री को बनाए रखने में समस्याओं को हल करने के लिए सही प्रयास को आसान बनाते हैं।
  • किए गए सटीक परिवर्तनों की एक सूची जल्दी से और आसानी से उत्पन्न हो सकती है, जिससे जानकारी के उपयोगकर्ताओं को सलाह देने में आसान हो जाता है कि यह संस्करण से संस्करण में कैसे बदल गया है।
  • जानकारी के पहले के संस्करण में 'वापस रोल' करना आसान है, अगर किसी गलती के दौरान एक गंभीर गलती की गई थी

स्रोत नियंत्रण बीमा की तरह है! आप आशा करते हैं कि आपको कभी इसकी ज़रूरत नहीं है, लेकिन आप खुश हैं जब आप करते हैं!


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

जाहिर है, कई अन्य फायदे हैं (यानी 2 लोग उसी समय एक ही फाइल पर काम कर रहे हैं), लेकिन कई साल पहले मेरी कंपनी को जल्दी से बेची गई बैकअप है।


कुछ संस्करण नियंत्रण प्रणाली किसी भी, कई मामलों में मदद करता है:

सिंगल डेवलपर, एकल शाखा

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

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

    साथ ही कुछ अंतिम संस्करण में वापस जाने के लिए आसान और स्वचालित है आप यह भी देख सकते हैं कि कैसे एक फ़ाइल किसी पिछले संस्करण की तरह दिखती है, और आप मौजूदा राज्य और कुछ पिछले संस्करण के बीच अंतर (अंतर प्रारूप में) प्राप्त कर सकते हैं। आप टैग (या 'लेबल') संस्करणों को भी टैग कर सकते हैं, ताकि आप पिछले संस्करण को न केवल दिनांक तक, या मौजूदा एक से n वें संस्करण के द्वारा, बल्कि प्रतीकात्मक नाम से भी, उदाहरण v1.2 या v1.2-rc0

  • संस्करण नियंत्रण प्रणाली के साथ आप इतिहास की जांच कर सकते हैं कि आपको याद दिलाना है कि वर्तमान स्थिति में (और दिए गए फ़ाइल का कुछ भाग) कोड का कुछ हिस्सा क्यों पहुंचा? अधिकांश वीसीएस एक फ़ाइल के लाइन-वार इतिहास की जांच करने की अनुमति देता है, अर्थात् एक फ़ाइल के प्रत्येक पंक्ति की व्याख्या करते समय, क्या किया गया था, और किसके द्वारा (कमांड का नाम annotate , blame या praise VCS पर निर्भर करता है)। कुछ वीसीएस में आप एक संस्करण (संशोधन) के लिए इतिहास खोज सकते हैं, जिसने कोड के टुकड़े को प्रस्तुत किया (जैसे गिट में 'पिकैक्स खोज' नामक एक, वीसीएस में से एक)।

    वास्तव में उपयोगी होने के लिए आपको कुछ अनुशासन बनाए रखना होगा: आपको प्रत्येक नए संस्करण का वर्णन करना चाहिए (प्रत्येक नए संशोधन / प्रत्येक नई प्रतिबद्धता) लिखना चाहिए कि परिवर्तन क्यों किया गया था इस तरह के वर्णन (प्रतिबद्ध संदेश) बहुत उपयोगी है, लेकिन इसके बैकअप सिस्टम में प्राकृतिक स्थान नहीं है।

    यदि आप एकमात्र डेवलपर नहीं हैं, तो यह सुविधा ज़्यादा उपयोगी है ...

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

    वास्तव में उपयोगी होने के लिए आपको कुछ अनुशासन बनाए रखना होगा: आपको पिछले संस्करण से केवल छोटे अंतर के साथ ही एक फीचर के साथ काम करना चाहिए (एक बदलाव को बदलें / याद रखने के लिए संस्करण नियंत्रण प्रणाली में दिए गए राज्य को बदलें); अर्थात् अक्सर कम करना

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

एकल डेवलपर, एकाधिक शाखाएं

  • संस्करण नियंत्रण प्रणाली कई वैकल्पिक विकास की समानांतर रेखाएं बनाने की अनुमति देती हैं, जिन्हें शाखाओं (या धाराओं, या विचार) कहते हैं सामान्य मामला विकास शाखाएं हो रहा है , अर्थात् अस्थिर विकास के लिए अलग शाखा (नई सुविधाओं का परीक्षण करने के लिए), स्थिर (मुख्य, ट्रंक) संस्करण के लिए अलग शाखा, जो वर्तमान कार्यरत संस्करण (या होना चाहिए) और एक अलग रखरखाव (फिक्सअप ) शाखाओं

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

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

  • यदि आप अपने उत्पाद को किसी अन्य (आमतौर पर तीसरे पक्ष) उत्पाद के स्रोत के आधार पर विकसित कर रहे हैं, तो आपको वास्तव में विक्रेता की शाखाओं का उपयोग करना चाहिए ताकि आप अपने द्वारा किए गए परिवर्तनों के साथ विक्रेता के किसी उत्पाद के नए संस्करण को एकीकृत कर सकें। बेशक यह अब विशुद्ध रूप से "एकल डेवलपर" मामले नहीं है।

एकाधिक डेवलपर्स

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

  • उपर्युक्त सभी विशेषताएं बहु-डेवलपर मामले में और भी महत्वपूर्ण हैं: जो कि परिवर्तन को उत्पन्न करने वाले व्यक्ति की जांच कर रहे हैं, जिन्होंने आखिरकार कोड (उर्फ, जिसने निर्माण को तोड़ दिया) को बदल दिया, कोड में एक बग को केवल आपके द्वारा नहीं लिखे गए


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

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

'माइक्रोसॉफ्ट टूल्स' प्रश्न के उत्तर के रूप में टीएफएस को ध्यान में रखें।


इसलिये:

  1. इससे लागत कम हो जाएगी - डेवलपर्स को अपने मौजूदा विज्ञापन-हॉक दृष्टिकोण की तुलना में एक असली वीसीएस में से / बाहर के आइटम को कम समय बिताना होगा।

  2. यह संगठन की बौद्धिक संपदा की रक्षा करेगा - यह किसी भी सॉफ्टवेयर कंपनी के लिए सबसे महत्वपूर्ण विचार होना चाहिए (डेटा के अलावा ...) आपको सॉफ्टवेयर बनाने के लिए भुगतान किया जाता है - क्या यह पूरी तरह से सुलभ नहीं होना चाहिए?

  3. यह तेज, अधिक विश्वसनीय और सीधा बैकअप तंत्र प्रदान करेगा - सभी VCSs ने डंपिंग क्षमताओं में बनाया है। ये एक सरल फ़ाइल कॉपी से अधिक परिपक्व होते हैं

  4. यह डेवलपर्स के बीच एक संचार तंत्र के रूप में कार्य करेगा - संस्करण नियंत्रण प्रणाली के आधार पर आप टिप्पणियों / लेबल / चेकआउट स्थिति का उपयोग कर सकते हैं, यह निर्धारित करने के लिए कि कोई अन्य किसी फ़ाइल पर काम कर रहा है, अगर उसे उत्पादन में पदोन्नत किया गया है, अगर उसके पास एक संगत समर्थन है टिकट संख्या आदि

  5. यह विकास को सरल बनाता है - फाइलों के साथ-साथ अन्य तंत्र के संस्करणों की तुलना करने की क्षमता आपकी कंपनी की अवधि के लिए फायदेमंद होगी।


स्रोत नियंत्रण के लाभों पर माइक्रोसॉफ्ट (एमएसडीएन) का एक अच्छा लेख है
http://msdn.microsoft.com/en-us/library/ms173539.aspx

यहां पर बहुत सारे अच्छे सवाल हैं, इसलिए पेशेवरों और विपक्षों के लिए
आपके इस्तेमाल के बाद git के अपने पेशेवरों और विपक्ष क्या हैं?

सबवर्सन बहुत लोकप्रिय है, लेकिन गिट स्रोत नियंत्रण दुनिया में "अगली बड़ी बात" होने जा रही है





visual-sourcesafe