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

Question

मैं एक ब्लॉग पढ़ रहा था जहाँ लेखक ने यह कहा

"कोड तब तक मौजूद नहीं है जब तक कि इसे संस्करण नियंत्रण प्रणाली में जांच नहीं किया जाता है। आप जो कुछ भी करते हैं उसके लिए संस्करण नियंत्रण का उपयोग करें। कोई भी संस्करण नियंत्रण, SVN, Git, यहां तक ​​कि CVS, इसे मास्टर करें और इसका उपयोग करें।"

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

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

क्या यह इसका मूल विचार है या क्या मैं इसे पूरी तरह से गलत मान रहा हूं?

अगर मैं सही हूं, तो हो सकता है कि अगर मैं:

• कोड पर काम करने वाले अन्य लोग न हों।
• दूसरों को कोड देने की योजना न बनाएं।

Comments

आपका मतलब है कि आप "कोडिंग हॉरर" पढ़ रहे थे ...

— जेसन

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

— स्पेंडर

हाथ जो मार्टिनो की शर्म साझा नहीं करता है। :)

— खर्च करें

कोई व्यक्ति @TimEckel को दिखावा करता है, जहां संस्करण नियंत्रण तीन महीने पहले आपको तीन लाइन परिवर्तन पर जादुई रूप से इंगित करता है और कहता है कि "बग को यहां पेश किया गया था।" मन = उड़ा।

— जोनाथन हार्टले

@TimEckel, आप अभी भी एक संस्करण नियंत्रण का उपयोग कर रहे हैं, कम सुविधाओं वाला एक अन्य प्रकार।

— अभिनव गौनियाल

Answer 1

क्या आपने कभी:

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

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

एक दोस्त को गलत तरीके से समझने के लिए: एक सभ्य उम्र के लिए एक सभ्य उपकरण।

Comments

इस आदमी ने इसे नंगा किया है। यहां तक ​​कि जब मैं अकेले प्रोजेक्ट्स पर काम करता हूं, तब भी मैं कुछ वर्जन को कंट्रोल करना पसंद करता हूं। 2 उपयोगकर्ताओं के लिए पेरफोर्स पूरी तरह से काम करने वाला डेमो इसके लिए बहुत अच्छा है।

— आलमो

उपयोगी लगता है .. जब तक मुझे इसे सीखना और मास्टर नहीं करना है। हेह

— पोटासिक

अच्छे अंक। हालाँकि, ध्यान दें कि संस्करण नियंत्रण बैकअप नहीं है! एक बैकअप को एक अलग सिस्टम / मीडिया पर संग्रहीत किया जाता है, और कुछ समय के लिए पुराने बैकअप रखता है (बस अगर आपकी रिपॉजिटरी किसी तरह खराब हो जाती है)।

— ५५

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

— si618

हाय टिम, आप अपने परिवर्तन इतिहास को कैसे ट्रैक करते हैं? आप अपने परिवर्तन इतिहास को किसी समस्या ट्रैकर या रिलीज़ नोट्स से कैसे जोड़ सकते हैं? आप अपने कोड की विभिन्न शाखाओं का विलय कैसे करते हैं? आप अपने पिछले 100 संस्करणों में किए गए परिवर्तनों को कैसे पा सकते हैं? हो सकता है कि अगर आप अकेले कोड करते हैं, या कभी भी इस बारे में चिंता न करें कि आपने कोड क्यों बदला है, तो हो सकता है कि सिर्फ एक बैकअप होना ही काफी है, लेकिन मैंने शर्त लगाई कि एक बार जब आप एक सभ्य वीसीएस का उपयोग करेंगे तो आप समझ जाएंगे कि इतने सारे लोग उनका उपयोग क्यों करते हैं।

— si618

Answer 2

यहां तक ​​कि अगर आप अकेले काम करते हैं तो आप स्रोत नियंत्रण से लाभ उठा सकते हैं। इन कारणों से अन्य लोगों में:

• आप कुछ भी नहीं खोते हैं। मैंने फिर कभी बाहर कोड टिप्पणी नहीं की। मैं बस इसे हटा देता हूं। यह मेरी स्क्रीन को अव्यवस्थित नहीं करता है, और यह खो नहीं है। मैं एक पुरानी प्रतिबद्धता की जांच करके इसे पुनर्प्राप्त कर सकता हूं।

• आप इच्छानुसार प्रयोग कर सकते हैं। यदि यह समस्या को हल नहीं करता है, तो इसे वापस लाएं।

• आप यह पता लगाने के लिए कोड के पिछले संस्करणों को देख सकते हैं कि कब और कहां बग पेश किए गए थे। git bisectउस संबंध में महान है।

• ब्रांचिंग और मर्जिंग जैसी अधिक "उन्नत" विशेषताएं आपके पास विकास की कई समानांतर रेखाएं हैं। आप हस्तक्षेप के बिना दो एक साथ सुविधाओं में काम कर सकते हैं और बहुत परेशानी के बिना आगे और पीछे स्विच कर सकते हैं।

• आप "क्या बदला" देख सकते हैं। यह मूल लग सकता है, लेकिन यह कुछ ऐसा है जो मुझे लगता है कि मैं बहुत जाँच कर रहा हूँ। मैं बहुत बार अपना एक-मैन वर्कफ़्लो शुरू करता हूं: मैंने कल क्या किया?

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

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

git init

क्लब में आपका स्वागत है।

Comments

यह अच्छा लगता है, इसलिए यह स्थानीय हो सकता है और किसी को देखने के लिए वेब पर नहीं होना चाहिए? मैं php डिज़ाइनर का उपयोग करता हूँ, मुझे यह बहुत पसंद है और इसका कछुआ SVN के लिए एकीकरण है, निश्चित नहीं है कि अगर यह एक अच्छा है

— JasonDavis

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

— 1800 सूचना

+1 कोड पर टिप्पणी न करने पर गोली के लिए +1

— एड स्कीबोर

अपने विशिष्ट सवालों के जवाब में @jasondavis (भले ही आप अब तक जानते हैं), आप किसी भी वितरित वीसीएस (गिट, मर्क्यूरियल, आदि) का उपयोग स्थानीय रूप से कर सकते हैं, बिना सर्वर के। आप स्थानीय रूप से एक केंद्रीकृत वीसीएस (सीवीएस, एसवीएन, आदि) का भी उपयोग कर सकते हैं , लेकिन इसे स्थापित करने के लिए बहुत अधिक कष्टप्रद होगा, और इससे अधिक लाभ नहीं मिलेगा। आपके द्वारा उपयोग किए जाने वाले वीसीएस के बावजूद, आप इसे एक सर्वर पर रख सकते हैं और अभी भी इसे सार्वजनिक नहीं कर सकते हैं (कंप्यूटर के बीच स्थानांतरित करने के लिए उपयोगी है, और दूसरा बैकअप प्रदान करना) - "निजी भंडार" की खोज करें। आप Gort के साथ TortoiseSVN का उपयोग नहीं कर सकते, लेकिन वहाँ एक Tortoise-Git है।

— naught101

Answer 3

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

आप शायद अभी संस्करण नियंत्रण का उपयोग करते हैं, भले ही आप इसे न जानते हों। क्या आपके पास "XXX Php कोड (दिसंबर)" या "XXX.php.bak.2" कहने वाला कोई फ़ोल्डर है? ये संस्करण नियंत्रण के रूप हैं । एक अच्छा संस्करण नियंत्रण प्रणाली स्वचालित रूप से आपके लिए इसका ख्याल रखेगा। आप किसी भी समय वापस रोल करने में सक्षम होंगे (जिसमें आपके पास चेक किया गया डेटा है) और उस डेटा की एक सटीक प्रतिलिपि देखने में सक्षम हो।

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

यहां तक ​​कि अगर आप अभी संस्करण नियंत्रण का उपयोग नहीं करते हैं, तो आप अपने कैरियर में बाद में एक समय में इसका उपयोग करने की संभावना रखेंगे और अब आप सिद्धांतों के साथ अधिक आरामदायक बनने से लाभ उठा सकते हैं।

Comments

... या "MyWork की कॉपी की प्रति की कॉपी"

— खर्चा करने

@spender: वास्तव में, यह वही है जो मुझे अंधेरे दिनों से याद है इससे पहले कि मैंने संस्करण नियंत्रण का उपयोग करना शुरू कर दिया :-)

— रॉबर्ट वेनबल्स

यह बहुत उपयोगी लगता है और मेरी वर्तमान परियोजना कुछ बड़ी है, कम से कम 150-200 फाइलें, यह कैसे काम करता है, मैं "संस्करण" डो को सुनता हूं जिसका अर्थ है संस्करण 1 और संस्करण 2, यदि संख्या वृद्धि, तो क्या होगा अगर मैं 1 को संशोधित करता हूं फ़ाइल और बाकी नहीं, क्या मेरे पास अनमॉडिफाइड कोड की 200 प्रतियां या संशोधित की गई फाइल की सिर्फ प्रतियां होंगी?

— जेसनडेविस

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

— खर्चा करने

मैंने अपने ऊपर की टिप्पणी को सही करने के लिए समय के माध्यम से यात्रा की है: संस्करण नियंत्रण केवल डेल्टा को संग्रहीत नहीं करता है , लेकिन यह डेल्टा के रूप में संस्करण का प्रतिनिधित्व करता है।

— हेनरेबोथा

Answer 4

अकेले काम करते हुए भी क्या कभी ऐसा हुआ है? आप अपना ऐप चलाते हैं, और कुछ काम नहीं करता है और आप कहते हैं कि "कल काम किया था, और मैं कसम खाता हूं कि मैंने उस कक्षा / पद्धति को नहीं छुआ।" यदि आप नियमित रूप से कोड में जांच कर रहे हैं, तो एक त्वरित संस्करण अंतर दिखाएगा कि पिछले दिन क्या बदल गया था।

Comments

या, मैं सिर्फ अपने बैकअप से नवीनतम संस्करण को खींचता हूं जो हर बार जब मैं एक फ़ाइल को सहेजता हूं तो बनाया जाता है।

— टिम एकल

@TimEckel और कुछ अन्य लोग अपने बदलावों को वापस

— लेते हैं

Answer 5

यहां एक ऐसा परिदृश्य है जो अकेले काम करने पर भी स्रोत नियंत्रण की उपयोगिता को स्पष्ट कर सकता है।

आपका ग्राहक आपको वेबसाइट पर एक महत्वाकांक्षी संशोधन लागू करने के लिए कहता है। यह आपको कुछ हफ़्ते तक ले जाएगा, और कई पृष्ठों में संपादन शामिल करेगा। तुम काम पर लग जाओ।

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

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

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

उपरोक्त परिदृश्य से पता चलता है कि स्रोत नियंत्रण एक महान उपकरण हो सकता है, भले ही आप एकल काम करते हों।

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

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

---

मूल लेखक: बिल कारविन

Answer 6

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

यह एक विशाल "पूर्ववत करें" बटन की तरह है जो आपके कोड की पहली पंक्ति में वापस आ जाएगा।

Answer 7

संस्करण नियंत्रण आपके द्वारा उपयोग करने के बाद शुरू किए बिना जीना लगभग असंभव है। यह अपरिहार्य है यदि एक से अधिक डेवलपर्स एक ही कोड बेस पर काम कर रहे हैं ... लेकिन यह एक डेवलपर के लिए भी काफी उपयोगी है।

यह आपके कोड में परिवर्तनों को ट्रैक करता है और आपको पिछले संस्करणों में वापस जाने की अनुमति देता है। यह आपको इस ज्ञान के साथ प्रयोग करने के लिए स्वतंत्र करता है कि यदि कुछ भी टूटता है तो आप अपने परिवर्तनों को पूर्ववत कर सकते हैं।

Comments

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

— टिम एकल

Answer 8

आप सुरक्षा प्राप्त करते हैं (अपने कोड के बैक-अप होने के अर्थ में) और अपने कोड के संस्करण (यह मानते हुए कि आप अपने परिवर्तनों को अक्सर करने की आदत डालते हैं)। दोनों बहुत अच्छी चीजें हैं भले ही कोई और आपके साथ कोड पर काम करना समाप्त न करे ...

Answer 9

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

मेरा व्यक्तिगत पसंदीदा git है।

Answer 10

संस्करण नियंत्रण का उपयोग करने के कई कारण हैं, भले ही आप एकमात्र व्यक्ति हैं जो कभी भी कोड को स्पर्श करेगा।

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

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

Answer 11

ऐसा कुछ जिसे किसी और ने स्पष्ट रूप से उल्लेख नहीं किया है, वह है टैगिंग या रिलीज़ का लेबल। यदि आपके पास अपने सॉफ़्टवेयर के संस्करण 1 का उपयोग करने वाला क्लाइंट है और आप संस्करण 2 पर काम करने में व्यस्त हैं, तो जब ग्राहक बग की सूचना देता है और आपको संस्करण 1.1 बनाने की आवश्यकता होती है?

एक स्रोत नियंत्रण प्रणाली आपको आपके द्वारा किए जाने वाले प्रत्येक रिलीज़ को लेबल करने देगी ताकि आप बाद में उस पर वापस जा सकें, इसे ठीक करें (और मर्ज करें कि नए संस्करण 2 कोड में ठीक करें) और बिना किसी चिंता के एक नई रिलीज़ करें कि आप गलती से कुछ वितरित कर सकते हैं तैयार नहीं है।

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

आमतौर पर नौकरी के लिए साक्षात्कार के दौरान पूछे जाने वाले पहले सवालों में से एक "स्रोत नियंत्रण के लिए आप क्या उपयोग करते हैं?" अब तक केवल एक जगह "कुछ भी नहीं" कहा गया है, लेकिन वे इसे ठीक करने की योजना बना रहे थे "अब जल्द ही ..."

Answer 12

तथ्य यह है कि अन्य डेवलपर्स भाग लेते हैं या नहीं पूरी तरह से एक संस्करण नियंत्रण प्रणाली की आवश्यकता के लिए रूढ़िवादी है।

आप एकमात्र डेवलपर हो सकते हैं लेकिन फिर भी इससे लाभ होगा:

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

अब, यदि आपके पास समान कोडबेस संस्करण नियंत्रण पर एक समूह विकसित हो रहा है, तब भी ऐसा करना आवश्यक है

• लोग एक ही फ़ाइल को एक ही समय में संपादित कर सकते हैं (विशेष प्रणाली के आधार पर, लेकिन अधिकांश समझदार आपको ऐसा करने की अनुमति देते हैं)
• आप बता सकते हैं कि कब किसने क्या किया

जब अधिक लोग शामिल होते हैं तो यह अधिक प्रासंगिक होता है कि आप विकास की शैली के आधार पर कौन सा संस्करण नियंत्रण उपकरण चुनते हैं।

Answer 13

यह पुरानी फ़ाइल का बैकअप लेने के बारे में भी है कि इसे "तोड़फोड़" क्यों कहा जाता है। तो आप अपने काम के कई संस्करण का प्रबंधन कर सकते हैं जिसमें आप वापस लौट सकते हैं (वापस लौट सकते हैं) और इसके विभिन्न कार्यान्वयन (ब्रांचिंग) का प्रबंधन कर सकते हैं।

Answer 14

आप पा सकते हैं कि आपके पास अपने कार्यक्रम का एक कार्यशील संस्करण था।

आप समय की अवधि में कुछ नई सुविधाएँ जोड़ने का निर्णय लेते हैं और आप इसे जारी करते हैं।

आपको कुछ कोड प्रभावित करने वाली बग रिपोर्ट्स मिलने लगती हैं जिन्हें आपने सोचा था कि आप स्पर्श नहीं करते हैं।

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

स्रोत नियंत्रण के कई उपयोग हैं, भले ही आप एकमात्र डेवलपर हों।

Answer 15

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

कुछ लाभ:

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

Answer 16

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

मैंने खुद को स्रोत नियंत्रण का उपयोग करने के बाद अधिक आक्रामक रीफैक्टरिंग पाया क्योंकि मुझे हमेशा पता था कि एक काम करने वाले संस्करण को आसानी से बहाल किया जा सकता है।

Answer 17

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

एक बार जब आप एक फाइल करने के लिए अपने कोड बचाने के लिए, आप तो कर सकते हैं प्रतिबद्ध अपनी परियोजना का संग्रह करने के लिए इस। जैसे ही आप अपना कोड विकसित करते हैं और अपने परिवर्तनों को करते हैं, रिपॉजिटरी संशोधन की एक श्रृंखला विकसित करती है । आप इनमें से किसी को भी देख सकते हैं संशोधन की । यदि आप अकेले काम करते हैं तो यह संभावना नहीं है कि आप अपनी कोड फ़ाइलों को खोने या एक अलग मशीन पर काम करना चाहते हैं। इन मामलों में आप आमतौर पर सभी फाइलों के नवीनतम संशोधन की जांच करेंगे।

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

मैंने जीआईटी पर इस बात को वास्तव में शिक्षाप्रद पाया; http://www.youtube.com/watch?v=4XpnKHJAok8

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

Comments

लेकिन अगर आप कमिट्स के बीच कुछ तोड़ते हैं तो क्या होगा? फिर तुम खो गए। स्वचालित संस्करण का उपयोग करते समय आपके पास यह समस्या कभी नहीं होती है जो गीथहब और पसंद जैसी बेकार संस्करण सेवाओं का उपयोग करते समय मौजूद होती है।

— टिम एकल

@TimEckel 'कुछ तोड़ो बी / डब्ल्यू कमिट्स' से आपका क्या मतलब है? अगर मैं अपने आखिरी कमिटमेंट के बाद कुछ लिखता हूं और नॉन-वर्किंग कोड के साथ नए बदलाव करता हूं, तो मैं अपने बदलावों को आखिरी कमिटमेंट में बदल देता हूं। इतना सरल है।

— अभिनव गौनियाल

@TimEckel का कहना है कि GitHub बेकार है ऐसा कहना है जैसे कि लिनक्स बेकार है - लाखों लोग आपसे असहमत होंगे, लेकिन आप इसे वैसे भी कह रहे हैं क्योंकि आप स्पष्ट रूप से उन लाखों लोगों की तुलना में अधिक चालाक हैं, है ना?

— चरलेह

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

— टिम इकेल

Answer 18

आप शायद तोड़फोड़ जैसा कुछ चाहते हैं, भले ही आप अपने आप से काम कर रहे हों ताकि आपके पास अपने सभी परिवर्तनों का इतिहास हो। आप यह देखना चाहते हैं कि एक बार कोड के एक टुकड़े ने ऐसा क्यों देखा कि यह याद रखें कि आपने बदलाव क्यों किया।

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

Answer 19

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

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

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

Answer 20

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