पारंपरिक टीमों के लिए वितरित संस्करण नियंत्रण का उपयोग करने वाले सिरदर्द?

Question

हालाँकि, मैं अपने व्यक्तिगत प्रोजेक्ट्स के लिए DVCS का उपयोग करता हूं और पसंद करता हूं, और पूरी तरह से यह देख सकता हूं कि यह आपकी परियोजना में दूसरों के योगदान को कैसे आसान बनाता है (जैसे कि आपके विशिष्ट गितुब परिदृश्य), ऐसा लगता है कि "पारंपरिक" टीम के लिए कुछ समस्याएं हो सकती हैं। TFS, Perforce, आदि जैसे समाधानों द्वारा नियोजित केंद्रीकृत दृष्टिकोण ("पारंपरिक" से मेरा मतलब है कि किसी एक परियोजना पर काम करने वाले कार्यालय में डेवलपर्स की एक टीम है जो कोई भी व्यक्ति "मालिक" नहीं है, संभवतः सभी उसी कोड को छूते हैं।)

इन समस्याओं के एक जोड़े को मैंने अपने दम पर दूर किया है, लेकिन कृपया अन्य विचारों के साथ झंकार करें।

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

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

जाहिर है अगर टीम में हर कोई केवल कोड के विभिन्न क्षेत्रों पर काम करता है, तो यह कोई समस्या नहीं है। लेकिन मैं उस मामले को लेकर उत्सुक हूं जहां हर कोई एक ही कोड पर काम कर रहा है। ऐसा लगता है कि केंद्रीकृत मॉडल बलों को बड़े और दर्दनाक मर्ज करने या किसी को "पुलिस" करने के लिए मुख्य रेपो की आवश्यकता को कम करने के लिए जल्दी और अक्सर से निपटने का सामना करना पड़ता है।

तो आप में से जो लोग अपने कार्यालय में अपनी टीम के साथ DVCS का उपयोग करते हैं, आप ऐसे मामलों को कैसे संभालते हैं? क्या आप अपने दैनिक (या अधिक संभावना, साप्ताहिक) वर्कफ़्लो को नकारात्मक रूप से प्रभावित पाते हैं? क्या मेरे कार्यस्थल पर डीवीसीएस की सिफारिश करने से पहले मुझे कोई अन्य विचार होना चाहिए?

Comments

यह एक उत्कृष्ट प्रश्न है। जिस तरह से आपने समस्या का वर्णन किया है वह मुख्य कारण है (दूसरों के बीच) मैं अपनी टीम के साथ DVCS का उपयोग करने पर विचार क्यों नहीं करता (सौभाग्य से - या नहीं - मैं ऐसी कॉल करने की स्थिति में हूं)।

— एलेक्स

मेरे अनुभव और भावनाएँ आपके समान हैं।

— विलियम पायने

Answer 1

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

तुमने कहा था:

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

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

इसलिए प्रत्येक कार्य दिवस के अंत में, कुछ समय के लिए अलग-अलग समय निर्धारित करने की आवश्यकता होती है, जो वास्तव में ये गतिविधियाँ हैं:

1. स्थानीय परिवर्तन करें।
2. केंद्रीय रेपो से खींचो।
3. मर्ज (और मर्ज करें।)
4. केंद्रीय रेपो में पुश करें।

यह उस व्यक्ति पर मर्ज गतिविधि रखता है जो हाल ही में इस कोड पर काम कर रहा था, और किसी अन्य के रूप में जल्दी से अपने परिवर्तनों को एकीकृत करने में सक्षम होना चाहिए।

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

एक और मुद्दा जिसका आप उल्लेख करते हैं:

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

यह हमारे लिए एक मर्ज समस्या नहीं बनाता है, लेकिन एक अलग समस्या पैदा कर सकता है:

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

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

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

यह मेरी कहानी है, और मैं इसे कम से कम कुछ मिनटों के लिए चिपका रहा हूं ...

Comments

यह बहुत अच्छा है। ब्रांचिंग स्थिति में कुछ जटिलता भी जोड़ सकती है।

— पॉल नाथन

डीवीसीएस के साथ, स्पष्ट प्रक्रिया या प्रक्रियाओं की आवश्यकता बढ़ जाती है। बड़ी ताकत के साथ बड़ी जिम्मेदारियां आती हैं।

— न्यूटोपियन

Answer 2

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

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

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

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

Answer 3

जब मैंने एक टीम पर काम किया था जिसमें गिट का इस्तेमाल किया गया था, तो यह नियम था: एक निजी शाखा पर काम करना, तब, जब आप अपना काम बाकी टीम को उपलब्ध कराने के लिए तैयार हों, तो आप धक्का देने से पहले मास्टर पर अपनी शाखा को रिबास कर दें। (फिर अपनी शाखा को मान्य करें।)

इस रणनीति का मतलब था कि मास्टर कमिट की एक रैखिक श्रृंखला थी, और यह कि एकीकरण के सभी मुद्दों को सार्वजनिक होने से पहले शाखाओं पर मरम्मत की गई थी।

Comments

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

— स्ट्रिपिंगवर्यर

Answer 4

एसवीएन जैसे उपकरण जोरदार एकीकृत तरीके से काम करने के लिए प्रोत्साहित करते हैं।

यानी एक साझा शाखा (या तो ट्रंक या एक देव शाखा) के लिए अक्सर प्रतिबद्ध।

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

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

मेरे दिमाग में हमेशा चिंता का विषय यह है कि: महान स्वतंत्रता के साथ उस स्वतंत्रता का उपयोग करने का प्रलोभन आता है।

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

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

यह जरूरी नहीं कि बुरी चीज हो, लेकिन मेरा मानना ​​है कि यह एक ऐसी चीज है जिस पर ध्यान देने की जरूरत है।

Answer 5

Git / मर्क्यूरियल टाइप वर्जन कंट्रोल वाली चीज, अक्सर कमिट करना होता है, और कोड अच्छा होने पर सेंट्रलाइज्ड सर्वर पर पुश करना होता है। इसके साथ एक बड़ा प्लस यह है कि यह छोटे पैच बनाता है, जो संघर्ष के मामलों में लागू करना आसान है। इसके अलावा, आप वर्कफ़्लो की लाइनों में कुछ होना चाहिए:

1. कई स्थानीय प्रतिबद्ध
2. सर्वर से खींचो
3. सर्वर पर पुश करें

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

यह भी मामला है जब आप एक सह-कार्यकर्ता के स्थानीय रेपो से खींचते हैं, जैसा कि दो चीजें हो सकती हैं। या तो वह पहले सर्वर पर धकेलता है, जो ठीक है क्योंकि आपके पास पहले से ही उसके पैच हैं, और कोई संघर्ष नहीं होना चाहिए, या आप पहले धक्का देते हैं, जिसका अर्थ है कि वह केवल आपके पैच को खींचेगा जब वह खींचेगा।

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

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

Answer 6

केंद्रीकृत भंडार के साथ काम करने का सिद्धांत एक ही है जब गैर-लॉकिंग केंद्रीकृत या वितरित प्रणाली के साथ काम करना:

• केंद्रीयकृत प्रणाली में आप:
  1. मेनलाइन से नवीनतम संस्करण प्राप्त करें (तोड़फोड़ में "ट्रंक", गिट में "मास्टर" ...)
  2. फ़ाइलों को संशोधित करें
  3. "अपडेट" कमांड का उपयोग करके मेनलाइन से नवीनतम संस्करण के साथ संशोधनों को मर्ज करें
  4. मेनलाइन के लिए प्रतिबद्ध
• वितरित प्रणाली में आप:
  1. मेनलाइन से नवीनतम संस्करण प्राप्त करें
  2. फ़ाइलों को संशोधित करें
  3. स्थानीय स्तर पर प्रतिबद्ध हैं
  4. मेनलाइन से नवीनतम संस्करण के साथ संशोधनों को मर्ज करें और स्थानीय रूप से परिणाम दें
  5. पुश अप मेनलाइन पर।

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

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

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

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