बॉस को नई परियोजना के लिए एक संस्करण नियंत्रण प्रणाली का उपयोग करने पर संदेह है, क्या मुझे वैसे भी होना चाहिए?

Question

Https://softwareengineering.stackexchange.com/questions/109817/superior-refuse-to-use-subversion देखें

मेरा प्रश्न समान है, लेकिन यहां मेरे परिदृश्य में मुख्य अंतर हैं:

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

• मेरी देव टीम में मेरे, और मेरे बॉस शामिल हैं। हम अपेक्षाकृत छोटे फर्म के "आईटी" विभाग हैं।

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

मेरे बॉस का प्रस्ताव, सीधे ईमेल से चिपकाया गया:

• अपडेट को SUBMISSIONS फ़ोल्डर में पैकेज के रूप में प्रस्तुत किया जाना चाहिए। पैकेज में सभी प्रासंगिक फाइलें और साथ ही एक 'UPDATE.NFO' फाइल होनी चाहिए जिसमें अपडेट का विवरण, शामिल सभी नई फाइलों की एक सूची (विवरण के साथ), और संशोधन विवरण के साथ सभी संशोधित फाइलों की एक सूची होनी चाहिए।

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

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

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

तो, मुझे अपने बॉस को किस तरह का तर्क देना चाहिए? या वह सही है, और कुछ अजीब बग से हमारे सभी काम खोने का खतरा हो सकता है?

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

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

कृपया "कोई अन्य नौकरी प्राप्त करें" टिप्पणी न करें। यह बहस के लिए मददगार नहीं है।

Comments

'और कृपया "कोई दूसरी नौकरी पाएं" टिप्पणी नहीं।' क्यों नहीं? आपका बॉस कयामत है।

— S.Lott

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

— लॉर्ड टाइडस

@ S.Lott, मुझे लगता है कि ओपी को सवाल की सीमा निर्दिष्ट करने का अधिकार है। उदाहरण के लिए, "एक और नौकरी प्राप्त करें" संभव नहीं है, यदि ओपी एक छोटे देश में रहता है और उसका / उसके पिता- / सास नौकरी का बॉस है जिसमें ओपी को दोगुना या तिगुना भुगतान किया जाता है जो वे ' खुले बाजार में फिर से लायक। संक्षेप में, यह सवाल का हिस्सा नहीं है।

— दान रोसेनस्टार्क

@ S.Lott I, on the other hand, think that the OP is being silly in trying to specify the bounds on the answer....खैर, विशिष्ट बाध्य मूर्खतापूर्ण नहीं है। कैरियर सलाह विषय से बाहर है, और हालांकि एक जवाब जो सवाल का जवाब देगा और कैरियर सलाह प्रदान करेगा मेरे द्वारा पूरी तरह से ठीक है, मुझे नहीं लगता कि ओपी के लिए यह निर्दिष्ट करना मूर्खतापूर्ण है कि वह कैरियर सलाह के लिए परवाह नहीं करता है।

— यानिस

@ S.Lott मुझे दूसरी तरफ मूर्खतापूर्ण लगता है, अपने आप में कैरियर सलाह है, खासकर जब यह "दूसरी नौकरी की तलाश में" है। बहुत सारे अज्ञात चर हैं, कि मुझे ऐसी किसी भी सलाह को गंभीरता से लेना असंभव है।

— यानिस

Answer 1

उससे मत पूछो। उसे मत बताना। उसे दिखाओ।

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

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

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

उसे एक चीट शीट दें जो आपके लिए आपके संस्करण नियंत्रण प्रणाली का उपयोग करना आसान बना देगा ।

अंत में, कुछ विकल्पों का सुझाव दें लेकिन निर्णय उसके पास छोड़ दें । क्या आपको अपना सर्वर सेट करना चाहिए, या कई होस्ट की गई सेवाओं में से किसी एक का उपयोग करना चाहिए ? क्या आपको svn, git, या कुछ और का उपयोग करना चाहिए? क्या आपको सिस्टम में सभी सात परियोजनाओं को माइग्रेट करना चाहिए, या पहले एक या दो के साथ प्रयास करना चाहिए?

Comments

+1 के लिए "बताएं नहीं, दिखाएँ (अभ्यास के बाद)"

— जेवियर

लेकिन जैसा कि किसी ने कहा, इसे अपनी प्रति के लिए उपयोग करें

— 0fnt

+1 के लिएsearch your old e-mail and compile a list of problems you've had over the past year that you could have avoided with version control.

— डैनिथ

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

— आर। श्मिट

Answer 2

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

- It's an undo mechanism.
- It's a historical archive.
- It's a reference point for diff.
- It's a backup.
- It's a journal of my progress. 
- It's a server. 

एरिक भी एक बहुत अच्छा शुरुआती स्रोत नियंत्रण हाउ-टू होता है । जोएल स्पोलस्की द्वारा उपलब्ध एक मुफ्त ऑनलाइन मर्क्यूरियल ट्यूटोरियल है, मर्क्यूरियल एक लोकप्रिय वितरित संस्करण नियंत्रण प्रणाली है।

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

और अंत में इससे पहले कि आप अपने बॉस को समझाने की कोशिश करें आप आपत्ति-हैंडलिंग के विषय में तल्लीन करना चाहते हैं । यह बिक्री का 101 है।

यदि असफल - व्यावहारिक रूप से जितनी जल्दी हो सके आगे बढ़ें, तो पवनचक्कियों पर अपना समय बर्बाद करने में ज्यादा बिंदु नहीं।

Comments

एरिक सिंक लेख के लिए +1। एचजी का सुझाव देने के लिए +1। git सभी गुस्से में है, लेकिन यह प्रश्न स्पष्ट रूप से बताता है कि op स्रोत नियंत्रण में एक शुरुआत है और gg की तुलना में hg थोड़ा आसान है। एचजी ट्यूटोरियल के लिए +1। एक बिक्री उन्मुख संदर्भ प्रदान करने के लिए +1, यह है कि आप पॉइन्टी-बालों वाले मालिकों के साथ सबसे अच्छा सौदा करते हैं (-0.5 एक Google खोज चिह्न होने के लिए)। डॉन क्विक्सोट संदर्भ के लिए +1। यह इस तरह का उत्तर है जो मुझे डुप्लिकेट खाते बनाना चाहता है ताकि मैं एक से अधिक बार उत्थान कर सकूं।

— यानिस

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

— माइक नाकिस

Answer 3

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

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

Comments

मैं गिट के उपयोग से सहमत हूं। मैं इसे परियोजनाओं के लिए उपयोग करता हूं, भले ही मैं केवल डेवलपर हूं।

— दानो

मैं भी शुरू कर रहा हूँ। मैं एसवीएन के साथ नहीं ... लेकिन गिट के साथ, एक सर्वर के साथ भी काम किए बिना एक रेपो बनाना और प्रबंधित करना इतना आसान है, कि यह कहना मुश्किल है कि आप जिस चीज पर काम करना शुरू करते हैं वह दूसरा नहींgit init है।

— cHao

सही के बिना .gitignoreएक git रेपो मूल रूप से बेकार है। केवल यही एक चीज है जो आपके पास अलग हैgit init

— दान रोसेनस्टार्क

" लेकिन विलय थोड़ा अधिक समस्याग्रस्त है " - यदि ओपी केवल इसका उपयोग स्वयं करता है, तो बहुत विलय नहीं होने वाला है, क्या वहाँ है? अपने स्वयं के मास्टर में अपनी सुविधा शाखा को वापस लाना शायद, लेकिन अपने बॉस से प्राप्त किसी भी कोड को एक नई प्रतिबद्धता में जाना होगा, नहीं? मुझे एसवीएन के साथ कोई अनुभव नहीं है, हालांकि, केवल गिट।

— आर। स्मित्ज

"वहाँ बहुत सारे विलय होने वाला नहीं है" जब तक वहाँ नहीं है। किसी भी परियोजना, भले ही यह एक शौक परियोजना है, अंततः एक ही समय में दो चीजों पर काम करने के लिए देव टीम (जो एक व्यक्ति हो सकती है) की आवश्यकता होगी। फिर आपको विलय करना होगा, और कुछ बिंदु पर आप मर्ज संघर्ष का सामना करेंगे।

— दान रोसेनस्टार्क

Answer 4

अगर मैं उसे मना नहीं सकता, तो क्या मेरे लिए इसका इस्तेमाल करने का कोई मतलब होगा?

हाँ। इसका उपयोग सिर्फ अपने लिए करने का लाभ है। आपको इतिहास बदल जाता है ताकि आप देख सकें कि क्या अलग है।

नहीं, कोई फायदा नहीं है क्योंकि आपके बॉस ने आपकी परियोजना को बहुत सारे बेकार कामों में उलझा दिया है क्योंकि उन्होंने चीजों को गड़बड़ कर दिया है।

Comments

यह सिर्फ यह नहीं है कि आप देख सकते हैं कि क्या अलग है, आप दो सेकंड के भीतर नए संस्करण और किसी भी पुराने संस्करण के बीच स्विच कर सकते हैं।

— gnasher729

Answer 5

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

नंबर 2. परिवर्तनों की पता लगाने की क्षमता, किसने, कब, आदि किया ... विलय, पूर्ववत करें। संख्या 3. # 2 और कई और मामलों के लिए जादुई टूल को मुश्किल करें। संख्या 4. शाखाएँ संख्या 5. संस्करण, रिलीज़ आदि को टैग करना।

आपको यहाँ सबसे आम git वर्कफ़्लो में से एक के बारे में अधिक जानकारी मिल सकती है: https://nvie.com/posts/a-successful-git-branching-model/

मुझे पता है कि git का उपयोग पहली बार में डराने वाला हो सकता है, लेकिन यह एक कौशल के लिए एक अच्छा निवेश है, और किसी भी विकास टीम के लिए होना चाहिए।

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