संस्करण नियंत्रण के तहत आप अपनी लाइब्रेरी के विभिन्न संस्करणों को कैसे रखते हैं? क्या आप टैग का उपयोग करते हैं? या शाखाएँ? या कोई दूसरी विधि?

Question

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

हालाँकि यह बेमानी लगता है जब फ़ोल्डर को संस्करण नियंत्रण में रखा जाता है। अतिरेक के अलावा, यदि कोई नवीनतम संस्करण प्राप्त करना चाहता है, तो वह सभी संस्करणों को डाउनलोड कर रहा होगा यदि वह सिर्फ importएस / cloneएस।

अब मुझे संस्करण नियंत्रण के साथ ऐसा करने के कई तरीके दिखाई दे रहे हैं, लेकिन जब से मैं इसके लिए नया हूं, मुझे नहीं पता कि कौन अधिक रखरखाव योग्य होगा।

विधि 1: टैग का उपयोग करना

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

विधि 2: शाखाओं में बंटी संस्करण

इस पद्धति में, मुख्य शाखा विकास शाखा होगी। हर अब और फिर एक स्थिर संस्करण बनाया जाता है (मान लीजिए v1.2.0), आप उस संस्करण के लिए एक शाखा बनाते हैं और इसके लिए कभी प्रतिबद्ध नहीं होते हैं। इस तरह, यदि आप एक निश्चित संस्करण डाउनलोड करना चाहते हैं, तो आपको उस शाखा से कोड प्राप्त होगा। हालाँकि मैंने कहा था कि आप कभी भी इसके लिए प्रतिबद्ध नहीं हैं, हो सकता है कि पुराने संस्करण को चालू रखने के लिए बग फिक्स और पुराने संस्करण की शाखा के लिए प्रतिबद्ध हो। उदाहरण के लिए यदि वर्तमान संस्करण है v2.0, लेकिन ऐसे लोग हैं जो उपयोग करना चाहते हैं v1.2, तो आप किसी अन्य शाखा को प्राप्त कर सकते हैं v1.2, अर्थात् v1.2.1बग फिक्स कर सकते हैं, या बस संस्करण को उसी तरह रख सकते हैं v1.2और बग फिक्स कर सकते हैं।

तो शाखाएँ इस तरह दिखेंगी:

                  v1.2.1  v1.2.2
                 /       /
 v1.0.0   v1.2.0---------     v2.0.0
/        /                   /
-------------------------------------- dev

इस तरह आपके पास हर छोटे संस्करण के अपडेट के लिए शाखाएँ हैं। (ध्यान दें कि ऊपर के ग्राफ़ में, v1.2.1 और v1.2.2 या v2.0.0 जारी होने के बाद बनाया गया था, इसलिए वे v1.2.0 और v2.0.0 के बीच विकास का हिस्सा नहीं थे। इसे पुराने संस्करणों के समर्थन के रूप में सोचें)

विधि 3: विकास शाखा

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

इस मामले में, शाखाएँ इस तरह दिखेंगी:

 ________  ____  ________________  _____ dev
/        \/    \/                \/
---------------------------------- latest_version

संभवत: यह सही टैग के साथ संयोजन के रूप में किया जाना चाहिए?

प्रश्न!

वैसे भी, मेरा सवाल यह है कि आपके अनुभव के आधार पर, इनमें से कौन सा तरीका अधिक व्यावहारिक साबित होता है? वहाँ एक ज्ञात सबसे अच्छा तरीका है (कि संभवतः मैं अपने आप को पता नहीं था)? ये चीजें आमतौर पर कैसे की जाती हैं?

Answer 1

टैग और शाखाएं परस्पर नहीं हैं, आप (और IMO आमतौर पर) उन दोनों का उपयोग कर सकते हैं। टैग विकास में मील के पत्थर को चिह्नित करने के लिए हैं। उदाहरण के लिए यदि आप अपने उत्पाद के 1.2 संस्करण के लिए एक शाखा खोलने के लिए, और आप को चिह्नित v1.2 Beta, RC1, RC2, Final(और फिर, अगर जरूरत है, SP1कि एक ही शाखा पर टैग के साथ आदि)।

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

Comments

खैर, जैसे मैंने कहा कि विधि 3 टैग के साथ संयोजन में आ सकती है, इसलिए आपके पास स्थिर आवागमन के लिए टैग हैं। मुझे यकीन नहीं है, अगर मुझे टैग सही लगे, लेकिन आप एक टैग को टैग करते हैं और फिर आप उस टैग के साथ कमिटमेंट प्राप्त कर सकते हैं? यदि हां, तो आपके पास कई स्थिर संस्करण हैं, लेकिन वे एक ही शाखा में हैं (अलग-अलग टैग्स के तहत)

— शाहबाज

@ शहबाज, हाँ, लेकिन बात यह है कि टैग किए गए संस्करण केवल पढ़े जाते हैं, आप उन पर बदलाव नहीं कर सकते। इसका मतलब है कि ट्रंक पर नई सुविधाओं को विकसित करते समय आप पुराने संस्करणों में बग को ठीक नहीं कर सकते।

— Péter Török

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

— च्लोए

Answer 2

मेरे पास लाइब्रेरी के नाम के साथ एक फ़ोल्डर था, जिसमें संस्करण संख्या के साथ कई फ़ोल्डर थे।

यह प्रभावी रूप से है, जैसा कि आप ध्यान दें, एक गलत दृष्टिकोण, क्योंकि आपके पास पहले से ही संस्करण नियंत्रण है ... संस्करणों को नियंत्रित करते हैं।

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

Comments

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

— पढ़ूंगा

लिंक बहुत अच्छा था। मुझे लग रहा था कि मेथड 2 बेहतर है (कम से कम मेरे लिए, वह मूल रूप से पुस्तकालयों का एकमात्र डेवलपर है)

— शहबाज

Answer 3

तीन तरीके परस्पर अनन्य नहीं हैं, और आपको अपने संस्करण नियंत्रण से अधिकतम लाभ उठाने के लिए तीनों को संयोजित करना चाहिए।

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

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

Answer 4

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

कई रिलीज संस्करणों को बनाए रखने के लिए शाखाओं के उपयोग के बारे में अधिक जानकारी के लिए मेरा जवाब यहां देखें ।