सबवर्सन का उपयोग करते समय, डेवलपर्स को ट्रंक से काम करना चाहिए या ट्रंक का उपयोग केवल प्रत्येक व्यक्तिगत डेवलपर की शाखा से विलय के लिए किया जाना चाहिए और निरंतर एकीकरण सेवा द्वारा देखा जाना चाहिए?सबवर्सन - क्या किसी को ट्रंक से विकास करना चाहिए?
दो बुनियादी रणनीतियां हैं:
जो आप उपयोग करते हैं, कुछ हद तक व्यक्तिगत वरीयता के मामले में किया जाता है। लेकिन इनमें से किसी एक के साथ, व्यक्तिगत डेवलपर्स को अपने प्रयोगात्मक विकास के लिए शाखाओं का उपयोग करना चाहिए।
तो सामान्य रूप से, कोई निश्चित उत्तर नहीं!
इस पर निर्भर करता है कि परिवर्तन कितने व्यापक हैं। एक सामान्य अच्छी प्रथा यह है कि ट्रंक हमेशा संकलित होना चाहिए, लेकिन इसका मतलब यह नहीं है कि डेवलपर्स छोटे बदलाव/बगफिक्स के लिए ट्रंक पर काम नहीं कर सकते हैं - आखिरकार, यह एक कार्यशील प्रतिलिपि बनाने के कारणों में से एक है; आप यह सुनिश्चित कर सकते हैं कि से पहले कुछ संकलित करता है।
बड़े बदलाव या फीचर एडिशंस को हमेशा एकीकरण के लिए तैयार होने तक शाखा में खींच लिया जाना चाहिए ताकि अन्य विकास में हस्तक्षेप न किया जा सके।
मेरे लिए बहुत उचित लगता है, धन्यवाद। –
मुझे लगता है कि यह वास्तव में आपके ऑपरेशन के पैमाने पर निर्भर करता है। 5-10 डेवलपर्स तक जो ट्रंक करने के लिए हर कोई वास्तव में ठीक होना चाहिए। लेकिन निश्चित रूप से सभी को यह ध्यान में रखना चाहिए कि ट्रंक हमेशा संकलित करने की आवश्यकता है। यदि वे बड़े बदलावों पर काम कर रहे हैं जो थोड़ी देर के लिए संकलित नहीं होंगे, तो उन्हें एक शाखा में जाना चाहिए।
स्केल इसे डालने का एक अच्छा तरीका है। –
"एक शाखा में चले जाओ" ... यह नहीं है कि कामकाजी प्रतिलिपि क्या है .. दोनों छोटे काम और व्यापक विकास? –
@ एडेन, आपका क्या मतलब है? आप कामकाजी प्रतिलिपि पर प्रतिबद्ध नहीं हो सकते हैं। यदि आप व्यापक विकास कर रहे हैं, जल्दी या बाद में आप प्रतिबद्ध करना चाहते हैं, और यदि वह प्रतिबद्धता कोड को अस्थिर करने जा रही है, तो यह ट्रंक के बजाय शाखा में होने का अर्थ है। –
मेरे पास ऐसे डेवलपर हैं जो परियोजना शाखाएं बनाते हैं या ट्रंक से अनुरोध/बग शाखाओं को बदलते हैं, और फिर वापस विलय करते हैं, इसलिए एक तरह से, मेरे पास डेवलपर्स ट्रंक से काम कर रहे हैं, लेकिन "विलय" शाखाओं में क्या होता है कुछ बिल्ड-कंट्रोल टूल या प्रक्रिया के माध्यम से।
मैं इस बहुत अच्छी तरह से this question
मैं लगभग हमेशा टीमों कि ट्रंक पर विकसित पर काम किया है कवर किया जाता है लगता है - ठीक काम करता है। मैं यह नहीं कह रहा हूं कि यह सबसे अच्छा विचार या कुछ भी है, सिर्फ कुछ ऐसा नहीं है जो आपको विरोध करने के लायक है।
हालांकि, हमारी प्रणाली हमेशा buildble है और अक्सर सीआई का भी उपयोग करता है। प्रत्येक डेवलपर को अपडेट/पुनर्निर्माण/रीटेस्ट/प्रतिबद्ध चक्र से अवगत होना चाहिए (यह नहीं कि यह मूर्खतापूर्ण है, लेकिन यह काफी अच्छी तरह से काम करता है)।
एचएमएच, जब मुझे लगता है कि हमारे कितने सॉफ़्टवेयर प्रथाओं "अच्छी तरह से पर्याप्त" काम करते हैं तो यह दर्द होता है।
यदि कोई विकल्प "लगभग कभी काम नहीं करता है" –
सबवर्सन का उपयोग करते समय, हर किसी के लिए ट्रंक से बाहर काम करना आम बात है। यदि कोई विशेष डेवलपर बड़ी या "प्रयोगात्मक" सुविधा पर काम कर रहा है, तो उस काम के लिए एक अलग शाखा बनाने के लिए बुद्धिमान हो सकता है, जिसे बाद में ट्रंक में विलय किया जा सकता है।
हालांकि, जिस विधि का आप वर्णन कर रहे हैं, प्रत्येक डेवलपर की अपनी शाखा होने के साथ, सबवर्सन की तुलना में Git के करीब है। यदि यह तरीका है कि आप काम करना पसंद करते हैं, तो मैं इसके बजाय गिट का उपयोग करने की अत्यधिक अनुशंसा करता हूं।
गिट के साथ, अलग-अलग शाखाओं को देखने के लिए किसी प्रकार के निरंतर एकीकरण सर्वर का उपयोग करना आवश्यक नहीं है। इसके बजाए, प्रत्येक डेवलपर की अपनी शाखा होती है, जिसे वे जब चाहें मुख्य शाखा में वापस विलय कर सकते हैं।
समांतर विकास के लिए संस्करण नियंत्रण प्रणाली के साथ काम करने के लिए कई तरीके हैं। ऊपर दिए गए सुझाव के साथ कुछ भी गलत नहीं है - लेकिन प्रत्येक से जुड़े फायदे और नुकसान हैं। मैंने दोनों तरीकों से काम किया है।
ट्रंक का निर्माण और रिहाई शाखाओं काटने ठीक है, लेकिन अगर आपको आपातकालीन उत्पादन रिलीज करने की ज़रूरत है तो आपको रिहाई शाखा को पैच करना होगा और इसे फिर से जारी करना होगा - इसका मतलब है कि आपके सीआई सिस्टम में शाखा बनाना।
शाखाओं में काम करना और मुख्य ट्रंक (निरंतर एकीकरण प्रणाली के साथ निगरानी) को संरक्षित करना भी ठीक है, लेकिन कई शाखाओं में परिवर्तन करने वाले डेवलपर्स के साथ संघर्ष के मुद्दों का कारण बन सकता है।
भी निम्न साइट पर एक नज़र डालें:
http://www.cmcrossroads.com/bradapp/acme/branching/
यह सहित समानांतर विकास के लिए शाखाओं में पैटर्न के एक नंबर पर चर्चा करता है:
अच्छे अंक; लिंक के लिए धन्यवाद। –
ऐसा तर्क है कि डेवलपर्स को ट्रंक पर काम करने की आवश्यकता होनी चाहिए।
यदि आप उन्हें शाखा छोड़ देते हैं, तो कुछ नियमित रूप से उन शाखाओं को बनाए रखने और नियमित अंतराल पर ट्रंक के साथ क्रॉस-सिंक करने के लिए प्रेरित होंगे। यह अनिवार्य रूप से जटिल विलय संचालन का कारण बन जाएगा, और ये बदले में बग का उत्पादन करेगा।
हर किसी को ट्रंक पर मजबूर कर, उन्हें सिर के बहुत करीब रखना होगा, इसलिए खराब विलयों के साथ बग का कम जोखिम होगा। साथ ही, चूंकि हर कोई अद्यतित कोड चलाता है, इसलिए वे बग्स को नोटिस करने की अधिक संभावना रखते हैं, और फिक्स तेजी से प्रतिबद्ध हो जाते हैं।
संभोग, कभी-कभी एक बड़ी सुविधा को अलग-अलग चरणबद्ध करने की आवश्यकता होती है, लेकिन उन मामलों में विशेष रूप से स्वीकृत अपवाद बनाया जा सकता है।
हमारा ट्रंक केवल विलय और तत्काल बग को ठीक करने के लिए है। जब हमारे पास एक नई परियोजना है, तो हम ट्रंक को शाखा में विकसित करते हैं, शाखा में विकसित होते हैं, अगर किसी अन्य शाखा को ट्रंक में विलय कर दिया जाता है और जब हम परीक्षण करने के लिए तैयार होते हैं, तो हम शाखा को तैनात करते हैं। जब परीक्षण ठीक है, हम ट्रंक में विलय करते हैं, और बीटा को छोड़ देते हैं। विलय से पहले, हम समस्याओं से बचने के लिए ट्रंक पर एक संस्करण करते हैं।
बीटा ठीक होने के बाद, हम प्रोडक्शन जारी करते हैं।
संयोग से, एकमात्र चीज जो ट्रंक "विशेष" बनाती है उसका नाम है। जो आपने अभी वर्णित किया है वह एक स्थिर रिलीज शाखा को बनाए रखते हुए ट्रंक पर विकास के समान ही है। आप बस अपनी स्थिर शाखा "ट्रंक" नाम दें और अपनी विकास शाखा को एक परियोजना/रिलीज-विशिष्ट नाम दें, जबकि कई टीमें विपरीत नामकरण सम्मेलन का उपयोग करती हैं। – Darryl
मैं एक संस्करण 3 पर काम कर रहा हूं।आज हमारे उत्पाद का 0 और ट्रंक में मेरे कोड में बदलाव की जांच। रिलीज अभी भी कई हफ्ते आगे है।
एक सहकर्मी कुछ विशेषताओं के साथ प्रयोग कर रहा है जो इसे 4.0 में बना सकता है, लेकिन निश्चित रूप से 3.0 में नहीं। वह अपनी सामग्री को एक अलग शाखा में देख रही है। ट्रंक में उस तरह की चीजों की जांच करना गलत होगा।
एक और सहकर्मी संस्करण 2.5 में बग फिक्स कर रहा है, जिसे हम पहले ही किसी ग्राहक को भेज चुके हैं। वह स्पष्ट कारणों से उन्हें 2.5 शाखा में देख रहा है।
तो, शीर्षक सवाल का जवाब देने (हर कोई जा ट्रंक बंद विकासशील चाहिए, मेरा उत्तर
विलय के बारे में पी एस नहीं। HTH है। हम चुनिंदा कुछ सामान 2.5 शाखा से ट्रंक को बाद में मर्ज कर सकते हैं, लेकिन नहीं । ट्रंक वापस शाखा से ट्रंक के बीच विलय और 4.0 शाखा दोनों तरीकों से जा सकते हैं
Neil Butterworth said रूप में, यह निर्भर करता है;। कई वैध तरीके मौजूद हैं
हालांकि, व्यक्तिगत रूप से मैं एक स्थिर होने की सिफारिश करेंगे। ट्रंक, और अस्थायी शाखाओं पर सभी प्रमुख विकास कर रहे हैं। (यानी, केवल छोटा, इंडिप अंततः परिवर्तन किया गया एक ही प्रतिबद्धता के साथ सीधे ट्रंक पर जाना चाहिए।) लंबी अवधि वाली शाखाओं को मुख्य रेखा से बहुत दूर होने से बचने के लिए, (ऑटो) कम से कम सभी विकास शाखाओं में ट्रंक में जाने वाली हर चीज को मर्ज करें रोज। ओह, और सब कुछ सीआई द्वारा देखा जाना चाहिए - न केवल ट्रंक बल्कि सभी विकास शाखाएं भी। विशेष रूप से हडसन के साथ यह एक तस्वीर है और बहुत कम ओवरहेड का कारण बनता है।
यदि इसमें यह रुचि है कि हमने इसे कैसे लागू किया है, तो this answer में कुछ और विवरण हैं। (मुझे खुद को दोहराने से नफरत है ... :)
मैं वास्तव में इस दृष्टिकोण की अनुशंसा करता हूं कि यह कोडबेज पर काम करने वाली एक टीम है, और भी यदि हर कोई एक ही सुविधा/परिवर्तन। क्यूं कर? खैर, क्योंकि मेरे अनुभव में (जब तक चीजें - रिलीज शेड्यूल, आवश्यकताएं, आदि जैसे नहीं - आपके पर्यावरण में बहुत अनुमानित हैं) यह निश्चित रूप से रिलीज करने योग्य आकार में आपके ट्रंक को बंद करने का भुगतान करता है।
परिशिष्ट, प्रश्न को और अधिक बारीकी से पढ़ने के बाद: ** देव शाखाओं को आम तौर पर प्रति फीचर/बगफिक्स ** मौजूद नहीं होना चाहिए, प्रति डेवलपर नहीं। कुछ व्यक्तिगत साइड-प्रोजेक्ट्स को छोड़कर, शायद, या यदि आप बस अलग-अलग परियोजनाओं पर काम कर रहे हैं (जो ज्यादातर मामलों में उपरोक्त आईएमएचओ होगा, लेकिन मैं digress ...) – Jonik
@ जोनिक - यह सही है, मैं स्थापित करने की कोशिश कर रहा था यदि कोई काम (किसी भी डेवलपर द्वारा) ट्रंक से बाहर या शाखा से बाहर किया जाना चाहिए। –
दाएं; थोड़ा "प्रत्येक व्यक्तिगत डेवलपर की शाखा" बस खड़ा हुआ, और मुझे जोड़ने के लिए प्रेरित किया :) – Jonik
हाँ, यह रिलीज के लिए आपकी कार्यशील प्रति होना चाहिए। आपकी सभी शाखाएं आपके कोड के पिछले रिलीज संस्करण होनी चाहिए।
यह पूरी तरह से आपके रिलीज़ शेड्यूल पर निर्भर करता है। यदि समय-समय पर सभी कामों की जांच एक बार में रिलीज के लिए की जाती है, तो वे सभी को एक क्षेत्र में चेक किया जा सकता है, जैसे ट्रंक। यदि कुछ काम है जो दूसरे के साथ वापस रखा जाएगा, अभी तक अधूरा काम करने के लिए, पहले बाहर जाना है, बाहर जाने वाला पहला कोड ट्रंक के लिए प्रतिबद्ध हो सकता है, और अगला कोड इसकी अपनी शाखा में हो सकता है, या इसके विपरीत।
आपको यह पता होना चाहिए कि विलय और ताज़ा शाखाएं एक परेशानी हो सकती हैं जहां चीजें कभी-कभी गलत होती हैं। तो स्वाभाविक रूप से कम करने की कोशिश कर रहा है कि समझ में आता है। स्रोत नियंत्रण का समग्र विचार यह है कि हर कोई एक ही स्थान पर काम कर सकता है।
अक्सर जब आप बड़ी टीम प्राप्त करते हैं, तो रिलीज शेड्यूल उप-टीमों और उनकी परियोजनाओं द्वारा आयोजित किया जाता है और इनकी अपनी शाखाएं होती हैं।
हां।
यह आपकी नवीनतम शाखा को आपकी सबसे हालिया रिलीज बनाने का कोई अर्थ नहीं है। फिर, आपकी ट्रंक आपकी शाखाओं से पुरानी हो जाती है।
मुझे लगता है कि अगर आप चुस्त हैं और कुछ हफ्तों के भीतर छोटी वृद्धि में रिलीज करते हैं, तो आपको ट्रंक में विकसित होना चाहिए। इस तरह, आपके पास ट्रंक में नवीनतम है, यह लगातार बनाया जाता है, हो सकता है कि यह टूटा हो, लेकिन जल्द ही ठीक हो जाएगा और जब आप रिलीज करने के लिए तैयार हों, इसे टैग करें और इसे छोड़ दें। इस तरह, शाखाओं से विलय करने का कोई सिरदर्द नहीं है।
मुझे लगता है कि मैं यह भी जोड़ना चाहूंगा कि यदि आप शाखाओं में विकास कर रहे हैं, तो आप चुस्त नहीं हो सकते हैं। शाखाओं में विकास केवल झरना में काम करता है।
मुझे लगता है कि आपके द्वारा उपयोग किए जाने वाले टूल यहां भी एक बड़ा कारक हैं।
मेरी कंपनी में हमने स्थिर ट्रंक विकास मॉडल को अपनाया है और ट्रंक में विलय होने से पहले शाखाओं पर पूरी तरह से परीक्षण किया गया है। लेकिन मुझे यह अभ्यास बहुत कठिन लग रहा है क्योंकि फीचर शाखाओं की पूरी तरह जांच करने में अक्सर सत्यापन टीम के लिए महीनों लगते हैं। इसलिए हम इन शाखाओं के साथ महीनों तक घूमते हैं, इससे पहले कि हम उन्हें वापस ट्रंक में विलय कर सकें।
इसका फ्लिप पक्ष हर समय ट्रंक में जाने वाले सभी परिवर्तनों के साथ अस्थिर ट्रंक विकास का उपयोग करना होगा, लेकिन फिर हमारी सत्यापन टीम शिकायत शुरू करती है कि उन्हें कोड में विश्वास नहीं है क्योंकि हर किसी के परिवर्तन हमेशा होते हैं वहाँ और कोई अलगाव नहीं है।
ऐसा लगता है कि इनमें से कोई भी दृष्टिकोण वास्तव में इष्टतम नहीं है। क्या एक टीम के लिए एक और इष्टतम दृष्टिकोण है जहां सत्यापन वास्तव में लंबा समय ले सकता है?
धन्यवाद, नील - इसलिए दिन के अंत में इनमें से कोई भी विकल्प आवश्यक रूप से क्रियापद नहीं है, यह एक और बात है कि हम कैसे चाहते हैं विकास प्रक्रिया का प्रबंधन करें। मैं सीआई द्वारा देखे जा रहे ट्रंक को छोड़ने की ओर झुका रहा हूं, इसलिए हम हमेशा एक स्थिर ट्रंक की गारंटी देते हैं, जिसमें ट्रंक के खिलाफ छोटे विकास और शाखाओं के लिए बड़े (परिभाषित) काम करते हैं। –
जिस कंपनी के लिए मैं काम करता हूं, मैं विकल्प का पालन करता हूं, दूसरे विभाग में वे दूसरी रणनीति का पालन करते हैं। व्यक्तिगत रूप से मैं विकल्प 1 पसंद करता हूं। – RichardOD
शाखाओं में विकास के बारे में एक चेतावनी: आप अन्य शाखाओं में विकास के साथ विलय में देरी करते हैं।इसे कम करने के लिए, हमेशा ट्रंक से अपने विकास शाखा में परिवर्तन मर्ज करें। यही कारण है कि मैं ट्रंक में विकास की वकालत करता हूं और उन ग्राहकों के लिए पुरानी रिलीज पर आपातकालीन सुधारों के लिए शाखाओं का उपयोग करता हूं जो अभी तक नवीनतम और महानतम में अपग्रेड नहीं करना चाहते हैं। – Christian