क्या "अक्सर" या केवल पूर्ण होने के बाद फीचर शाखाओं का एक बड़ा विलय करना बेहतर है?

40

मान लें कि कई शाखाएँ विकसित की जा रही हैं, Aऔर Bसाथ ही एक वृद्धिशील "बग फिक्स" शाखा भी C।

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

क्या Cनई सुविधा शाखाओं में जल्द से जल्द विलय करना एक अच्छा विचार है ? ताकि नई सुविधाएँ यथासंभव समीप रहें master? या यह बेहतर है कि नई सुविधा को अपनी "दुनिया" में विकसित किया जाए, केवल एक बार मास्टर में विलय कर लेने के बाद वे समाप्त हो जाते हैं?

किसी भी तरह से संघर्ष होगा, इसलिए उन्हें ठीक करने पर समय व्यतीत करने की आवश्यकता है।

version-control branching merging

— paul23
स्रोत

2

संभावित शाखाओं को मेन लाइन में विलय करने के लिए एक अच्छी आवृत्ति क्या है?

— १२:४४ पर gnat

5

@gnat एक मुख्य लाइन में सुविधाओं की शाखाओं के विलय के बारे में है, मैं सोच रहा हूँ कि फीचर को विकसित करते समय मुख्य बैक को विलय कर दिया जाए, तो "संघर्षों को जल्दी हल करने" के लिए अच्छा है।

— पौल

1

@ paul23, मैं कहूंगा कि यह एक व्यावहारिक आवश्यकता है।

— बेरिन लोरिट्श

3

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

— टी। सार -

2

आप नियमित रूप से "पर्याप्त" पास रहने के लिए मास्टर से मर्ज करना चाह सकते हैं ताकि बाद में बहुत दर्दनाक न हो।

— थोरबजोरन रावन एंडरसन

71

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

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

किसी भी तरह से संघर्ष होगा, इसलिए उन्हें ठीक करने पर समय व्यतीत करने की आवश्यकता है।

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

— mmathis
स्रोत

33

मर्ज या रिबास , चूंकि रिबासिंग अक्सर एक क्लीनर कमिट इतिहास का निर्माण करता है।

— क्राइसिस -ऑन स्ट्राइक-

11

@chrylis: रिबासिंग खतरनाक हो सकती है यदि "शाखाएं म्यूटेलर स्टोरीज को कवर करती हैं" का अर्थ यह लिया जाता है कि दो डेवलपर्स एक ही शाखा पर काम करते हैं।

— मेरिटॉन - हड़ताल पर

9

@ डॉमिटॉन ऑफिशियल डॉक्स से: अपने रिपॉजिटरी के बाहर मौजूद कामों को दोबारा न करें और उन पर लोगों का काम हो सकता है। यदि आप उस दिशानिर्देश का पालन करते हैं, तो आप ठीक हो जाएंगे। यदि आप नहीं करते हैं, तो लोग आपसे घृणा करेंगे, और आप दोस्तों और परिवार के लोगों से डरेंगे। LOL

— Xtreme बाइकर

6

@XtremeBiker: Git में एक रिबास इतिहास को बदलता है। Git इस संबंध में वास्तविक जीवन की तरह काम करता है: इतिहास को बदलने के लिए, आपको एक साजिश की आवश्यकता है। Git के लिए रिपॉजिटरी में एक शाखा है जो नियमित रूप से विद्रोह करती है, और यह एक अत्यधिक सार्वजनिक है। यह काम करने का कारण यह है कि एक साजिश है: इस शाखा का उपयोग करने वाला हर व्यक्ति निश्चित समय पर इतिहास को फिर से लिखने के लिए सहमत होता है, इसलिए वे यह सुनिश्चित करेंगे कि वे उस समय तक सब कुछ विलय करने की स्थिति में हैं।

— जोर्ज डब्ल्यू मित्तग

1

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

— सिनुक

11

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

मैं निम्नलिखित के समान रणनीतियों पर विचार करूंगा

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

— kenchew
स्रोत

5

आमतौर पर अक्सर एक विशाल से बेहतर होता है।

छोटे, अधिक लगातार, पुल अनुरोध लगभग हमेशा बेहतर होते हैं।

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

कॉन्फ़िगरेशन ध्वज बनाने में अतिरिक्त ओवरहेड है, इसलिए यह छोटी सुविधाओं पर इसके लायक नहीं है। लेकिन फिर भी आपका पुल अनुरोध छोटा होगा।

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

मेरे अधिकांश साथी कराहते हैं जब कोई बड़े पैमाने पर पुल का अनुरोध करता है, और अधिकांश भाग के लिए, ठीक है।

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

— मार्क रोजर्स
स्रोत

1

फ़ीचर फ्लैग महंगा हो सकता है (45 मिनट में 450 मिलियन अमरीकी डालर)। इस उदाहरण का उल्लेख अंकल बॉब ने भी किया है (लेकिन बिना किसी तकनीकी जानकारी के (जैसा कि कोई उम्मीद करेगा))।

— पीटर मोर्टेंसन

1

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

— मार्क रोजर्स

3

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

— JohnnyApplesauce
स्रोत

2

अच्छी तरह से Aऔर Bप्रमुख कट्टरपंथी नए ओवरहाल को पकड़ें कि आवेदन कैसे काम करता है, वे एक महीने के भीतर "नहीं" हो जाते हैं। लेकिन वे भी बेकार हैं इससे पहले कि वे कर रहे हैं ...

— paul23

8

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

— bdsl

1

यही कारण है कि मास्टर शाखा में किसी भी परिवर्तन के शीर्ष पर अपने स्थानीय को फिर से विकसित करना दीर्घकालिक विकास के लिए आसान है। अपने काम करता रहता है जैसे कि यह सिर्फ नवीनतम बंद branched था

— NKCampbell

2

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

— Qwertie
स्रोत

1

फ़ीचर झंडे = ज़ोंबी कोड (पुनर्जीवित होने तक)?

— पीटर मोर्टेंसन

@PeterMortensen वैसे आपको जल्द से जल्द झंडे हटाने का लक्ष्य रखना होगा लेकिन यह कुछ स्थितियों के लिए काम कर सकता है

— Qwertie

3

@PeterMortensen अगर झंडा कम से कम एक व्यक्ति के लिए चालू नहीं है

— इयान