शाखा लगाने के लिए या नहीं करने के लिए?


84

हाल ही में मेरे विकास वर्कफ़्लो निम्नलिखित थे:

  1. उत्पाद के स्वामी से सुविधा प्राप्त करें
  2. एक शाखा बनाओ (यदि सुविधा 1 दिन से अधिक है)
  3. इसे एक शाखा में लागू करें
  4. मेरी शाखा में मुख्य शाखा से परिवर्तन (पिछड़े विलय के दौरान संघर्ष को कम करने के लिए)
  5. मेरी शाखा को मुख्य शाखा में वापस मिलाएं

कभी-कभी विलय के साथ समस्याएं थीं, लेकिन सामान्य तौर पर मुझे यह पसंद आया।

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

तो सवाल यह है कि क्या हमें आजकल शाखाओं का उपयोग करना चाहिए?


2
मुझे यकीन है कि यह इसके लिए सही मंच है, लेकिन हां, मैं शाखा लगाऊंगा। लेकिन हो सकता है कि आपको 100% ख़त्म होने से पहले कुछ खास फीचर्स को वापस मर्ज करने के बारे में सोचना चाहिए (प्रीव्यू देने के लिए: P)
ZeissS

1
लगता है कि उन्हें विलय के लिए बेहतर रणनीति की आवश्यकता है।
b01

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

मेरा तर्क है कि शाखाएँ सीआई को आसान
बनाएंगी

7
कृपया एक ही पोस्ट वर्बेटिम को कई स्टैक एक्सचेंज साइटों पर क्रॉस-पोस्ट न करें।
एडम लेअर

जवाबों:


64

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

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

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

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

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

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


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

@anthony सबसे अधिक संभावना है, आप विलय से पहले अपना इतिहास साफ कर देंगे (हटाएं)। इतिहास पुनर्लेखन के खिलाफ किसी ने शायद आपके तरीके का पालन करना बेहतर है।
इडबरी

यदि आप ब्रांचिंग और हिस्ट्री रीराइटिंग निकालते हैं, तो Git का उपयोग क्यों करें?
everton

80

सवाल यह है कि क्या हमें आजकल शाखाओं का उपयोग करना चाहिए?

खैर लगभग आधे साल पहले मुझे उस सवाल का जवाब देने के लिए एक अध्ययन करने के लिए सौंपा गया था। यहां सारांश, अध्ययन किए गए संदर्भों के आधार पर (नीचे सूचीबद्ध है)

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

संदर्भ

  • http://msdn.microsoft.com/en-us/library/aa730834%28v=vs.80%29.aspx

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

  • http://www.cmcrossroads.com/bradapp/acme/branching/

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

  • http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html

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

  • http://www.lostechies.com/blogs/derickbailey/archive/2010/02/24/branching-strategies-when-to-branch-and-merge.aspx

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

  • http://www.snuffybear.com/ucm_branch.htm
    नोट को यहां सूचीबद्ध अन्य संदर्भ दिए गए हैं, लेखक का दावा है कि "यह लेख सॉफ्टवेयर इंजीनियरिंग परियोजनाओं में उपयोग किए जाने वाले तीन प्रमुख ब्रांचिंग मॉडल का वर्णन करता है " उचित नहीं लगता है। इस्तेमाल की जाने वाली शब्दावली व्यापक नहीं लगती है ( EFIX , Model-1,2,3 आदि)।

  • http://svn.haxx.se/users/archive-2007-10/att-0101/SCMBranchingModels-talkback.pdf
    संदर्भ ब्रांचिंग रणनीतियों को संप्रेषित करने में कठिनाइयों का एक दिलचस्प उदाहरण प्रस्तुत करता है।

  • http://simpleprogrammer.com/2010/06/04/simple-branching-strategy-part-1-back-to-basics/
    ... इसे सरल रखें। ट्रंक से सीधे काम करना मेरी राय में अब तक का सबसे अच्छा तरीका है।  
     
    जब मैं वास्तव में इसे अपनी स्क्रीन पर टाइप करता हूं, तो यह लगभग सुनता है, लेकिन अगर आप एक पल के लिए मेरे साथ रहेंगे, तो न केवल मैं आपको दिखाऊंगा कि मुझे क्यों लगता है कि यह एक चुस्त प्रक्रिया के लिए आवश्यक है, लेकिन मैं आपको दिखाऊंगा कि कैसे यह काम करने के लिए ...  
     
    ... अगर मुझे अपने तर्क को एक ठोस तर्क पर आधारित करना था, तो यह निरंतर एकीकरण का मूल्य होगा। मैंने अतीत में सीआई के मूल्य और सर्वोत्तम प्रथाओं के बारे में ब्लॉग किया । मैं सीआई का एक बहुत बड़ा वकील हूँ ...  
     
    ... आप वास्तव में यहाँ अपने आप को एक सवाल पूछने के लिए है: "सभी भूमि के ऊपर है कि आप अपने जटिल शाखाओं में कर रहे हैं और एक वास्तविक मूल्य है कि एक और अधिक सरल रणनीति के ऊपर मौजूद नहीं है, जिसके परिणामस्वरूप रणनीति विलय से उठाने कर रहे हैं?" ...  
     
    .. .A रणनीति मैंने अतीत में प्रभावी रूप से उपयोग की है और समय के साथ विकसित हुई है। मैं इसे संक्षेप में यहाँ प्रस्तुत करूँगा।

    • हर कोई धड़ल्ले से काम करता है।
    • जब आप कोड जारी करते हैं तो शाखा।
    • जब आपको पहले से ही जारी कोड के लिए बग फिक्स बनाने की आवश्यकता होती है, तो एक रिलीज़ को शाखा दें।
    • प्रोटोटाइप के लिए शाखा।
      ...
  • http://www.codelathe.com/blog/index.php/2009/07/02/a-svn-branching-strategy-that-works/
    ... अंत में, याद रखें कि कोई आदर्श ब्रांचिंग और विलय की रणनीति नहीं है। यह आपके अद्वितीय विकास पर्यावरण पर बहुत निर्भर करता है ...

  • http://blog.perforce.com/blog/?cat=62
    ... सबसे खराब स्थिति यह है कि आप एक "सिमेंटिक मर्ज" समस्या का परिचय देते हैं, जहां एक स्वचालित मर्ज का परिणाम गलत होता है, लेकिन ठीक है और अतीत को दबाता है परीक्षण, संभवतः एक ग्राहक-दृश्यमान बग होने के लिए लंबे समय तक जीवित रहना। Eek!  
     
    चोट के अपमान को जोड़ना, क्योंकि वे लंबे समय तक पता लगाने से बच सकते हैं, सिमेंटिक मर्ज की समस्याओं को बाद में ठीक करना मुश्किल है, क्योंकि परिवर्तन अब डेवलपर के दिमाग में ताज़ा नहीं है जिसने परिवर्तन की उत्पत्ति की है। (आमतौर पर किए गए परिवर्तनों को मर्ज करने के बाद आमतौर पर सबसे अच्छा होता है, आदर्श रूप से डेवलपर द्वारा जो परिवर्तन की उत्पत्ति करता है यदि यह व्यावहारिक है) ...

  • https://stackoverflow.com/questions/34975/branching-strategies
    सामुदायिक सदस्य विभिन्न शाखाओं में विभिन्न रणनीतियों का उपयोग करके विभिन्न अनुभव साझा करते हैं। "सर्वश्रेष्ठ" या "सबसे खराब" पर कोई सहमति नहीं बनी।

  • http://www.stickyminds.com/s.asp?F=S16454_COL_2
    अनिवार्य रूप से http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf में प्रस्तुत सामान का संक्षिप्त सारांश

    • http://www.stickyminds.com/s.asp?F=S16511_COL_2
      ... शाखा में कब और कैसे निर्णय लिया जाए, इसके लिए तीन सामान्य दृष्टिकोण हैं:
      • जब आप "सुविधा पूर्ण" हो, तो रिलीज़ शाखा बनाएँ और इस कोड लाइन पर अंतिम-मिनट के मुद्दों को ठीक करने की योजना बनाएं। इस मामले में, रिलीज शाखा वास्तव में "रिलीज-प्रीप कोड कोड" है, जैसा कि सॉफ्टवेयर कॉन्फ़िगरेशन प्रबंधन पैटर्न में वर्णित है , क्योंकि आप उम्मीद करते हैं कि अभी भी काम करना बाकी है।
      • सक्रिय एकीकरण लाइन से हटकर, अंतिम एकीकरण कार्य से बचने के लिए अपनी कार्य शैली बदलें।
      • कार्य शाखा बनाकर नए कार्य के लिए शाखा जारी करने के बाद उस कार्य को सक्रिय विकास लाइन में विलय कर दिया जाता है।
        ... ब्रांचिंग के लिए एक तर्क एक रिलीज के अंत में कोड को अलग करना है ताकि यह स्थिर हो सके। ब्रांचिंग के माध्यम से अलगाव अक्सर एक गुणवत्ता की समस्या का सामना करता है जो एक उत्पाद जारी होने से पहले समानांतर धाराओं को बनाए रखने की अतिरिक्त लागत में खुद को प्रकट करेगा। शाखा लगाना आसान है। बल्कि, यह मर्जिंग है और यह समझने का संज्ञानात्मक उपरिव्यय है कि शाखाओं के बीच प्रवाह कैसे बदलता है जो मुश्किल है, इसलिए एक ऐसी प्रक्रिया चुनना महत्वपूर्ण है जो ब्रांचिंग और विलय की लागत को कम करती है ...
  • http://nvie.com/posts/a-successful-git-branching-model/ गिट-उन्मुख रणनीति।
    ... हम उत्पत्ति / मास्टर को मुख्य शाखा मानते हैं जहां हेड का स्रोत कोड हमेशा उत्पादन-तैयार स्थिति को दर्शाता है ।  
     
    हम उत्पत्ति / विकास को मुख्य शाखा मानते हैं, जहां HEAD का स्रोत कोड हमेशा अगली रिलीज के लिए नवीनतम वितरित विकास परिवर्तनों के साथ एक राज्य को दर्शाता है। कुछ लोग इसे "एकीकरण शाखा" कहेंगे। यह वह जगह है जहाँ से कोई भी स्वचालित नाइट बिल्ड बनाया जाता है ...।

  • http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html
    ... सुविधा शाखा बनाने के लिए उचित होने पर परियोजना नीतियां व्यापक रूप से भिन्न होती हैं। कुछ परियोजनाएं कभी भी फीचर शाखाओं का उपयोग नहीं करती हैं: सभी के लिए / ट्रंक एक फ्री-फॉर-ऑल है। इस प्रणाली का लाभ यह है कि यह सरल है - किसी को शाखा या विलय के बारे में जानने की आवश्यकता नहीं है। नुकसान यह है कि ट्रंक कोड अक्सर अस्थिर या अनुपयोगी होता है। अन्य परियोजनाएं एक चरम पर शाखाओं का उपयोग करती हैं: कोई भी परिवर्तन कभी भी सीधे ट्रंक के लिए प्रतिबद्ध नहीं होता है । यहां तक ​​कि सबसे तुच्छ परिवर्तन एक अल्पकालिक शाखा पर बनाए जाते हैं, ध्यान से समीक्षा की जाती है, और ट्रंक में विलय कर दिया जाता है। फिर शाखा को हटा दिया जाता है। यह प्रणाली हर समय एक असाधारण स्थिर और प्रयोग करने योग्य ट्रंक की गारंटी देती है, लेकिन जबरदस्त लागत परओवरहेड प्रक्रिया।  
     
    अधिकांश परियोजनाएं सड़क के बीच का रास्ता अपनाती हैं। वे आमतौर पर जोर देते हैं कि / ट्रंक संकलित करें और हर समय प्रतिगमन परीक्षण पास करें। एक सुविधा शाखा की आवश्यकता तभी होती है जब किसी परिवर्तन के लिए बड़ी संख्या में अस्थिर करने की आवश्यकता होती है। अंगूठे का एक अच्छा नियम यह सवाल पूछना है: यदि डेवलपर ने अलगाव में दिनों के लिए काम किया और फिर एक साथ बड़े बदलाव को पूरा किया (ताकि / ट्रंक को कभी भी अस्थिर नहीं किया गया), तो क्या यह समीक्षा करने के लिए बहुत बड़ा बदलाव होगा? यदि उस प्रश्न का उत्तर "हाँ" है, तो परिवर्तन को एक सुविधा शाखा पर विकसित किया जाना चाहिए। जैसा कि डेवलपर शाखा में वृद्धिशील परिवर्तन करता है, वे आसानी से साथियों द्वारा समीक्षा की जा सकती है।  
     
    अंत में, काम के बढ़ने के साथ ट्रंक के साथ "सिंक" में एक सुविधा शाखा को सर्वोत्तम तरीके से रखने का मुद्दा है। जैसा कि हमने पहले उल्लेख किया है, एक शाखा पर हफ्तों या महीनों तक काम करने का एक बड़ा जोखिम है; ट्रंक परिवर्तन, उस बिंदु तक डालना जारी रख सकते हैं, जहां विकास की दो लाइनें इतनी भिन्न होती हैं कि यह शाखा को ट्रंक में वापस विलय करने की कोशिश करना एक दुःस्वप्न बन सकता है।  
     
    ट्रंक परिवर्तनों को शाखा में नियमित रूप से विलय करने से इस स्थिति से सबसे अच्छा बचा जाता है। एक नीति बनाएं: सप्ताह में एक बार, पिछले सप्ताह के ट्रंक में परिवर्तन के मूल्य को शाखा में मर्ज करें ...

  • http://thedesignspace.net/MT2archives/000680.html
    ... ग्रहण सीवीएस ट्यूटोरियल का यह खंड ग्रहण वेबसाइट पर पॉल गिलेजन के लेख पर आधारित है: ग्रहण और सीवीएस के साथ शाखाओं में बंटी , और उनकी शर्तों के तहत उनकी अनुमति के साथ उपयोग किया जाता है ईपीएल लाइसेंस। मैं उनके संस्करण में जो बदलाव कर रहा हूं, वे मुख्य रूप से इसे स्टेप इमेजेज और एक्सप्लेनेशन द्वारा और अधिक विस्तार के साथ विस्तारित करने के लिए हैं, और इसे शुरुआती और डिजाइनरों के लिए अधिक सुलभ बनाने के प्रयास में अपने स्वयं के शुरुआती ट्यूटोरियल के साथ इसे एकीकृत करते हैं। अनुभवी डेवलपर्स शायद पॉल के संस्करण से काम करना पसंद करेंगे ...

  • http://learnsoftwareprocesses.com/2007/12/29/common-branching-strategies/
    ... यहाँ कुछ सामान्य शाखा मॉडल हैं:  

    1. ब्रांच-बाय-रिलीज़ मॉडल: सबसे आम ब्रांचिंग रणनीतियों में से एक है, उत्पाद रिलीज के साथ शाखाओं को संरेखित करना। एक शाखा एक रिलीज के लिए सभी सॉफ्टवेयर विकास संपत्ति रखती है। कभी-कभी, अपडेट को एक रिलीज़ से दूसरे रिलीज़ में मर्ज किए जाने की आवश्यकता होती है, लेकिन वे आमतौर पर मर्ज नहीं होते हैं। जब कोई रिटायर होता है, तो शाखाएं बंद कर दी जाएंगी।  
    2. पदोन्नति प्रति शाखा: एक और बहुत ही सामान्य दृष्टिकोण सॉफ्टवेयर परिसंपत्ति पदोन्नति के स्तर के साथ शाखाओं को संरेखित करना है। एक विशिष्ट विकास संस्करण को एक शाखा में विभाजित किया जाता है, जिस पर सभी एकीकरण और सिस्टम परीक्षण किए जाते हैं। जब आप परीक्षण पूरा कर लेते हैं, तो सॉफ़्टवेयर डेवलपमेंट एसेट्स प्रोडक्शन ब्रांच में पहुंच जाते हैं और अंततः उन्हें तैनात किया जाता है।  
    3. टास्क प्रति शाखा: अतिव्यापी कार्यों (या गतिविधियों) और उत्पादकता में कमी से बचने के लिए, आप उन्हें एक अलग शाखा पर अलग कर सकते हैं। ध्यान रखें कि ये अल्पकालिक शाखाएं हैं जिन्हें कार्य पूरा होते ही मर्ज किया जाना चाहिए, अन्यथा आवश्यक रूप से विलय का प्रयास उन्हें पहली बार में बनाने के उत्पादकता लाभों से अधिक हो सकता है।  
    4. प्रति घटक शाखा: आप सिस्टम आर्किटेक्चर के साथ प्रत्येक शाखा को संरेखित कर सकते हैं। इस रणनीति में, आप अलग-अलग घटकों (या सबसिस्टम) को शाखा देते हैं। तब एक घटक विकसित करने वाली टीम यह तय करती है कि अपने कोड को एकीकरण शाखा के रूप में कार्य करने वाली विकास लाइन में वापस मर्ज करें। यह रणनीति अच्छी तरह से काम कर सकती है यदि सिस्टम आर्किटेक्चर जगह में है और व्यक्तिगत घटकों में अच्छी तरह से परिभाषित इंटरफेस हैं। तथ्य यह है कि आप शाखाओं पर घटक विकसित करते हैं, सॉफ्टवेयर विकास परिसंपत्तियों पर अधिक सूक्ष्म नियंत्रण को सक्षम बनाता है।  
    5. प्रति प्रौद्योगिकी शाखा: सिस्टम आर्किटेक्चर के साथ एक और ब्रांचिंग रणनीति। इस मामले में शाखाओं को प्रौद्योगिकी प्लेटफार्मों से जोड़ा जाता है। कॉमन कोड एक अलग शाखा पर प्रबंधित किया जाता है। सॉफ्टवेयर विकास की अद्वितीय प्रकृति के कारण शाखाओं पर संपत्ति का प्रबंधन, वे शायद विलय नहीं ...
  • http://msdn.microsoft.com/en-us/library/bb668955.aspx
    ... ब्रांचिंग और मर्जिंग दिशानिर्देशों के सारांश के लिए इस गाइड में "सोर्स कंट्रोल गाइडलाइन्स" में ब्रांचिंग और मर्जिंग दिशानिर्देशों का संदर्भ लें । ... जब शाखाओं में बँटे, तो निम्नलिखित पर विचार करें:

    • जब तक आपकी विकास टीम को समवर्ती फ़ाइलों के एक ही सेट पर काम करने की आवश्यकता न हो, तब तक शाखा न लगाएं। यदि आप इसके बारे में अनिश्चित हैं, तो आप किसी बिल्ड को लेबल कर सकते हैं और बाद में उस बिल्ड से एक शाखा बना सकते हैं। मर्जिंग शाखाएं समय लेने वाली और जटिल हो सकती हैं, खासकर अगर उनके बीच महत्वपूर्ण बदलाव हों।
    • अपनी शाखा के पेड़ों की संरचना करें ताकि आपको केवल पदानुक्रम के बजाय पदानुक्रम (शाखा वृक्ष के ऊपर और नीचे) के साथ विलय करने की आवश्यकता हो। पदानुक्रम में शाखा करने के लिए आवश्यक है कि आप एक आधारहीन मर्ज का उपयोग करें, जिसके लिए अधिक मैन्युअल संघर्ष समाधान की आवश्यकता होती है।
    • शाखा पदानुक्रम शाखा माता-पिता और शाखा बच्चे पर आधारित है, जो डिस्क पर स्रोत कोड की भौतिक संरचना से भिन्न हो सकती है। अपने मर्ज की योजना बनाते समय, डिस्क पर भौतिक संरचना के बजाय तार्किक शाखा संरचना को ध्यान में रखें।
    • बहुत गहराई से शाखा न करें। क्योंकि प्रत्येक मर्ज को निष्पादित करने और संघर्षों को हल करने में समय लगता है, एक गहरी शाखा संरचना का मतलब यह हो सकता है कि मुख्य शाखा के प्रचार के लिए एक बच्चे की शाखा में परिवर्तन बहुत लंबा समय लग सकता है। यह प्रोजेक्ट शेड्यूल को नकारात्मक रूप से प्रभावित कर सकता है और बग को ठीक करने के लिए समय बढ़ा सकता है।
    • एक उच्च-स्तर पर शाखा और कॉन्फ़िगरेशन और स्रोत फ़ाइलों को शामिल करें।
    • समय के साथ अपनी शाखाओं की संरचना का विकास करें।
    • विलय को निष्पादित करने और टकराव को हल करने के लिए एक या अधिक डेवलपर्स की आवश्यकता होती है। मर्ज किए गए स्रोत का पूरी तरह से परीक्षण किया जाना चाहिए क्योंकि यह खराब मर्ज निर्णय लेने के लिए असामान्य नहीं है जो निर्माण को अस्थिर कर सकता है।
    • शाखा पदानुक्रम में विलय करना विशेष रूप से कठिन है और आपको कई संघर्षों को मैन्युअल रूप से संभालने की आवश्यकता होती है जो अन्यथा स्वचालित रूप से नियंत्रित किए जा सकते हैं।  
      यह निर्णय कि क्या एक शाखा का निर्माण किया जा सकता है, क्या वास्तविक समय में विलय की लागतों की लागत शाखाओं के बीच विलय की ओवरहेड लागत से अधिक है ...
  • http://kashfarooq.wordpress.com/2009/11/23/bazaar-branching-strategy-with-a-subversion-trunk/

    • http://kashfarooq.wordpress.com/2010/12/16/bazaar-branching-strategy-with-a-subversion-trunk-revised/
    • http://kashfarooq.wordpress.com/2009/11/02/using-bazaar-feature-branches-with-a-subversion-trunk/
    • http://kashfarooq.wordpress.com/2009/09/08/bazaar-or-git-moving-away-from-subversion/
      ... क्या इनमें से कोई भी तोड़फोड़ की शिकायतें परिचित हैं?
      • आपको बेतरतीब ढंग से निर्देश दिया जाता है कि "आपको अपडेट चलाने की आवश्यकता है"। फिर आप एक अपडेट करते हैं - जिसे पूरा करने में उम्र लगती है। और फिर, अंत में, आप देखते हैं कि कोई परिवर्तन नहीं थे जिन्हें डाउनलोड करने की आवश्यकता थी।
      • आपको बेतरतीब ढंग से निर्देश दिया जाता है कि "आपको सफाई चलाने की आवश्यकता है"।
      • आपको भारी मर्ज की समस्या है। उदाहरण के लिए, आप किसी वर्ग का नाम बदलने के लिए ReSharper का उपयोग करते हैं, और कुछ अन्य ने उस समय में उस वर्ग को अपडेट किया है। फिर आप खूंखार पेड़ संघर्ष त्रुटि (कंपकंपी) देखते हैं। या इससे भी बदतर, आप एक पूरे नाम स्थान और फ़ोल्डर (डबल कंपकंपी) का नाम बदलें। अब आप वास्तव में दर्द की दुनिया के लिए हैं।
      • आपका मर्ज अधिक से अधिक मैनुअल हो जाता है। आपको अक्सर WinMerge का उपयोग करना होगा क्योंकि सबवर्सन को कोई सुराग नहीं मिला है।
      • आप अक्सर संशोधनों / कुछ भी अपडेट करने / जांचने के लिए कछुआ के लिए इंतजार कर रहे हैं।  
         
        मेरी USB पेन ड्राइव पर मेरे पास एक तोड़फोड़ का भंडार है। मुझे पेड़ से टकराव मिलता है और उस के साथ समस्याओं का विलय होता है, और मैं केवल उपयोगकर्ता हूँ!  
         
        मुख्य समस्या विलय है ...  
         
    • "तोड़फोड़ बेकार है" परिचित लगता है। जोएल और लिनुस को सुनने का समय ?
  • http://social.msdn.microsoft.com/Forums/en/tfsversioncontrol/thread/f127676c-8f05-410c-9a30-0eb43a26a9fa
    इवोल्यूशन सिस्टम के मामले में रिलीज़ आइसोलेशन शाखा रणनीति के लिए सबसे अच्छा अभ्यास।

  • http://branchingguidance.codeplex.com/
    "Microsoft टीम फ़ाउंडेशन सर्वर ब्रांचिंग गाइडेंस" - विभिन्न परियोजनाओं के अनुरूप सिफारिशों के साथ विशाल और विस्तृत दस्तावेज़: यहाँ HTML संस्करण । साबित होता है कि Microsoft एक-आकार-फिट-सभी दृष्टिकोण wrt ब्रांचिंग रणनीतियों में विश्वास नहीं करता है।

  • https://stackoverflow.com/questions/597707/best-branching-strategy-when-doing-continuous-integration
    जब आप निरंतर एकीकरण करना चाहते हैं तो उपयोग करने के लिए सबसे अच्छी शाखा रणनीति क्या है? ... उत्तर आपकी टीम के आकार और आपके स्रोत नियंत्रण की गुणवत्ता और सही ढंग से जटिल परिवर्तन सेट को मर्ज करने की क्षमता पर निर्भर करता है ...

  • http://codicesoftware.blogspot.com/2010/03/branching-strategies.html
    ... CVS और SVN पूरी ब्रांचिंग / विलय की रणनीति को हतोत्साहित कर रहे थे क्योंकि वे ऐसा करने में पूरी तरह से असमर्थ थे ... ... सरल नियम: आपके द्वारा लागू की जाने वाली प्रत्येक नई सुविधा या बगफ़िक्स के लिए एक कार्य शाखा बनाएं ... यह SVN / CVS उपयोगकर्ताओं के लिए ओवरकिल की तरह लग सकता है, लेकिन आपको पता है कि कोई भी आधुनिक SCM आपको एक सेकंड में शाखाएं बनाने देगा, इसलिए कोई वास्तविक ओवरहेड नहीं है।  
     
    महत्वपूर्ण नोट: यदि आप इसे ध्यान से देखेंगे तो आप देखेंगे कि मैं धनी-जप करने वाले के रूप में कार्य शाखाओं का उपयोग करने की बात कर रहा हूँ ...

  • http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_proj.doc/c_bntr_plnbrstrat.htm
    ... ब्रांचिंग नीति विकास से प्रभावित है। परियोजना के उद्देश्य और कोड बेस के विकास को नियंत्रित करने के लिए एक तंत्र प्रदान करता है। ब्रांचिंग नीति के रूप में कई संगठन हैं जो तर्कसंगत क्लीयरेज़ संस्करण नियंत्रण का उपयोग करते हैं। लेकिन ऐसी भी समानताएं हैं जो सर्वोत्तम प्रथाओं के लिए सामान्य पालन को दर्शाती हैं ...

  • http://blogs.open.collab.net/svn/2007/11/branching-strat.html
    ... तोड़फोड़ मॉडल (या सामान्य रूप से खुला स्रोत मॉडल अधिक सटीक) वह है जो अस्थिर ट्रंक मॉडल में दिखाया जा रहा है। ।

  • http://en.wikipedia.org/wiki/Trunk_%28software%29
    सॉफ्टवेयर विकास के क्षेत्र में, ट्रंक संशोधन नियंत्रण के तहत एक फ़ाइल ट्री की अनाम शाखा (संस्करण) को संदर्भित करता है । ट्रंक को आमतौर पर एक परियोजना का आधार माना जाता है, जिस पर विकास आगे बढ़ता है। यदि डेवलपर्स ट्रंक पर विशेष रूप से काम कर रहे हैं, तो इसमें हमेशा परियोजना का नवीनतम अत्याधुनिक संस्करण होता है, लेकिन इसलिए यह सबसे अस्थिर संस्करण भी हो सकता है। एक अन्य दृष्टिकोण ट्रंक से एक शाखा को विभाजित करना है, उस शाखा में परिवर्तन लागू करना और परिवर्तनों को वापस ट्रंक में मर्ज करना है जब शाखा स्थिर और काम करने वाली साबित हुई है। विकास मोड और प्रतिबद्ध पर निर्भर करता हैनीति में ट्रंक में सबसे स्थिर या कम से कम स्थिर या कुछ-के-बीच का संस्करण हो सकता है।  
     
    अक्सर मुख्य डेवलपर का काम ट्रंक में होता है और स्थिर संस्करण शाखाबद्ध होते हैं, और कभी-कभी बग-फिक्स को शाखाओं से ट्रंक में विलय कर दिया जाता है। जब भविष्य के संस्करणों का विकास गैर-ट्रंक शाखाओं में किया जाता है, तो यह आमतौर पर उन परियोजनाओं के लिए किया जाता है जो अक्सर बदलते नहीं हैं, या जहां एक बदलाव के विकास में एक लंबा समय लगने की उम्मीद है, जब तक कि यह ट्रंक में शामिल करने के लिए तैयार नहीं होगा। ।

  • http://www.mcqueeney.com/roller/page/tom/20060919
    ... ये सबवर्सन सर्वोत्तम प्रथाओं पर एक वेबिनार से नोट्स हैं , CollabNet द्वारा 30 अगस्त, 2006 को आयोजित किया गया। ... दो संगठनात्मक रणनीतियाँ: अस्थिर ट्रंक बनाम स्थिर ट्रंक ... ... जब संभव हो तो एक अस्थिर ट्रंक ...

  • https://stackoverflow.com/questions/153812/subversion-is-trunk-really-the-best-place-for-the-main-development
    SVN में, ट्रंक मुख्य विकास के लिए अनुशंसित स्थान है और मैं इस सम्मेलन का उपयोग करता हूं मेरी सभी परियोजनाओं के लिए। हालांकि, इसका मतलब यह है कि ट्रंक कभी-कभी अस्थिर होता है, या यहां तक ​​कि टूट जाता है ... ... यह बेहतर नहीं होगा कि "शाखा / देव जैसी कुछ शाखा पर" जंगली विकास "करें और जब निर्माण उचित हो तो ट्रंक में विलय करें" ठोस?

    • ... ट्रंक वह जगह है जहां चल रहा विकास होना चाहिए। आपको वास्तव में "टूटे" कोड के साथ कोई समस्या नहीं होनी चाहिए, अगर हर कोई उन्हें करने से पहले अपने परिवर्तनों का परीक्षण कर रहा है। अंगूठे का एक अच्छा नियम है कि आप अपने परिवर्तनों को कोड करने के बाद एक अपडेट (रिपॉज से सभी नवीनतम कोड प्राप्त करें) करें। फिर निर्माण और कुछ इकाई परीक्षण करें। यदि सब कुछ बनता है और काम करता है, तो आपको इसे जांचना अच्छा होना चाहिए ...
    • ... नहीं ट्रंक सबसे अच्छी जगह नहीं है। हमारे संगठन में हम हमेशा इस दृष्टिकोण का पालन करते हैं: ट्रंक में रिलीज़ कोड होता है, इसलिए यह हमेशा संकलन करता है। प्रत्येक नई रिलीज / मील के पत्थर के साथ हम एक नई शाखा खोलते हैं। जब भी कोई डेवलपर किसी आइटम का मालिक होता है, तो वह इस रिलीज़ शाखा के लिए एक नई शाखा बनाता है और इसे परीक्षण करने के बाद ही रिलीज़ शाखा में विलीन कर देता है। सिस्टम परीक्षण के बाद रिलीज शाखा को ट्रंक में मिला दिया गया है ...
  • http://blog.yclian.com/2009/03/working-on-branches-and-stable-trunk.html
    ... मैं ट्रंक पर काम करता था क्योंकि मैंने जिन परियोजनाओं पर काम किया था, उनके लिए यह या तो मैं था। एकमात्र डेवलपर या टीम ने सुनिश्चित किया कि सभी कोड चेक-इन ने स्थानीय परीक्षण पास कर लिए हैं। अन्यथा, हमने बग फिक्स के लिए (हम अभी भी) शाखाएं बनाईं, नई सुविधाओं के लिए बड़े कोड आदि,  
     
    लगभग 2 महीने पहले, मेरे पास कमल के साथ एक छोटा सत्र था और उन्होंने मेरे साथ कहानी / शाखा का विचार साझा किया । और जैसे-जैसे मेरी टीम और अधिक देव लोगों के साथ बढ़ने लगी, मुझे और अधिक ब्रांचिंग को प्रोत्साहित करने की आवश्यकता महसूस हुई और अब यह एक नियम बन गया है। CI के साथ परिभाषित स्वचालित परीक्षणों के साथ एक परियोजना के लिए, एक स्थिर ट्रंक की गारंटी है और यह अभ्यास इसमें बहुत अच्छी तरह से फिट हो सकता है।  
     
    हम git का उपयोग नहीं करते हैं, लेकिन तोड़फोड़ इसलिए करते हैं कि हमने कैसे शुरुआत की और हम अभी भी इसके साथ सहज हैं (ज्यादातर समय) ...

  • http://www.ericsink.com/scm/scm_branches.html
    यह ऑनलाइन कंट्रोल सोर्स नामक एक पुस्तक का हिस्सा है , जो स्रोत नियंत्रण, संस्करण नियंत्रण और कॉन्फ़िगरेशन प्रबंधन पर एक सर्वोत्तम प्रैक्टिस गाइड है  
     
    ... एरिक के पसंदीदा ब्रांचिंग अभ्यास ... एक "मूल रूप से अस्थिर" ट्रंक रखें। ट्रंक में अपना सक्रिय विकास करें, जिसकी स्थिरता जारी होने के साथ बढ़ती जाती है। आपके जहाज करने के बाद, एक रखरखाव शाखा बनाएं और इसे हमेशा बहुत स्थिर रखें ...  
     
    ... अगले अध्याय में मैं इसे विलय करने के विषय में तब्दील करूंगा ...

  • http://marc.info/?l=forrest-dev&m=112504297928196&w=2 अपाचे फॉरेस्ट प्रोजेक्ट के
    लिए शाखाओं की रणनीति पर चर्चा करते हुए धागे का मेल शुरू करना

    • कृपया ध्यान दें कि वर्तमान में परियोजना रिलीज शाखाओं के साथ अस्थिर ट्रंक मॉडल का उपयोग करती है:
    • "विकास कार्य एसवीएन के ट्रंक पर किया जाता है ... एसवीएन की" रिलीज़ शाखाएं "हैं, उदाहरण के लिए forrest_07_branch।" ( परियोजना दिशानिर्देश )
    • "रिलीज उम्मीदवार पैकेज का निर्माण ... 17. एसवीएन में एक रखरखाव शाखा बनाएं ..." ( कैसे जारी करें )
  • ओ रेली सीवीएस शाखाकरण डॉक्स:
    http://commons.oreilly.com/wiki/index.php/Essential_CVS/Using_CVS/Tagging_and_Branching#Basically_stable

    • ... मूल रूप से स्थिर शाखा दर्शन में कहा गया है कि ट्रंक में प्रोजेक्ट डेटा होना चाहिए जो हमेशा रिलीज के लिए तैयार होने के करीब है ... ... इस दर्शन के अधिक उदार रूपांतर कुछ भी अनुमति देते हैं जो डेवलपर यूनिट-टेस्टिंग को मर्ज करने की अनुमति देता है। सूँ ढ। इस तरह के आराम के दृष्टिकोण के लिए एक रिलीज के उम्मीदवार को बंद करने की आवश्यकता होती है और प्रकाशन से पहले एक पूर्ण क्यूए विश्लेषण के माध्यम से डाल दिया जाता है ...
    • ... मूल रूप से अस्थिर दर्शन में कहा गया है कि ट्रंक में इसकी स्थिरता की परवाह किए बिना नवीनतम कोड होना चाहिए, और यह कि रिलीज उम्मीदवारों को क्यूए के लिए बंद कर दिया जाना चाहिए।
       
       
      ... अधिक उदार भिन्नताएं प्रयोगात्मक कोड, रीफैक्टरिंग और अन्य विशेष-केस कोड के लिए भी शाखाएं देती हैं। ट्रंक में एक शाखा का विलय शाखा के प्रबंधकों द्वारा किया जाता है। ...
      • मेरे द्वारा की गई खोजों में से किसी में भी संसाधन से ऊपर नोट नहीं हुआ (CVS संबंधित दिशानिर्देश अब लोकप्रिय नहीं हैं?)
  • एससीएम (लेख मजबूरन) में सर्वोत्तम प्रथाओं पर
    http://www.perforce.com/perforce/papers/bestpractices.html
    ... एससीएम तैनाती के छह सामान्य क्षेत्रों, और कुछ मोटे-कणों का उन क्षेत्रों में से प्रत्येक के भीतर सर्वोत्तम प्रथाओं। निम्नलिखित अध्याय प्रत्येक आइटम की व्याख्या करते हैं ...
    कार्यक्षेत्र, कोडलाइन, शाखा, परिवर्तन प्रचार, निर्माण, प्रक्रिया ...


37
मुझे विश्वास है कि मैंने किसी भी स्टैकएक्सचेंज प्रश्न में सबसे लंबा उत्तर देखा है!
जॉन फिशर

2
@JohnFisher अच्छी तरह के अनुसार JIRA , वापस तो मैं 6 घंटे संकलन और इन संदर्भों :) का सारांश खर्च
कुटकी

2
आप किसी प्रकार के सारांश को याद कर रहे हैं, जो यह बताना चाहिए कि नई सुविधाओं के लिए नई शाखाओं का उपयोग करना है या नहीं। आपका उत्तर विभिन्न लेखों के लिंक का एक योग है - उनमें से कुछ एक बात बता रहे हैं, जबकि अन्य काफी विपरीत बता रहे हैं। आपका उत्तर काफी लंबा है, इसलिए मैं खो गया हूं।
B:овиЈ

3
@ B ofовиЈ सारांश उत्तर की शुरुआत में प्रदान किया जाता है: 'किसी भी परियोजना के लिए सामान्य रूप से सहमत "सर्वश्रेष्ठ" ब्रांचिंग रणनीति नहीं है। " * अधिकांश संसाधन इस बात से सहमत प्रतीत होते हैं कि उत्पादक रणनीति चुनना विशेष परियोजना बारीकियों पर निर्भर करता है '
gnat

2
पूरक रीडिंग: Google बनाम फेसबुक का ट्रंक आधारित विकास "वे [Google और Facebook] में मर्ज दर्द नहीं है, क्योंकि एक नियम के रूप में डेवलपर्स शाखाओं से / से विलय नहीं कर रहे हैं। कम से कम केंद्रीय रेपो के सर्वर पर वे काम नहीं कर रहे हैं।" , डेवलपर्स का स्थानीय शाखाओं से / में विलय हो सकता है , और जब कुछ ऐसा होता है, जो "सेंट्रल रिपो पर वापस होता है ..."
पुनर्जन्म

7

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

शाखाओं को प्राप्त करने का सबसे आसान तरीका है।

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


5

लेकिन हाल ही में मैंने शाखाओं को नहीं बनाने के लिए अधिक से अधिक विचार के अनुयायियों को देखा क्योंकि यह निरंतर एकीकरण, निरंतर वितरण आदि का अभ्यास करना अधिक कठिन बनाता है।

खैर यह निरंतर एकीकरण, निरंतर वितरण, आदि का अभ्यास करने के अधिक कठिन बना देता है आप के लिए वस्तुतः?

यदि नहीं, तो मुझे आपके काम करने के तरीके को बदलने का कोई कारण नहीं दिखता है।

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


बिलकुल यह करता है! यह प्राथमिकताओं का सवाल है: शाखाओं में बँटना (सुविधाएँ अलगाव) बनाम आसान एकीकरण, वितरण, इत्यादि
साइबेरियनगू

1
यह केवल CI टूल का उपयोग करने की बात है। आपको एक शाखा से बिल्ड और "लगातार वितरित" करने से क्या रोकता है?
Shaddix

@ शादिक्स, आमतौर पर शाखा से वितरित करना मुश्किल है। उदाहरण के लिए, आप सुविधा शाखा से कैसे वितरित करेंगे?
साइबेरियनगूई

1
क्या समस्या है, अगर आपके पास पूरा सोर्सकोड शाखित है (जैसे डीवीसीएस)?
शाडिक्स

1
@ शादिक्स, आपने जितना अधिक कोड शाखित किया है, विलय के दौरान आपको उतने ही अधिक संघर्ष होंगे
साइबेरियनगूई

4

क्या जवाब का एक दिलचस्प सेट। 20+ वर्षों में मैंने कभी भी ऐसी कंपनी में काम नहीं किया है जिसने ब्रांचिंग (आमतौर पर सिर्फ ब्रांच रिलीज के लिए) के एक तुच्छ उपयोग से अधिक बनाया है।

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

दूसरी ओर, मैंने git का अधिक उपयोग नहीं किया है और शायद यह git टैग का समावेश है जिसने इन उत्तरों को प्रभावित किया है - मैं समझता हूं कि शाखा / मर्ज git के साथ दिया गया है क्योंकि यह बहुत आसान है।


2
+1, ये git'er dunns अन्य संस्करण नियंत्रण / CI सेटअप पर गिट की श्रेष्ठ श्रेष्ठता के बारे में अधिक कट्टर होते जा रहे हैं।
maple_shaft

3

हां, आपको किसी भी (कम से कम मध्यम) विकास प्रयास को अलग करने के लिए शाखाओं का उपयोग करना चाहिए। देखें "आपको कब शाखा लगानी चाहिए? "

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


2

आपको शाखाओं का पूर्ण उपयोग करना चाहिए। उस के लिए कई ताकतें हैं।

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

बहुत कठिन कभी नहीं एक बहाना है। इसे हमेशा सही करने के लिए अधिक प्रयास करना चाहिए।


2
मैं इसे कम नहीं करना चाहता क्योंकि मैं शाखा के खिलाफ हूं लेकिन क्योंकि आप सुझाव देते हैं कि उनका उपयोग सभी समय के लिए किया जाना चाहिए।
maple_shaft

उन्होंने यह कहां कहा, क्या उन्होंने इसे संपादित किया या कुछ और।
b01

अपनी खुद की स्थानीय सीआई को अपनी शाखा को छोटी-छोटी शाखाओं (2-5 दिनों) के लिए देखने के लिए सेटअप करें, जो काफी उपरि हो सकती हैं। वहाँ किया गया कि
gnat

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

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

2

यदि दो टीमें अपनी शाखा पर काम करती हैं, तो वे दूसरी टीम के बदलाव नहीं देखेंगी, भले ही दोनों masterशाखा को एकीकृत करें । इसका मतलब है कि उनकी विकास शाखाएं अलग-अलग हो जाएंगी और यदि उनमें से एक टीम का विलय हो जाएगा master, तो दूसरी टीम को बहुत सारे बदलावों को फिर से करना होगा।

यहां तक ​​कि अगर आपके पास सुविधाओं के लिए शाखाएं हैं, तो मैं आपसे आग्रह करूंगा कि आप मास्टर शाखा में सभी रिफलेक्टरिंग के 'बैकपोर्ट' बनाएं और शाखा को केवल नई सुविधाओं के लिए रखें।

  • बैकपोर्ट रिफलेक्टरिंग

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

  • सुविधा स्विच का उपयोग करें

2

हम सिर्फ इस (फिर से) के माध्यम से गए हैं .. पहले हमारे पास पूरी जीआईटी / एसवीएन बहस थी, जिसने हमें आम तौर पर शाखाओं की रणनीतियों में ले लिया।

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

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

यह वाक्य आपके जीवन को बचा सकता है: SCM में जो है वह वैसा नहीं है जैसा कि आपकी निर्मित कलाकृतियों में है!

अगर आपको शाखा लगाने में परेशानी हो रही है, क्योंकि आप अपने SCM का दुरुपयोग कर रहे हैं। हम सभी इसे सालों से कर रहे हैं। आपके पास एक प्रणाली है जहां SCM का उपयोग यह निर्धारित करने के लिए किया जा रहा है कि आपके अंतिम बिल्ड में क्या जाता है।

यह SCM का काम नहीं है। SCM एक गौरवशाली फ़ाइल सर्वर है। यह निर्धारित करने का काम कि आपकी SCM की कौन सी फाइलें आपके बिल्ड में जाती हैं, आपके बिल्ड टूलिंग से संबंधित हैं।

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

इस बारे में बहुत रोना और हाथ मिलाना होगा। क्या iffery, और सामान्य howling। इस तरह की भावना का स्तर एक फाइल रिपॉजिटरी के रूप में कुछ के रूप में सरल है, चाहे कितना भी चालाक हो।

लेकिन आपका जवाब है।


1

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

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


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

1
@ b01, उस पर बहुत ज्यादा स्पॉट। कोई भी सही डिजाइन के साथ नहीं आ सकता है जब आवश्यकताएं आगे और पीछे जाती हैं और दरार पर एडीएचडी बच्चे की तुलना में तेजी से बदलती हैं। अन्य बार जब आप डिजाइन को बेहतर बनाने के लिए विरासत कोड को रिफलेक्टर करने की कोशिश करते हैं और यह स्थिति समय-समय पर सामने आती रहती है। यह एक टीम की सबसे खराब समस्या नहीं है, और कुछ जगहों पर मैंने जितना अच्छा काम किया है, उससे कहीं ज्यादा बेहतर रोना है जहाँ एक बैठक में भी सुझाव देने से आपको अछूतों के दृश्य की तरह बेसबॉल के बल्ले से मौत के घाट उतार दिया जाएगा।
maple_shaft

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

@ पाओल, मुझ पर भरोसा करो जो सभी परियोजनाओं या प्रौद्योगिकियों के लिए काम नहीं करता है। स्ट्रेट्स की तरह एक सामान्य XML कॉन्फ़िगरेशन फ़ाइल के बारे में सोचें, जहाँ हर कोई हर रोज़ इसमें अपना हाथ डुबो रहा हो। लेकिन नहीं, आपका तरीका हर समय काम करता है और मैं पूरी तरह से नीच का पात्र हूं। धन्यवाद।
मेपल_शफ्ट

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

1

मैं इस तरह की शाखा योजना की सिफारिश करता हूं:

रिहाई - परीक्षण - विकास

फिर विकास से, डेवलपर द्वारा शाखा और / या सुविधा द्वारा।

प्रत्येक डेवलपर्स के पास खेलने के लिए एक शाखा होती है, और इससे विलय होता है, और फिर विकास शाखा में नियमित रूप से - आदर्श रूप से हर दिन (यह संकलन प्रदान करता है)।

इस तरह की योजना बहुत सारे डेवलपर्स और एक ही कोडबेस पर कई परियोजनाओं के साथ वास्तव में अच्छी तरह से काम करती है।


0

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

IMHO, तो जवाब है, हाँ । हमें अभी भी ब्रांचिंग का उपयोग करना चाहिए।


0

मेरे संगठन की प्रक्रिया शाखाओं का व्यापक उपयोग करती है और (एक प्रक्रिया जो थोड़ी सी लगती है) निरंतर एकीकरण।

उच्च स्तर के दृश्य में, डेवलपर्स मेनलाइन के साथ विलय के बारे में बहुत चिंता नहीं करते हैं, वे सिर्फ शाखा के लिए प्रतिबद्ध हैं। a (अर्ध-) स्वचालित प्रक्रिया यह जांचती है कि मेनलाइन में जाने के लिए कौन-कौन सी सुविधाएँ निर्धारित हैं, उन शाखाओं को मर्ज करता है और उत्पाद बनाता है। प्रक्रिया काम करती है क्योंकि हम वास्तव में इश्यू ट्रैकर से विलय की इस प्रक्रिया को एकीकृत करते हैं, ताकि बिल्ड टूल को पता हो कि किस शाखा को विलय करना है।


यह प्रक्रिया ऐसा लगता है कि यह टूट जाएगा यदि किसी डेवलपर ने एक शाखा पर कुछ preexisting कोड को पुनःप्राप्त किया है, और एक अलग शाखा पर एक डेवलपर ने कुछ लिखा है जो कोड के पुराने संस्करण पर निर्भर करता है।
बीडीएस

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

हां लेकिन यह बहुत कम संभावना है कि यदि रिफैक्टिंग को उसी दिन मेनलाइन में मिला दिया जाए जो कि एक नई सुविधा के तैयार होने तक इंतजार करने के बजाय किया गया था।
bdsl

@ बीडीएसएल हमेशा एक विकल्प नहीं है; आपको हर समय "अच्छे, काम करने वाली शाखा" की आवश्यकता हो सकती है, उदाहरण के लिए आपातकालीन बग फिक्स को जहाज करने के लिए। वैकल्पिक तकनीक, एक नियमित आधार पर सुविधा में मेनलाइन का विलय, आमतौर पर ए-ओके है, और मेरी मजबूत सिफारिश कोई फर्क नहीं पड़ता कि आपकी शाखा रणनीति क्या है।
21
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.