क्या DVCSes निरंतर एकीकरण को हतोत्साहित करते हैं?

Question

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

यदि वे SVN की तरह एक केंद्रीकृत CVS का उपयोग कर रहे थे, तो हर बार उनमें से एक के आने के बाद, बिल्ड सर्वर अन्य नौ डेवलपर्स के काम के खिलाफ उनके परिवर्तनों को एकीकृत और परीक्षण करेगा। बिल्ड सर्वर बहुत सारा दिन लगातार चलता रहेगा।

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

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

इसका मतलब यह है कि पुराने केंद्रीयकृत औजारों की तुलना में DVCS निरंतर टीमों के लिए कम उपयुक्त हैं? आप लोग इस आस्थगित-धक्का मुद्दे के आसपास कैसे पहुँचते हैं?

Comments

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

बहुत अच्छा सवाल है।

— माइकल ब्राउन

@ डायलेन: मान लें कि दोनों टीमें प्रति दिन कई बार प्रतिबद्ध हैं, लेकिन गिट लोग केवल उन लोगों को एक साथ धक्का देते हैं जब कार्य पूरा हो जाता है।

— रिचर्ड डिंगवाल

मुझे लगता है कि आप पाइप के गलत छोर को देख रहे हैं, आपको मुद्दे मिलते हैं, न कि यदि आप पूरी तरह से धक्का नहीं देते हैं, लेकिन अगर आप नियमित रूप से खींचते नहीं हैं

— jk।

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

— Kyralessa

Answer 1

अस्वीकरण: मैं एटलसियन के लिए काम करता हूं

DVCS कंटीन्यूअस इंटीग्रेशन को हतोत्साहित नहीं करता है जब तक कि डेवलपर अपनी शाखा में नियमित रूप से दूरस्थ रूप से धक्का देता है और CI सर्वर सेटअप होता है ताकि यह ज्ञात सक्रिय शाखाओं का निर्माण करे।

परंपरागत रूप से DVCS और CI के साथ दो समस्याएं हैं:

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

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

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

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

Answer 2

मेरी छोटी टीम एक या दो साल पहले डीवीसीएस में बदल गई थी, और मेरी कंपनी के बाकी लोगों ने कुछ महीने पहले अपना काम किया था। मेरे अनुभव में:

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

Comments

बिल्ड सर्वर सभी नामित शाखाओं का निर्माण करता है इसलिए प्रत्येक कमिटर का अपना बिल्ड सर्वर काम होता है?

क्या इस परिदृश्य में कोड समीक्षक एक गंभीर अड़चन नहीं है?

— एंड्रेस एफ

@ ThorbjørnRavnAndersen: नहीं, बिल्ड सर्वर केवल "हेड" या "डिफॉल्ट" ब्रांच और रिलीज़ ब्रांच बनाता है। इसलिए प्रत्येक उपयोगकर्ता बिल्ड को तोड़ने के डर के बिना अपनी खुद की नामित शाखा के लिए प्रतिबद्ध हो सकता है। हम सभी की शाखाओं को बनाने के लिए एक बिल्ड सर्वर की कल्पना कर सकते हैं, लेकिन कुछ मामलों में मैं कुछ काम करना चाहता हूं जो मैंने पूरा किया है, यह अच्छी तरह से जानते हुए भी कि यह मेरी अपनी शाखा को एक बेकार स्थिति में रखता है। कोड समीक्षा और मर्ज करने से पहले मैं सुनिश्चित करूंगा कि मेरी शाखा स्थिर है। मुझे केवल इस बात का ध्यान है कि मुख्य शाखाएँ जो अन्य सभी का उपयोग करती हैं, वे स्थिर हैं।

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

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

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

Answer 3

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

एक और समस्या जिसका हमें सामना करना पड़ा है वह है निरंतर एकीकरण सर्वर। हमें समस्याओं (उदाहरण के लिए परीक्षण में विफल) के बारे में सूचित किया गया था, केवल तभी जब सर्वर पर आवागमन का सिंक किया गया था।

ऐसा लगता है कि मार्टिन फाउलर ने अपनी साइट पर इसके बारे में लिखा है ।

उस ने कहा, कुछ परियोजनाएँ जो मैंने उल्लेख की हैं, उन्होंने दिन में कम से कम एक बार समस्याओं को कम करने के लिए एक सिंक किया। इसलिए आपके प्रश्न का उत्तर देने के लिए, मुझे लगता है कि DVCS निरंतर एकीकरण को हतोत्साहित कर सकता है और व्यक्तिवाद को बढ़ा सकता है। हालांकि, डीवीसीएस इसका प्रत्यक्ष कारण नहीं है।

डेवलपर अभी भी प्रभारी हैं, भले ही वे वीसीएस का उपयोग करते हों।

Comments

क्या परियोजनाओं ने एक सामान्य लक्ष्य पर जोर दिया या क्या डेवलपर्स को विशिष्ट, डिस्कनेक्ट किए गए लक्ष्यों पर काम करना था?

हम 19 परियोजनाओं पर सामान्यीकरण नहीं कर सकते। लेकिन जब हमें एकीकरण की समस्याओं का सामना करना पड़ा, तो यह भी है क्योंकि कुछ सिद्धांतों जैसे चिंताओं को अलग करना सम्मान नहीं था। मैं जो कहता हूं, हां, DVCS व्यक्तिवाद को प्रोत्साहित करने और निरंतर एकीकरण के लाभों को कम करने के लिए लगता है , लेकिन, यदि डेवलपर्स अच्छी तरह से प्रशिक्षित हैं, तो समस्या को कम करना या समाप्त करना संभव है।

उस स्थिति में मैं आपको सुझाव दूंगा कि आप कंटीन्यू डिलीवरी भी करें, या कम से कम लगातार ग्राहक डिलीवर करें, इसलिए मर्ज के होने की समय सीमा बहुत कम है। क्या आपने इन परियोजनाओं में ऐसा किया है?

बेशक, हम

मैं निरंतर वितरण की अपनी परिभाषा के लिए देख रहा था (अभी भी कुछ सभ्य नहीं मिल सकता है, अगर तुम मुझे कुछ संदर्भ दे सकता है मैं सराहना करेंगे), और पाया इस: continuousdelivery.com/2011/07/...

Answer 4

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

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

मर्क्यूरियल जैसे वितरित वीसीएस के लिए कहें, आप आसानी से लगातार विलय के लिए मजबूत सिफारिश पा सकते हैं :

पहले, अक्सर विलय! यह हर किसी के लिए विलय को आसान बनाता है और आप पहले के विवादों (जो अक्सर असंगत डिजाइन निर्णयों में निहित होते हैं) के बारे में पता लगाते हैं ...

ऊपर जैसी सिफारिशों का अध्ययन करने पर, कोई भी आसानी से यह पता लगा सकता है कि इन अपील का मर्क्यूरियल के साथ कुछ भी नहीं होने के बारे में अपील है।

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

• ^{मैंने केंद्रीयकृत VCS के साथ गंभीर रूप से विलंबित विलय (यहां तक ​​कि लंगड़ा प्रबंधन द्वारा प्रोत्साहित) भी देखा है, साथ ही DVCS के साथ लगातार विलय तब किया जब टीम / प्रबंधन ने सोचा कि यह सही तरीका है। मैंने देखा है कि अगर कोई वीसीएस वितरित या केंद्रीकृत है तो कोई भी परवाह नहीं करता है कि एक या दूसरे तरीके से निर्णय लिया जाए।}

उपरोक्त देखते हुए, यह क्या DVCSes निरंतर एकीकरण को हतोत्साहित करने के लिए सही उत्तर की तरह दिखता है ? म्यू हो जाएगा ।

VCS वितरित किया जा रहा है या नहीं, इसका उस पर पर्याप्त प्रभाव नहीं पड़ता है।

Comments

+1 मैं आपसे सहमत हूं कि प्रबंधन समस्या को हल करने की कुंजी है। हालांकि, हम स्वीकार करते हैं चाहिए कि वहाँ DVCS कि सतत एकीकरण हतोत्साहित में कुछ। वास्तव में, DCVS की एक प्रमुख विशेषता उस व्यवहार को प्रोत्साहित करना है।

हो सकता है @ Pierre303 शायद - मैं भी ऐसा ही महसूस करता हूं, लेकिन यह बहुत ज्यादा एक सिद्धांत है। जैसा कि मैंने लिखा है, मैंने टीम को DVCS के साथ पागलों की तरह एकीकृत किया है और दूसरी तरफ, सबसे अधिक "आइसोलेशनिस्ट" परियोजना जिसे मैंने कभी काम किया था (और वह एक बुरा सपना था) केंद्रीकृत वीसीएस के साथ था। इतना भावनाओं के लिए, इतना सिद्धांत के लिए ...

— कुटकी

मैं मानता हूं कि केवल अनुभवजन्य अवलोकन है, लेकिन बड़ी संख्या में परियोजनाओं पर, और संभवतः एक विशाल "कौशल" पूर्वाग्रह शामिल है।

Answer 5

मेरा अनुभव बिल्कुल विपरीत है , svn का उपयोग करने वाली टीमें दिनों के लिए धक्का नहीं देती हैं, क्योंकि वे जिस कोड पर काम कर रहे थे, वह मैनुअल मर्जिंग पर समय बर्बाद किए बिना ट्रंक को हर किसी के लिए संकलन नहीं करने का कारण होगा । फिर स्प्रिंट के अंत में, हर कोई प्रतिबद्ध होगा, पागलपन का विलय होगा, चीजें अति-लिखित और खो जाएंगी और पुनर्प्राप्त करना होगा। CI प्रणाली लाल हो जाएगी और उंगली से संकेत मिलेगा।

कभी भी Git / Gitorious के साथ यह समस्या नहीं थी।

Git आपको अपनी सुविधानुसार अन्य लोगों के परिवर्तनों को खींचने और मर्ज करने देता है, न कि इसलिए कि किसी और ने कुछ चेक किया है और आप चेक करना चाहते हैं, लेकिन आपके पास करने के लिए मैन्युअल मर्ज करने के 20 मिनट हैं।

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

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

Git रिपॉजिटरी में सभी सक्रिय शाखाओं को ट्रैक करने के लिए जेनकिंस / हडसन की स्थापना करना बहुत आसान है। जब हम SVN से Git में चले गए, तो हमें CI के साथ और अधिक बार प्रतिक्रिया मिली और रिपोजिटरी की स्थिति के बारे में और अधिक प्रतिक्रिया मिली।

Comments

वे सीधे ट्रंक क्यों करेंगे? मुझे लगता है कि यह आपकी समस्या थी।

— gbjbaanb

@gbjbaanb क्योंकि वह पारंपरिक मुहावरेदार सीवीएस काम करने का तरीका है, क्योंकि यह पारंपरिक केंद्रीकृत रेपो मुहावरा है। एसवीएन उपयोगकर्ता आमतौर पर पूर्व सीवीएस उपयोगकर्ता हैं, और एसवीएन में ब्रांचिंग और विलय केवल सीवीएस की तुलना में मामूली बेहतर है; जो सही होने के लिए असंभव के बगल में दर्दनाक था। यह उपकरण और समूह के विचार के कारण सभी SVN दुकानों के 99% में 99% वर्कफ़्लो मामला है।

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

— gbjbaanb

Answer 6

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

जेनकिंस के पास कई गिट रिपॉजिटरी की जांच करने और एकल नौकरी में से किसी एक से 'नवीनतम' प्राप्त करने का समर्थन है। मुझे यकीन है कि अन्य उपकरणों के साथ समान समाधान हैं।

Comments

और अगर आप कुछ ऐसा करना चाहते हैं जो टूटता है, headलेकिन एक सहयोगी की मदद करता है या आवश्यक है तो एक सहयोगी आपकी मदद कर सकता है? आप अपने सहयोगी को एक अंतर और ईमेल बना सकते हैं, लेकिन किसी भी तरह जो सही नहीं लगता है।

— अर्जन

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

— ptyx

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

— अर्जन

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

— ptyx

इसलिए CI को उन सभी शाखाओं को नहीं चुनना चाहिए जिनके बारे में आप जानते हैं, लेकिन केवल वे ही जिन्हें आप CI में चाहते हैं। मेरे लिए वह एक अंतर है। फिर भी, मुझे लगता है कि मैं समझता हूं कि आप क्या कहना चाह रहे हैं, इसलिए +1

— अर्जन

Answer 7

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

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

DVCS ने आपके कमिट्स को एकीकृत करने के एक अधिक पदानुक्रमित मोड को जन्म दिया है। उदाहरण के लिए, मैं अक्सर डेवलपर के साथ बहुत करीब से काम करता हूं जो मेरे बगल में बैठता है। हम प्रति दिन कई बार एक दूसरे की शाखाओं से खींचेंगे। आज, हमने दूसरे डेवलपर के साथ हर कुछ घंटों में एक पुल अनुरोध में बदलाव के माध्यम से सहयोग किया।

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

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

Answer 8

मैं कहूंगा कि DVCS निरंतर एकीकरण के लिए अधिक अनुकूल है। मर्ज उनके साथ चिढ़ नहीं है। हालाँकि इसके लिए अधिक अनुशासन की आवश्यकता होती है। आपको आधार से मर्ज करने के लिए एक पुल के साथ एक स्थानीय प्रतिबद्ध का पालन करना चाहिए और फिर जब आपका काम पूरा हो जाए (अगले पर जाने से पहले) धक्का।

Answer 9

जब मेरी टीम ने Git पर स्विच किया, तो हमने स्पष्ट रूप से हमारी प्रक्रिया को ऐसे निर्धारित किया कि एक धक्का को पुराने VCS में एक कमिट की तरह व्यवहार किया जाए, और प्रत्येक व्यक्ति द्वारा चुने गए के रूप में स्थानीय कमिट अक्सर किया जा सकता है। इसके साथ, CI सिस्टम में कोई अंतर नहीं है कि क्या हम एक DVCS या एक केंद्रीकृत VCS का उपयोग कर रहे हैं।

Answer 10

उत्तर हां भी है और नहीं भी।

यहां अंतर केंद्रीय सीआई-रेपो रेपो पर सीधे प्रतिबद्ध होने और केंद्रीय सीआई-रेपो रेपो में आपके परिवर्तनों को आगे बढ़ाने के बीच है। 'समस्या' आपको मिल सकती है कि डीवीसीएस उपयोगकर्ता वास्तव में उस पुश को नियमित रूप से नहीं कर सकते हैं।

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

(और यदि आपके एसवीएन उपयोगकर्ता हर रात को कमिट नहीं कर रहे हैं, तो उन्हें बताएं - इसकी वही समस्या है)।

Answer 11

Git निरंतर एकीकरण को रोक नहीं रहा है। आपका ट्रंक-आधारित वर्कफ़्लो है।

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

मैं यह बताता हूं कि Google शैली ट्रंक-आधारित वर्कफ़्लो एक VCS जैसे Git के साथ प्रतिउत्पादक है जहाँ विलय आसान है। यहाँ मैं इसके बजाय क्या सलाह दूंगा:

• ब्रेक फीचर्स नीचे छोटा है जिसे विकसित करने में एक या दो दिन से अधिक समय नहीं लगेगा।
• प्रत्येक सुविधा एक निजी शाखा पर विकसित की जाती है।
• डेवलपर निजी शाखा पर अक्सर एकीकृत होता है ( git fetch origin; git merge master)। मैं आमतौर पर इस तरह से काम करते समय दिन में कई बार करता हूं।
• जब डेवलपर विलय और समीक्षा के लिए शाखा प्रस्तुत करता है, तो CI सर्वर एक स्वचालित निर्माण करता है। विलय तभी होता है जब यह गुजरता है।

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

Answer 12

@Jdunay जैसे भयानक तकनीकी समाधान हैं, लेकिन हमारे लिए यह एक लोगों का मुद्दा है - उसी तरह एक वातावरण को बढ़ावा देना जहां लोग अक्सर svn के लिए प्रतिबद्ध होते हैं, यह एक लोगों का मुद्दा है।

हमारे लिए क्या काम किया है: (वर्तमान में सक्रिय देव शाखा के साथ 'मास्टर' को बदलें)

1. मास्टर से बार-बार विलय / विद्रोह
2. बार-बार मास्टर को धक्का देना

3. चीजों के बारे में जागरूकता जो नरक का कारण बनती है, जैसे कि कुछ रिफैक्टोरिंग और संचार द्वारा इसे कम करना। उदाहरण के लिए:

   • सुनिश्चित करें कि हर कोई दोपहर के भोजन से पहले धक्का देता है
   • दोपहर के भोजन के दौरान रीफैक्टरिंग को निष्पादित और धक्का दें
   • सुनिश्चित करें कि हर कोई दोपहर के भोजन के बाद खींचता है