क्या आप एक शाखा में या ट्रंक में विकास जारी रखते हैं? [बन्द है]

170

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

version-control 
— सैम मैकएफी
स्रोत
3
आश्चर्य है कि अगर यह svn के बिना बदला जा सकता है क्योंकि यह स्रोत नियंत्रण प्रबंधन के लिए काफी सामान्य है?
— स्कॉट साद
4
यह उन "धार्मिक" प्रश्नों में से एक प्रतीत होता है।
— जेम्स मैकमोहन
@ जेम्स मैकमोहन - यह अधिक है कि वास्तव में दो परस्पर अनन्य सर्वोत्तम अभ्यास हैं, लेकिन कुछ लोगों को लगता है कि केवल एक ही है। यह मदद नहीं करता है कि एसओ चाहता है कि आपके पास एक सही उत्तर हो।
— केन लियू

जवाबों:

151

मैंने एक बड़े व्यावसायिक अनुप्रयोग के साथ दोनों तरीकों की कोशिश की है।

किस विधि का उत्तर बेहतर है यह आपकी सटीक स्थिति पर बहुत निर्भर करता है, लेकिन मैं लिखूंगा कि मेरे समग्र अनुभव ने अब तक क्या दिखाया है।

समग्र रूप से बेहतर विधि (मेरे अनुभव में): ट्रंक हमेशा स्थिर होना चाहिए।

इस विधि के कुछ दिशानिर्देश और लाभ इस प्रकार हैं:

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

यदि आप इसके विपरीत करने की कोशिश करते हैं और ट्रंक में अपने सभी विकास करते हैं, तो आपके पास निम्नलिखित मुद्दे होंगे:

  • लगातार निर्माण दैनिक समस्याओं के लिए
  • जब एक डेवलपर प्रोजेक्ट पर अन्य सभी लोगों के लिए समस्या उत्पन्न करता है तो उत्पादकता हानि
  • लंबे समय तक रिलीज चक्र, क्योंकि आपको अंततः एक स्थिर संस्करण प्राप्त करने की आवश्यकता है
  • कम स्थिर रिलीज

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

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

वैसे वितरित नियंत्रण प्रणाली बहुत अधिक लचीलापन प्रदान करती हैं और मैं अत्यधिक hg या git पर स्विच करने की सलाह देता हूं।

— ब्रायन आर बॉडी
स्रोत
35
क्षमा करें, लेकिन यह उत्तर गलत है। सभी विकास ट्रंक में होना चाहिए। यदि आपके पास 'स्पाइक' या 'रिस्की' फीचर के लिए कुछ है, तो एक सुविधा शाखा बनाएं। उत्पादन में उत्पाद के प्रत्येक संस्करण के लिए शाखाएं मुख्य होनी चाहिए, या यदि कोई एकल संस्करण एक एकीकरण शाखा का उपयोग करता है।
— मिच गेहूं
52
मैं दावा नहीं कर रहा था कि यह एकमात्र तरीका था, बस यह बेहतर तरीका है। बेशक अगर आपको लगता है कि आपके पास पर्याप्त कारण हैं कि आपको लगता है कि मैं गलत हूं, तो आपको इसे पोस्ट करना चाहिए। कम से कम मेरा जवाब उचित है।
— ब्रायन आर बॉडी
5
यह समस्याग्रस्त है, क्योंकि डेवलपर्स एक शाखा पर लंबे समय तक काम कर सकते हैं जो मुख्य ट्रंक से विचलन कर रहा है। बाद में उस सामान को एकीकृत करना बड़े सिरदर्द पैदा कर सकता है। मेरे लिए हमेशा कुछ न्यूनतम आवश्यकताओं के साथ एक रक्तस्रावी धार को बनाए रखना आसान था (हमेशा संकलन करना चाहिए) और सामान की शाखा जो एक रिलीज के लिए स्थिर होनी चाहिए।
— Mnementh
31
Mnementh के पद के जवाब में, मेरा मानना ​​है कि एक अच्छा समाधान यह है कि एक डेवलपर को समय-समय पर ट्रंक को अपनी शाखा में विलय करना चाहिए ताकि वे ट्रंक की स्थिति से बहुत दूर न हों। प्रत्येक डेवलपर के लिए यह अक्सर पर्याप्त होता है कि वे किसी भी समय एक विशाल पुनर्संयोजन सिरदर्द न करें।
— RjOllos
8
@ Mnementh कोई बहाना नहीं है। सर्वश्रेष्ठ अभ्यास और सिर्फ सामान्य ज्ञान कहता है कि टीम के सभी लोगों को ट्रंक के साथ अपनी शाखाओं को अपडेट करना चाहिए। मेनलाइन ट्रंक सही होने के लिए नहीं है और न ही इसका मतलब है कि आप उत्पादन करने के लिए धक्का देते हैं, यह सिर्फ संकलन करने की आवश्यकता है और यही कारण है कि अच्छे देव वातावरण में अधिकांश देवता यह सुनिश्चित करने में बहुत अच्छे होते हैं और यदि यह नहीं होता है, तो टीम को उस व्यक्ति को एक कठिन समय देने का अधिकार है ... क्रूज़ कंट्रोल और अन्य निरंतर निर्माण सेटअप जैसे उपकरण भी। यही निरंतर एकीकरण है! आपके पास अपनी मेनलाइन ट्रंक नहीं, अपनी शाखाओं का परीक्षण करने के लिए क्यूए है।
— पॉजिटिव
66

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

ऊपर के लोग जो यह कहते हुए आपत्ति करते हैं कि आपके पास होगा:

  • लगातार निर्माण दैनिक समस्याओं के लिए
  • जब एक डेवलपर प्रोजेक्ट पर अन्य सभी लोगों के लिए समस्या उत्पन्न करता है तो उत्पादकता हानि

शायद निरंतर एकीकरण तकनीकों का उपयोग नहीं किया है।

यह सच है कि यदि आप दिन के दौरान कई परीक्षण बिल्ड नहीं करते हैं, तो हर घंटे या एक बार कहें, इन समस्याओं के लिए खुद को खुला छोड़ देगा, जो जल्दी से विकास की गति का गला घोंट देगा।

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

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

कंटीन्यूअस इंटीग्रेशन पर मार्टिन फाउलर का पेपर पढ़ा । हमने एक बड़ी परियोजना (3,000kSLOC) के लिए अपनी खुद की ऐसी प्रणाली को Posix sh की लगभग 2,000 लाइनों में उतारा।

— रॉब वेल्स
स्रोत
1
'निरंतर एकीकरण' का इस संभावना से क्या लेना-देना है कि एक टीम अपने फीचर पर देर से पहुंचती है और एक संपूर्ण रिलीज चक्र को समाप्त कर देती है? यह 'आपके लिए' जाने का सबसे अच्छा तरीका है! प्रति दिन कई बिल्ड करने से आपके द्वारा बनाई गई जानकारी के अलावा कोई भी संभावित समस्या हल नहीं होती है! आपके तर्क इस बात का प्रमाण नहीं देते हैं कि यह एक बेहतर तरीका है (हालाँकि यह वह तरीका है जो मैं आमतौर पर करता हूँ)।
— पहुंचें
इस उत्तर के लिए CI आवश्यक है, लेकिन ब्रायन के लिए भी।
— ज्ञानदेव
2
@ जाइच, प्रति दिन कई बिल्ड्स करना आपको विश्वास दिलाता है कि यह बनाता है ताकि आप नियमित रूप से परीक्षण चला सकें, या तो दिन के दौरान सरल स्मोक टेस्ट या शाम के दौरान प्रतिगमन परीक्षण। यदि आप प्रतिगमन परीक्षण के लिए शाम के निर्माण तक बिल्ड को छोड़ देते हैं, तो आप पूरे प्रोजेक्ट को एक दिन में वापस सेट कर सकते हैं क्योंकि आप निर्माण नहीं कर सकते हैं। इसका मतलब यह है कि सभी देवों को उनके द्वारा प्रस्तुत नए कोड के लिए प्रतिगमन परीक्षणों के परिणाम देखने में सक्षम नहीं होंगे। एक महंगी लागत, सिर्फ इसलिए, उदाहरण के लिए, किसी ने एक वाक्यविन्यास त्रुटि वाले कोड में जाँच की।
— रॉब वेल्स
क्या होगा यदि एक फीचर को बनाने में 2 महीने का समय लगता है, और दूसरे को बनाने में 6 महीने लगते हैं, आपको वहां शाखाओं का उपयोग करना होगा, न कि हर चीज को ऐसे मामलों में ट्रंक में चेक किया जा सकता है
— कल्पेश सोनी
1
@Wolf आप भ्रम के साथ भ्रमित कर रहे हैं, लोग उत्पादों का निर्माण करते हैं, हर कोई devops के लिए काम नहीं करता है
— कल्पेश सोनी
36

मैं "रिलीज़ ब्रांच" का तरीका अपनाता हूं। ट्रंक अस्थिर है। एक बार रिलीज होने के बाद, मैं एक रिलीज शाखा बनाऊंगा, जिसे मैं अधिक सावधानी से व्यवहार करूंगा। जब ऐसा अंत में हो जाता है, तो मैं रिपॉजिटरी की स्थिति को लेबल / टैग कर दूंगा ताकि मुझे "आधिकारिक" जारी किए गए संस्करण का पता चल जाए।

मैं समझता हूं कि इसे करने के अन्य तरीके भी हैं - यह सिर्फ उसी तरह है जैसे मैंने अतीत में किया है।

— मैट डिलार्ड
स्रोत
19

दोनों।

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

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

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

— एंड्रयू एजेकॉम्बे
स्रोत
3
मैं इस पर आपके साथ हूँ ... डेवलपर्स जो हर समय केवल एक ही विधि से चिपके रहते हैं समस्या है!
— पहुंचें
14

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

वैकल्पिक शब्द वैकल्पिक शब्द

क्योंकि मुझे यह पसंद है:

  • यह सरल है: आप इसे चित्र से प्राप्त कर सकते हैं।
  • यह बहुत अधिक मर्ज और संघर्ष मुसीबतों के बिना अच्छी तरह से काम करता है (और तराजू)।
  • आप "कार्यशील सॉफ़्टवेयर" को किसी भी समय (चुस्त की भावना में) जारी कर सकते हैं।

और बस के मामले में यह स्पष्ट रूप से पर्याप्त नहीं था: विकास "कार्य शाखा (तों)" में किया जाता है, ट्रंक का उपयोग Done (releasable) कोड के लिए किया जाता है। सभी विवरणों के लिए कई चुस्त टीमों के लिए संस्करण नियंत्रण की जाँच करें ।

— पास्कल थिवेंट
स्रोत
मेरा व्यक्तिगत अनुभव यह है कि यह केवल आपकी 'टिप्पणी' के विपरीत, छोटी टीमों के लिए काम करता है। जैसे-जैसे टीमें बढ़ती हैं और कहानियों में छूट होती है, अन्य सभी टीमें काफी मात्रा में टीम का विलय करती हैं। और बहुत बड़ी परियोजनाओं (कई फाइलें और केएलओसी) पर, मर्ज की समस्याएं नियमित रूप से दिखाई देने लगती हैं, खासकर जब कोड की अस्थिरता होती है।
— पहुंचें
@ जेच ने फीचर टीम में 5 टीमों के साथ बड़े प्रोजेक्ट पर हमारे लिए अच्छा काम किया है, हालांकि मैं इससे इनकार नहीं कर रहा हूं कि विलय की लागत है।
— पास्कल थिवेंट
11

एक विकास प्रक्रिया पर एक अच्छा संदर्भ जो ट्रंक को स्थिर रखता है और शाखाओं में सभी काम करता है Divmod का अंतिम गुणवत्ता विकास प्रणाली है । एक त्वरित सारांश:

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

वे इसके लिए एसवीएन का उपयोग करते हैं, लेकिन यह आसानी से किसी भी वितरित संस्करण नियंत्रण प्रणाली के साथ किया जा सकता है।

— ट्रैविस बी हार्टवेल
स्रोत
10

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

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

शाखाओं को वास्तविक रेत बक्से माना जाता है, हालांकि ट्रंक को भी यह भूमिका निभानी होगी: टैग यह संकेत देंगे कि कोड उस समय "सोना" है, जो रिलीज के लिए उपयुक्त है।

— जॉन लिमजप
स्रोत
8

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

— ब्रायन स्टीवर्ट
स्रोत
5

यह आपकी स्थितियों पर निर्भर करता है। हम Perforce का उपयोग करते हैं और आमतौर पर विकास की कई लाइनें हैं। ट्रंक को "सोना" माना जाता है और सभी विकास शाखाओं पर होते हैं जो मुख्य पंक्ति में वापस विलय हो जाते हैं जब वे एकीकृत करने के लिए पर्याप्त स्थिर होते हैं। यह उन सुविधाओं को अस्वीकार करने की अनुमति देता है जो कटौती नहीं करते हैं और समय के साथ ठोस वृद्धिशील क्षमता प्रदान कर सकते हैं जो स्वतंत्र परियोजनाएं / सुविधाएँ उठा सकती हैं।

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

इस की सुंदरता यह है कि आप इसे पुनरावर्ती रूप से कर सकते हैं: एक बड़ी सुविधा शाखा अपनी स्वयं की ट्रंक हो सकती है यदि अन्य शाखाएं बंद हो जाती हैं। इसके अलावा, अंतिम रिलीज से आपको स्थिर रखरखाव करने के लिए एक नई शाखा मिलती है।

— जोश सेगल
स्रोत
4

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

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

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

— चक
स्रोत
4

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

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

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

यदि आपके पास डेवलपर्स का एक बड़ा समूह है और आपकी स्थिति में क्या काम करता है, इसके बारे में जानने के लिए आपको प्रयोग करना होगा। यहाँ Microsoft का एक पृष्ठ है जो कुछ उपयोगी हो सकता है: http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx

— हरप्रीत
स्रोत
4

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

— adriaanp
स्रोत
1
बिना डेटाबेस के नियम शाखा में क्यों बदलता है?
— ब्योर्न रिपेन
हमारे पास बस नियम है क्योंकि यह हमारे डेटाबेस वर्जनिंग को मर्ज करना आसान बनाता है। ऐसा इसलिए हो सकता है क्योंकि जिस तरह से हम डेटाबेस को अपडेट करने के लिए स्क्रिप्ट फ़ाइल नामों में अनुक्रमण का उपयोग कर रहे हैं, मुझे यकीन है कि अगर कोई अलग विधि है, तो शाखा में परिवर्तन के लिए डेटाबेस में बदलाव ठीक रहेगा।
— adriaanp
2

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

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

— DevelopingChris
स्रोत
2

हम ट्रंक = वर्तमान विकास धारा, शाखा = रिलीज (एस) दृष्टिकोण का पालन करते हैं। ग्राहक को जारी करने पर हम ट्रंक को शाखा देते हैं और बस ट्रंक को आगे बढ़ाते हैं। आपको इस बात पर निर्णय लेने की आवश्यकता होगी कि आप कितने रिलीज़ का समर्थन करने के लिए तैयार हैं। जितना अधिक आप बग फिक्स पर कर रहे हैं उतना अधिक विलय का समर्थन करेंगे। हम ट्रंक के पीछे 2 से अधिक रिलीज पर अपने ग्राहकों को रखने की कोशिश करते हैं। (जैसे। देव = १.३, समर्थित रिलीज़ १.२ और १.१)।

— लो
स्रोत
1

ट्रंक आम तौर पर मुख्य विकास लाइन है।

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

— 17 का 26
स्रोत
1

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

हम अपनी रिलीज़ को लेबल करते हैं ताकि हम सक्रिय विकास को परेशान किए बिना उत्पादन आपात स्थितियों पर जल्दी से प्रतिक्रिया कर सकें।

— जिम
स्रोत
1

मेरे लिए, यह उस सॉफ्टवेयर पर निर्भर करता है जिसका मैं उपयोग कर रहा हूं।

सीवीएस के तहत, मैं सिर्फ "ट्रंक" में काम करूंगा और कभी भी टैग / शाखा नहीं करूंगा, क्योंकि यह वास्तव में अन्यथा करने के लिए दर्दनाक था।

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

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

— सीपीएम
स्रोत
1

यह वास्तव में इस बात पर निर्भर करता है कि आपका संगठन / टीम संस्करणों का कितना अच्छा प्रबंधन करती है और कौन सी SCM आप उपयोग करते हैं।

  • यदि आगे क्या है (अगली रिलीज में) आसानी से योजना बनाई जा सकती है, तो आप ट्रंक में विकसित होने के साथ बेहतर हैं। शाखाओं के प्रबंधन में अधिक समय और संसाधन लगते हैं। लेकिन अगर अगली बार आसानी से योजना नहीं बनाई जा सकती है (बड़े संगठनों में हर समय होता है), तो आप शायद शाखाओं (सीरियस या दसियों) के बजाय चेरी पिकिंग कमिट्स (सैकड़ों / हजारों) खत्म कर देंगे।
  • Git या Mercurial के साथ, cv और तोड़फोड़ की तुलना में शाखाओं का प्रबंधन करना बहुत आसान है। मैं स्थिर ट्रंक / विषय शाखाओं की पद्धति के लिए जाऊंगा। यह वह है जो git.it टीम का उपयोग कर रहा है। पढ़ें: http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
  • तोड़फोड़ के साथ, मैंने पहली बार ट्रंक-इन-ट्रंक पद्धति विकसित की। जब रिलीज की तारीख आई तो काफी कुछ काम हो रहा था क्योंकि हर बार मुझे चेरी पिक कमिट्स करना पड़ता था (मेरी कंपनी प्लानिंग में अच्छी नहीं है)। अब मैं तोड़फोड़ में विशेषज्ञ की तरह हूं और तोड़फोड़ में शाखाओं को प्रबंधित करने के बारे में अच्छी तरह से जानता हूं, इसलिए मैं स्थिर ट्रंक / विषय शाखाओं की पद्धति की ओर बढ़ रहा हूं। यह पहले से काफी बेहतर काम करता है। अब मैं कोशिश कर रहा हूं कि कैसे git.git टीम काम करती है, हालांकि हम शायद तोड़फोड़ के साथ रहेंगे।
— बो बो
स्रोत
1

यहाँ SVN डिज़ाइन है जो मुझे पसंद है:

  • जड़
    • विकास
      • शाखाओं
        • feature1
        • feature2
        • ...
      • सूँ ढ
    • बीटा
      • टैग
      • सूँ ढ
    • रिहाई
      • टैग
      • सूँ ढ

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

टैग बीटा शाखा या रिलीज़ शाखा में बनाया जा सकता है ताकि हम बीटा और रिलीज़ दोनों के लिए विशिष्ट रिलीज़ का ट्रैक रख सकें।

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

— केविन क्राउल
स्रोत
0

हम जिस विधि का उपयोग करते हैं वह है पर्फेफ़्स दृष्टिकोण, जिसकी चर्चा लौरा विंगरड की महान पुस्तक में है।

http://oreilly.com/catalog/9780596101855/index.html

जबकि पुस्तक पेरफ़ोरस सेंट्रिक (Wingerd एक Perforce उत्पाद प्रबंधक है), अवधारणाओं को किसी भी या सभी VCS पर लागू किया जा सकता है।

पेरफ़ोरस एप्रोच (और प्लेटफ़ॉर्म) ने हमारी बहुत अच्छी सेवा की है। इसका उपयोग बहुत सारी फर्मों (google, Intuit और, मैंने सुना है, Microsoft Windows में ही किया जाता है) में किया जाता है।

पुस्तक अच्छी तरह से पढ़ने लायक है।

0

तोड़फोड़ सम्मेलन प्रश्न IMHO के लिए कोई एक आकार-फिट-सभी जवाब नहीं है।

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

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

सबसे अच्छा काम करने के लिए मैंने जिन दो तरीकों को जाना है, वे हैं शाखा-जब-तब, और शाखा-प्रत्येक-कार्य। ये निश्चित रूप से एक दूसरे के ठीक विपरीत हैं। जैसा मैंने कहा - यह परियोजना की गतिशीलता के बारे में है।

— एक आँख वाला देव
स्रोत
-1

@ ब्रायन आर बॉडी: कृपया ध्यान दें कि यह एक समाधान नहीं है, जब आपकी टीम परियोजना पर समानांतर रूप से संचालित पीपीएल / कार्यों की एक निश्चित राशि तक पहुंच जाती है।

क्यूए विभाग में शामिल होने के बाद, प्रगति में प्रति शाखा एक स्थापना प्रदान करने के लिए आवश्यक प्रयास बहुत अधिक हैं। सोचिए SOA / Clients / Servers / WebServices / डेटाबेस जिनमें से प्रत्येक को प्रति शाखा प्रदान किया जाना है ।

इस समाधान में एकीकरण चरण का भी अभाव है।

— pointernil
स्रोत
हमारी टीम में कई QA शामिल हैं। वे विलय से पहले शाखा से निर्मित एक पूर्ण इंस्टॉलर से प्रत्येक सुविधा का परीक्षण करते हैं।
— ब्रायन आर। बॉन्डी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.