GitHub प्रवाह में, किसी अन्य सुविधा शाखा पर सुविधा शाखा को आधार देना ठीक है?

Question

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

हालाँकि, मेरा वर्तमान कार्य एक अन्य मुद्दे पर निर्भर करता है जिसमें काम किया जा रहा है feature-branch-A। क्या यह उस दूसरी शाखा से मेरी शाखा बनाने के लिए कोषेर है या कि गीथहब फ्लो की भावना के खिलाफ है?

इसका विकल्प यह होगा कि मैं अपनी शाखा को मास्टर पर आधारित करूं और feature-branch-A(अक्सर) से होने वाले परिवर्तनों में विलय करूँ ।

GitHub प्रवाह में कौन सा विकल्प पसंद किया जाता है?

Answer 1

यहाँ है कि मैं एक सुविधा शाखा से शाखा जब कार्यप्रवाह का पालन करें:

1. बनाएं feature-branch-Bसेfeature-branch-A
2. पर काम feature-branch-B
3. यदि feature-branch-Aब्रांचिंग के बाद और कमिट जोड़े जाते हैं , तो रिबास feature-branch-Bपरfeature-branch-A
4. काम समाप्त करें feature-branch-Bऔर तब तक प्रतीक्षा करें जब तक feature-branch-Aकि विलय न हो जाए master।
5. feature-branch-Aमर्ज किए जाने के बाद master, feature-branch-Bपर रिबास करेंmaster
6. मर्ज feature-branch-Bमेंmaster

उपरोक्त वर्कफ़्लो का अनुसरण करके यह दिखाई देगा कि आप विलय होने के masterबाद feature-branch-Aसे शाखाबद्ध हैं। feature-branch-Aकाम शुरू करने के लिए विलय होने तक आपको इंतजार नहीं करना होगा feature-branch-B। फिर भी, आपको बिना किसी जटिल पेड़ के एक साफ इतिहास मिलेगा।

Comments

यह वही उत्तर था जिसकी मुझे तलाश थी! आपने मुझे उस छँटाई के सिरदर्द से बचाया, धन्यवाद!

— वंस पलैसियो

पहले से ही प्रकाशित करता rebase मत करो ... daolf.com/posts/git-series-part-2

— Sebi2020

Answer 2

मुझे लगता है कि यह पूरी तरह से ठीक है यदि आप किसी अन्य सुविधा पर सुविधा बनाते हैं।

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

Answer 3

एक महत्वपूर्ण बात जो git-flow को संबोधित करने के लिए बनाई गई थी, वह किसी दिए गए शाखा की भूमिका के बारे में तर्क करने की क्षमता थी, और यह किस शाखा से आती और विलीन होती है।

आदर्श रूप से, सभी शाखाएं उस कोडलाइन में वापस आ जाती हैं, जिनसे उन्हें विलय किया गया था। यह आमतौर पर मेनलाइन से एक मर्ज होता है (git-flow में यह dev)। शाखा शाखाएं और देव से विलय, शाखाएं छोड़ें शाखा और देव से विलय (एक अतिरिक्त विलय के साथ master)। हॉट फ़िक्सेस शाखा और मास्टर से मर्ज (उस अतिरिक्त मर्ज वापस देव के लिए)।

प्रत्येक कोडलाइन शाखा से वापस अपने माता-पिता में विलीन हो जाती है। एक codeline सकता है किसी भी समय अन्य codelines से कोड में खींच अगर यह आवश्यक है।

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

1. सुविधा से शाखा
2. विचार का पता लगाएं
3. सुविधा के लिए मर्ज

हालांकि आप जो बचना चाहते हैं वह कुछ ऐसा है जो दिखता है:

1. आवश्यक-सुविधा से शाखा
2. कोड पर काम करते हैं
3. एक बार आवश्यक-सुविधा पूर्ण होने के बाद देव से विलय करें
4. सुविधा शाखा में कार्यक्षमता (और अतिरिक्त कमिट) सत्यापित करें
5. देव में विलय

कारण यह है कि शुरुआत और अंत मेल नहीं खाते हैं - यह यह समझना थोड़ा कठिन है कि यह क्या है और क्या है। असंभव नहीं है, लेकिन यह सिर्फ किसी को अपनी भूमिका को समझने में थोड़ा अधिक समय लेता है।

हालाँकि, यदि यह नई सुविधा है जो कोड पर निर्भर करती है जो अभी तक देव में नहीं मिली है, तो प्रवाह होना चाहिए:

1. देव से शाखा
2. आवश्यक-सुविधा से मर्ज करें
3. कोड पर काम करते हैं
4. एक बार आवश्यक-सुविधा पूर्ण होने के बाद देव से विलय करें
5. सुविधा शाखा में कार्यक्षमता (और अतिरिक्त कमिट) सत्यापित करें
6. देव में विलय

ध्यान दें कि यह देव से एक शाखा से शुरू होता है और देव में एक मर्ज के साथ समाप्त होता है।

सभी ने कहा, शायद सबसे अच्छी बात यह है कि एक फीचर से दूसरे फीचर में मर्ज करने से बचें। सुविधा को शाखा दें, जो कुछ भी आवश्यक हो उसे करें ... और प्रतीक्षा करें।

1. देव से शाखा
2. कोड पर काम करते हैं
3. एक बार आवश्यक-सुविधा पूर्ण होने के बाद देव से विलय करें
4. सुविधा शाखा में कार्यक्षमता (और अतिरिक्त कमिट) सत्यापित करें
5. देव में विलय

यह शाखाओं और कोड का सबसे स्थिर सेट प्रदान करता है।

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

Comments

आपके तीसरे चरण में, नकारात्मक पक्ष यह है कि चरण 1 में कुछ "डमी कमिट" शामिल करने की आवश्यकता है। मेरी स्थिति में, जब तक required-featureविलय नहीं हो जाता, तब तक मेरे पास कुछ भी उपयोगी नहीं है ।

— बोरक बर्नार्ड

मैं अभी भी इसे ब्रांचिंग पर अपने पसंदीदा लेखों में से एक के रूप में इंगित करता हूं: उन्नत एससीएम ब्रांचिंग रणनीतियाँ । हालांकि यह एक केंद्रीकृत संस्करण नियंत्रण प्रणाली पर केंद्रित है, भूमिकाओं के विचारों को यह बिल्कुल गिट-फ्लो के लिए प्रस्तुत करता है ।

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

आश्चर्य है कि आपके कदमों का दूसरा सेट कितना खराब है। क्या यह व्यवहार में एक समस्या है कि एक शाखा में "समान" शुरू और अंत नहीं है? मुझे नहीं लगता कि यह मुझे बहुत परेशान करेगा लेकिन शायद यह एक प्रमुख गड़बड़ कारक है?

— बोरिक बर्नार्ड

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

Answer 4

एक सुविधा शाखा को आमतौर पर ट्रंक (विकसित / मास्टर) की तुलना में कम स्थिर माना जाता है, इसलिए यदि आप अपने काम को आधार बनाते हैं तो संभवतः आप सामान्य से अधिक अंतर्निहित परिवर्तनों के अधीन होते हैं।

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

उस ने कहा, इसके खिलाफ कोई सख्त नियम नहीं है। ये केवल पैटर्न और सर्वोत्तम अभ्यास हैं।

संपादित करें: अपने प्रश्न का हिस्सा याद किया। फीचर ब्रांच को अपने आप में मर्ज करना, जो मास्टर ऑफ पर आधारित है, वास्तव में ऊपर बताई गई किसी भी समस्या से नहीं बचता है, और वास्तव में एक और भी अधिक जटिल इतिहास बना सकता है।

इस प्रकार अगर मैं आपके जूतों में होता और मैं तब तक काम को टाल सकता था जब तक कि सुविधा नहीं हो जाती, या पहले कुछ और करना, मैं ऐसा कर सकता था।