क्या मेरी कंपनी शाखाओं का विलय कर रही है?

Question

मैं हाल ही में ब्रांचिंग और मर्जिंग और SCM: ब्रांचिंग और मर्जिंग प्राइमर - क्रिस बिरमेले के बारे में एक MSDN लेख के पार आया ।

लेख में वे कहते हैं कि 'बिग बैंग मर्ज' एक विलयन एंटीपैटर्न है:

बिग बैंग मर्ज - विकास प्रयास के अंत में शाखा विलय को समाप्त करना और सभी शाखाओं को एक साथ विलय करने का प्रयास करना।

मैंने महसूस किया कि यह मेरी कंपनी द्वारा विकसित की गई सभी शाखाओं के साथ समान है।

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

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

हमारे लिए यह असामान्य नहीं है कि 10-20 सक्रिय शाखाएँ हों जो अंतिम समीक्षा कतार में बैठे हों और उन्हें ट्रंक में मिला दिया जाए।

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

कुछ प्रत्यक्ष प्रश्न मेरे पास हैं:

• क्या हम बहुत ही विरोधी पैटर्न का प्रदर्शन कर रहे हैं जिसे 'बिग बैंग मर्ज' के रूप में वर्णित किया गया था?
• क्या कुछ समस्याएं हैं जो हम इस मर्ज प्रक्रिया का परिणाम देख रहे हैं?
• मेरे बॉस पर अड़चन बढ़ाए बिना हम इस मर्ज प्रक्रिया को कैसे सुधार सकते हैं?

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

इस स्थिति में किसी भी अन्य अंतर्दृष्टि की सराहना की जाएगी।

Comments

विलीन क्यों किया जा रहा है? आमतौर पर, इसे तुरंत नहीं करने का एक कारण है। क्या अकेला आदमी ओवरवर्क करता है और बैकलॉग इतना बड़ा हो जाता है? क्या कोई अन्य कारण है कि विलय समय पर नहीं किया जाता है?

— पॉलीग्नोम

मैं कई बार आपके जैसी ही स्थिति में था। मैं व्यक्तिगत अनुभव से बता सकता हूं कि कई कंपनियां संस्करण नियंत्रण करती हैं, विशेष रूप से शाखाओं में बंटी, बुरी तरह से गलत।

— MeMMK1

जब बॉस छुट्टी पर जाता है तो क्या होता है?

— Liath

आप लिनक्स कर्नेल ब्रांचिंग / मर्ज रणनीति को कैसे परिभाषित करेंगे?

— ब्रियम

संघर्षों के कारण जो परिवर्तन वापस किए जाते हैं, लेकिन अन्य दोषों को फिर से अनुमोदन प्रक्रिया से गुजरने की आवश्यकता नहीं होती है एक बार संघर्षों का समाधान हो जाता है या क्या उन्हें "अनंतिम रूप से अनुमोदित" माना जाता है?

— ग्रेगरी निस्बेट

Answer 1

कुछ सुझाव:

• जब तक प्रत्येक शाखा में किए गए परिवर्तन बहुत कम होते हैं तब तक बहुत सारी सुविधा या बगफिक्स शाखाएं होने में कुछ भी गलत नहीं है, फिर भी आप परिणामी मर्ज संघर्षों को प्रभावी तरीके से संभाल सकते हैं। यदि आपका काम करने का तरीका ठीक है, तो यह आपकी कसौटी होनी चाहिए, न कि कुछ MSDN लेख।

• जब भी किसी शाखा को ट्रंक में विलय किया जाता है, तो ट्रंक को सभी खुले विकास शाखाओं एएसएपी में विलय कर दिया जाना चाहिए। इससे टीम के सभी लोग अपनी-अपनी शाखा में समानांतर रूप से मर्ज संघर्ष को हल कर सकते हैं और इसलिए ट्रंक के द्वारपाल से कुछ बोझ उठाते हैं।

• यह बेहतर तरीके से काम करेगा यदि गेटकीपर तब तक इंतजार नहीं करेगा जब तक कि 10 शाखाएं "ट्रंक में विलय के लिए तैयार नहीं होती हैं" - अंतिम ट्रंक एकीकरण से मर्ज संघर्षों को हल करना टीम के लिए हमेशा कुछ समय की आवश्यकता होती है, इसलिए यह संभव है कि इंटरव्यू टाइम अंतराल में काम करना बेहतर हो। - गेटकीपर द्वारा एक एकीकरण, टीम द्वारा एक पुन: विलय, गेटकीपर द्वारा अगला एकीकरण, टीम द्वारा अगले पुन: विलय, और इसी तरह।

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

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

• आपकी वर्तमान टीम के आकार के लिए, एकल गेटकीपर के पास अभी भी काम हो सकता है। लेकिन अगर आपकी टीम आकार में बढ़ेगी, तो दूसरा द्वारपाल (या अधिक) होने के आसपास कोई रास्ता नहीं है। नोट मैं सुझाव नहीं दे रहा हूं कि सभी को ट्रंक में विलय करने की अनुमति दी जाए, लेकिन इसका मतलब यह नहीं है कि केवल आपका बॉस ही ऐसा करने में सक्षम है। शायद एक या दो वरिष्ठ देव हैं जो द्वारपाल की नौकरी करने के लिए भी उम्मीदवार हो सकते हैं। और यहां तक ​​कि आपकी वर्तमान टीम के आकार के लिए, एक दूसरा द्वारपाल आपकी टीम के लिए ट्रंक को अधिक बार और पहले या जब आपका बॉस उपलब्ध नहीं होता है, तब एकीकृत करना आसान बना सकता है।

Comments

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

— user6567423

@ user6567423 एक और बात जिस पर आप विचार करना चाहते हैं, वह प्रत्येक विकास संस्करण (जैसे 5.2.3 या जो भी हो) के लिए शाखाएं बना रहा है, कि प्रत्येक डेवलपर फीचर काम के लिए शाखा बंद कर सकता है और फिर विलय कर सकता है, और जिसे फिर मुख्य में विलय किया जा सकता है। विकास पूर्ण होने पर बॉस द्वारा शाखा जारी करें।

— nic012000

@ nic012000: क्या यह सुझाव गेटकीपर के लिए कठिन हो सकता है या ट्रंक में एकीकरण के खिलाफ ईकाइडरुअल फीचर शाखाओं को स्वीकार या अस्वीकार कर सकता है? मेरा मतलब है, अगर कई विशेषताओं को एक विकास शाखा में मिलाया जाता है, तो उन परिवर्तनों को आंशिक रूप से ट्रंक में बदल देना वास्तव में कठिन हो जाएगा। या क्या मैं कुछ न कुछ भूल रहा हूं?

— डॉक ब्राउन

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

— आर। शमित्ज़

हाँ जब तक वह कोड की स्थिति से खुश न हो, तब तक कार्य को स्वीकार करने और मर्ज को पूरा करने के लिए अस्वीकार करें।

— nic012000

Answer 2

क्या हम बहुत ही विरोधी पैटर्न का प्रदर्शन कर रहे हैं जिसे 'बिग बैंग मर्ज' के रूप में वर्णित किया गया था?

अच्छा लगता है।

क्या कुछ समस्याएं हैं जो हम इस मर्ज प्रक्रिया का परिणाम देख रहे हैं?

निश्चित रूप से

मेरे बॉस पर अड़चन बढ़ाए बिना हम इस मर्ज प्रक्रिया को कैसे सुधार सकते हैं?

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

विलय होने की प्रतीक्षा कर रही 10-20 शाखाएं इस बात का संकेत हैं कि आपकी प्रक्रिया त्रुटिपूर्ण है। यदि हमारे पास ऐसा होता, तो सभी देव कार्य बंद हो जाते, जब तक कि इसे साफ नहीं किया जाता।

Comments

उत्तर नहीं, जिसकी मुझे तलाश थी क्योंकि मुझे संदेह है कि मेरा मालिक ट्रंक भंडार पर अपनी पकड़ ढीली करने वाला है। लेकिन एक अविश्वसनीय रूप से सहायक उत्तर कम-से-कम, अंतर्दृष्टि के लिए धन्यवाद!

— user6567423

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

— फ्लैटर

वह सहमत है कि वह अड़चन है और वह निश्चित रूप से इसके लिए दूसरों को दोषी नहीं ठहराता है। लेकिन हां, मैं किसी ऐसे टिप्स की तलाश में था जो आसानी से स्पष्ट नहीं हो सकता है जो संभवतः हमारी अड़चन को कम कर सकता है। अंतर्दृष्टि के लिए धन्यवाद

— user6567423

@ user6567423 मुझे उत्सुकता है अगर उसने कभी समझाया कि वह एकमात्र ऐसा व्यक्ति क्यों है जो ट्रंक में विलीन हो सकता है।

— मैथ्यू

Answer 3

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

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

Comments

धन्यवाद, मुझे लगता है कि शाखाओं के संयोजन और संघर्षों को रोकने की युक्तियां शायद हमारी सबसे अच्छी कार्रवाई होगी।

— user6567423

Answer 4

मैं डॉक्टर ब्राउन दोनों से सहमत हूं, लेकिन मैं एक और एंटीपार्टर्न भी देखता हूं:

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

मेरे विनम्र में कुछ प्रबंधन विरोधी हैं:

1. वह / वह एकल चोक पॉइंट है जो टीम के वेग को बाधित करता है। आपका बस कारक है 1. बाधाओं का सिद्धांत कहता है कि आपको श्रृंखला के सबसे धीमे हिस्से को बेहतर बनाने में अपना प्रयास करना चाहिए।
2. आपका प्रबंधक आपकी प्रतिक्रिया चक्र को धीमा कर रहा है और आपकी टीम की चपलता को कम कर रहा है। क्या आप हर हफ्ते रिलीज कर सकते हैं?
3. कोड की मात्रा के साथ जटिलताएं तेजी से बढ़ती हैं। 1000 लाइनों में से 1 से 100 लाइनों के साथ 10 मर्ज करना बेहतर है। यह सिर्फ एक कारण है कि आपको इसे एएसएपी क्यों करना चाहिए
4. यदि आप ट्रंक में विफलता का पता लगाते हैं, तो आप इसे समय में बाद में करेंगे। कई शाखाओं में से कौन सी समस्याग्रस्त थी
5. उन लोगों द्वारा निर्णय लिया जाना चाहिए जिनके बारे में अधिक जानकारी है। इस मामले में कौन अधिक जानता है? मुझे विश्वास है कि डेवलपर्स ने कोड बनाया था।
6. यदि आपका प्रबंधक पवित्र दिन है तो आप उत्पादन में बग को ठीक नहीं कर सकते।
7. आप काम को फिर से कर रहे हैं और वापस शाखाओं को फेंक रहे हैं। यह समय की बर्बादी है। उत्पादन तक पहुंचने का इंतजार समय भी बेकार है।

recomendations:

• आपके प्रबंधक को टीम को जिम्मेदारी सौंपने की आवश्यकता है। आपको यह दिखाने की जरूरत है कि टीम परिपक्व है, पेशेवर है। स्पष्ट करें कि वे टीम में भरोसा कर सकते हैं
• कुछ समीक्षा पद्धति को लागू करें। हो सकता है कि आपको टीम के दो अन्य सदस्यों की जरूरत हो।
• एसवीएन का उपयोग करना कठिन हो सकता है। गेट को एक कोशिश दें और देखें कि क्या यह आपकी मदद करता है। और भी अधिक। यदि आप GitHub का उपयोग करते हैं तो आप पुल अनुरोध तंत्र का उपयोग कर सकते हैं ताकि मर्ज को कुछ वोटों की आवश्यकता हो।
• चुस्त प्रथाओं, निरंतर एकीकरण और DevOps के बारे में जानकारी पढ़ें और साझा करें।

Comments

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

— cmaster

Git के कारण मेरी राय में svn की तुलना में बहुत बेहतर है @cmaster बाहर रखा गया है और अधिक

— reggaeguitar

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

— user6567423

@ user6567423, मैंने पिछले साल एक परामर्श किया था जहां मैंने svn से Git में एक छोटी टीम के संक्रमण में मदद की थी और उनके वर्कफ़्लो को बदलने के लिए, जिसमें उन्हें Git पर प्रशिक्षण देना और कोड समीक्षा और सहयोग के लिए GitLab समुदाय संस्करण (जो खुला स्रोत है) स्थापित करना शामिल है। । वे इसे लेकर बहुत उत्साही थे; यह एक रात और दिन का अंतर था। (इसके अलावा केवल तीन दिन लगे।)

— वाइल्डकार्ड

Answer 5

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

Answer 6

तो आपके पास 20 शाखाएँ हैं। शाखा 1 का विलय कर दिया गया है। फिर शाखा 2 के डेवलपर को शाखा 1 को अपनी शाखा में मर्ज करना पड़ता है, जो संघर्ष के बिना मुख्य में विलय करने में सक्षम होता है, फिर विलय होता है। फिर शाखा 3 के विकासकर्ता को अपनी शाखा में शाखा 1 और शाखा 2 का विलय करना पड़ता है, जो बिना संघर्ष के मुख्य में विलय करने में सक्षम होता है, फिर विलय होता है।

पाठक के लिए व्यायाम: एक प्रोग्राम लिखें जो मेरी पूरी पोस्ट को प्रिंट करता है :-)

यह पागलपन है। आप विलय के समय की एक अविश्वसनीय राशि खर्च करेंगे।

Comments

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

— user6567423

सामान्य एसवीएन विलय व्यवहार, जहां तक ​​मैं बता सकता हूं ...

— सेमीस्टर

Answer 7

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

ब्रांचिंग ही एक ऐसी चीज है जिसे आप तब तक नहीं करना चाहते जब तक आपके पास इसे करने का बहुत अच्छा कारण न हो या आपके पास कोई दूसरा विकल्प न हो। आप चीजों को अधिक कसकर सिंक में रखने के लिए काफी छोटे हैं, जो आसान और सुरक्षित होगा।

Comments

और अगर आप उन विशेषताओं में से सिर्फ एक बग है या समय पर समाप्त नहीं हुआ है तो आप रिलीज को कैसे संभालेंगे? "ब्रांचिंग ही एक ऐसी चीज है जिसे आप तब तक नहीं करना चाहते जब तक आपके पास करने के लिए बहुत अच्छा कारण न हो" - एक बार जब आपके पास 5 लोग एक से अधिक सुविधाओं पर काम करते हैं, तो आपको ब्रांचिंग का उपयोग करना होगा जब तक कि आपके पास बहुत अच्छा कारण न हो।

— इवो ​​वैन डेर विकेन

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

— मार्टिन माट

मैं इस पर अंतिम उपाय के रूप में विचार

— करूंगा