संस्करण नियंत्रण का उपयोग करने में गैर-प्रोग्रामर (यानी डिजाइनर) को उलझाने का आसान तरीका?


13

विकास, वेब विकास या अन्यथा के दौरान संस्करण नियंत्रण का उपयोग करके अपनी टीम को शामिल करने के कुछ प्रमुख तरीके क्या हैं?

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

टॉवर जैसी जीयूआई ने मदद की है, लेकिन इसकी अवधारणा या तो गुस्से से मिली है ('मेरी नौकरी नहीं है!' )।

संपादित करें: मुझे थोड़ा स्पष्ट करना चाहिए था कि मुझे केवल छवियों / PSDs से मतलब नहीं है।


11
उपयोग करने के लिए इसे आसान बनाएं ...

1
मुझे लगता है कि आपके द्वारा कुछ दिन बिताने के बाद Git बहुत आसान है, और इस बात पर आम सहमति है कि विकास कैसे होना चाहिए .. यह अभी भी दूसरों के लिए एक बड़ी बाधा है।
केविन

2
याद करने के लिए एक बिट है कि संस्करण नियंत्रण और बैकअप कभी-कभी पिघल जाता है (जबकि बहुत भिन्न होता है) और बाइनरी डेटा के साथ एक डिजाइनर के लिए; बैकअप लेना पहले से ही आदर्श हो सकता है और इसलिए यह समझना कि वह क्या हासिल कर रहा है या समझने की जरूरत है।
एरोन मैकिवर

1
@ केविन: एक प्रोग्रामर के लिए क्या आसान, स्पष्ट और सहज है, जरूरी नहीं कि वह अन्य लोगों, यहां तक ​​कि बुद्धिमान और रचनात्मक अन्य लोगों की तरह भी हो।
डेविड थॉर्नले

1
एक डिजाइनर के साथ सगाई करें और फिर उसे निजी तौर पर संस्करण नियंत्रण में संलग्न करें। :)

जवाबों:


11

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

फ़ाइल साझाकरण / बैकअप हमेशा संस्करण नियंत्रण के बराबर होता है

जब आप कहें:

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

आपको बाइनरी डेटा के साथ संस्करण नियंत्रण का उपयोग करने के नुकसान के बारे में पता होना चाहिए:

  • ओवरराइटिंग : यदि दो डिज़ाइनर एक ही फाइल पर काम कर रहे हैं, तो दूसरा प्रतिबद्ध वर्तमान संस्करण के रूप में पहले बदलाव को ओवरराइट कर देगा। इसे रोकने का एकमात्र तरीका लॉकिंग या निरंतर संचार है कि कौन कौन सी फाइल को कर रहा है, दोनों ही अपनी टीम के वर्कफ़्लो में बाधा डाल सकते हैं।
  • विलय : बाइनरी डेटा में टूल-असिस्टेड विलय गैर-मौजूद है। मैनुअल मर्जिंग दर्दनाक है और भारी मात्रा में त्रुटियों का खतरा है।
  • रिपोजिटरी ब्लोटिंग: वीसी सिस्टम केवल पाठ फ़ाइलों के लिए परिवर्तित लाइनों को संग्रहीत करते हैं। यह द्विआधारी डेटा के साथ संभव नहीं है, क्योंकि पूरी फाइल कुलपति प्रणाली के लिए अलग दिखेगी। इसका मतलब यह है कि 10KB पाठ फ़ाइल के 20 संस्करण केवल 20KB तक ले सकते हैं, 1MB फ़ाइल के 20 संस्करण संभवतः 20MB के करीब होंगे। एक मध्यम आकार की डिजाइन टीम दर्जनों बाइनरी फ़ाइलों पर कई संशोधन आसानी से उत्पन्न कर सकती है। आपका आईटी विभाग भंडारण आवश्यकताओं के लिए जल्द ही आपसे घृणा कर सकता है और संभवत: बढ़ी हुई मेमोरी / सीपीयू आपके वीसी सर्वर के पास होगा।

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

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

अपने कोड के लिए, आपको पूरी तरह से VC का उपयोग करना चाहिए और आप इसे मांगने के लिए सही हैं।

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


"रिपॉजिटरी ब्लोट" के बारे में: आप सही फ़ाइल स्वरूपों के साथ उसके आसपास काम करने की कोशिश कर सकते हैं। डॉक्यूमेंट मार्कअप लैंग्वेज फॉर्मेट और ग्राफिक्स में स्टोर किए गए डॉक्यूमेंट को बाइनरी फॉर्मेट के बजाय ग्राफिक्स मार्कअप लैंग्वेज फॉर्मेट में स्टोर करने से काफी मदद मिल सकती है। बेशक इस की व्यवहार्यता प्रश्न में परियोजना और शामिल लोगों की इच्छा और क्षमता पर निर्भर करती है। ;)
Baelnorn

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

2
@ बियर: यह सच है, लेकिन आधुनिक वीसीएस के लाभों में से एक यह है कि दो लोग एक ही समय पर एक ही काम कर सकते हैं और बहुत से सामंजस्य का काम स्वचालित है। हालांकि, एक बाइनरी फ़ाइल के साथ जहां कोई सार्थक मर्ज प्रक्रिया नहीं है, यह संभव नहीं है। इसके अतिरिक्त, रिपॉजिटरी का प्रमुख वह है जो लोग "वास्तविक" के रूप में सोचेंगे।
jprete

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

1
आप काफी गलत हैं, उदाहरण के लिए: ओवरराइटिंग - यह विपरीत पर संस्करण नियंत्रण की समस्या नहीं है, यह आपको इसका पता लगाने में मदद करता है। वीसी सिस्टम केवल पाठ फ़ाइलों के लिए परिवर्तित लाइनों को संग्रहीत करते हैं। - गिट के लिए गलत।
मारार्टिनस

4

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

यह एक महान रवैया है, 'नहीं मेरी नौकरी!' :-)

खरीद-इन करने का सबसे अच्छा तरीका एक्सप्लोरर में संस्करण नियंत्रण को एकीकृत करने के लिए TortoiseGit या TortoiseSVN जैसे कुछ का उपयोग कर रहा है (विंडोज को संभालने)। यदि आपको संस्करण नियंत्रण प्रतिमान के लिए उपयोग नहीं किया जाता है तो वास्तविक लाभ देखने में समय लगता है। कम से कम कछुआ माउस के साथ वीसीएस के साथ काम करना आसान बनाता है। एक साधारण "राइट क्लिक -> चेकइन" यह सब लेता है।

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

मेरे पास ऑडिट दस्तावेज़ों के एक विशाल सेट के साथ यही समस्या है कि मुझे लोगों को संस्करण नियंत्रण में नहीं लाया जा सकता है, इसलिए हमारे पास समान दस्तावेज़ के 50 संस्करण हैं जो सभी के आसपास तैर रहे हैं।


4

जिस तरह से इस दृष्टिकोण के लिए है सेटअप एक निर्माण प्रणाली (जैसे हडसन ) जो का उपयोग करता है का निर्माण सूत्रों पुनः प्राप्त करने के संस्करण नियंत्रण प्रणाली है कि केवल और यह एक परियोजना नियम बनाने कलाकृतियों कि एक कर रहे हैं निर्माण प्रणाली द्वारा वितरित टेस्ट टीम के लिए जा रहा है और कर रहे हैं अंततः ग्राहक स्थल पर तैनात किया गया।

यह बहुत स्पष्ट करें कि जहां तक ​​परियोजना की प्रक्रिया का संबंध है कुछ भी निर्माण से नहीं आ रहा है केवल डेवलपर्स के लिए निजी है; जब तक किसी के काम को बिल्ड में स्वीकार नहीं किया जाता है, तब तक यह अस्तित्व में नहीं हो सकता है।


2

लाभ का वर्णन करें:

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

1
-1 यह गैर-प्रोग्रामर को उलझाने के बारे में था; सूची एक प्रोग्रामर को दिखाई देती है। यदि आप अपना उत्तर संशोधित करते हैं तो मैं निश्चित रूप से डाउन वोट को हटा दूंगा ...
हारून मैकएवर

1
मुझे लगता है कि आप "गैर-प्रोग्रामर" भाग से चूक गए। आपके द्वारा बताए गए सभी कार्य प्रोग्रामर कार्य हैं।
एरिक फनकेनबस

क्षमा करें, मैंने केवल शीर्षक पढ़ा है, प्रश्न नहीं। मैं जवाब को संपादित करूंगा।
19

1 निकाला ...
हारून मैकएवर

1

संस्करण नियंत्रण के बारे में "नॉट माय जॉब" एक गैर-प्रोग्रामर का एक समझदार रवैया है।

एक संस्करण नियंत्रण प्रणाली को सरल और अदृश्य के रूप में बनाएं क्योंकि ड्रॉपबॉक्स बैकअप के लिए सिंकिंग या टाइम मशीन के लिए है।

यह सिर्फ काम करना चाहिए। कोई चेकआउट नहीं, कोई कमिट नहीं। प्रोजेक्ट फ़ोल्डर में बस फाइलें रखें।


1

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

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


0

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.