रिलीज में परिवर्तन मर्ज व्यवहार 1.7.10

रिलीज़ कैलेंडर के अनुसार , केवल कुछ ही हफ्तों का समय बचा है, जब तक कि अगले git रिलीज़ की सुविधाओं की सूची जमी नहीं है (1.7.10), जिसमें git मर्ज के काम में सुधार शामिल होगा, जो पिछड़ी संगतता का उल्लंघन करता है और अपनी स्क्रिप्ट में मर्ज का उपयोग करने वालों को खतरे में डालता है।
हमने जेक एज की सलाह का पालन करने का फैसला किया: “अधिकांश मुफ्त परियोजनाएं उनके कार्यान्वयन से पहले नियोजित परिवर्तनों पर चर्चा करती हैं और उपयोगकर्ताओं को रिलीज से पहले नई सुविधाओं का परीक्षण करने का अवसर देती हैं। इस स्तर पर परियोजना के लिए सबसे अच्छी मदद स्पष्ट रूप से पुष्टि की गई है, मौजूदा समस्याओं का विशिष्ट विवरण, लापता कार्यक्षमता, आदि, और संदेशों की एक अंतहीन धारा नहीं "प्रोजेक्ट XYZ अगस्त !!! 11" मेलिंग सूचियों या टिप्पणियों में "

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


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

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

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

हम कुछ अनुशंसाएँ देना चाहते हैं जो हमारे उपयोगकर्ताओं को इस परिवर्तन की आदत डालने में मदद कर सकती हैं:

(1) जब git मर्ज को कमांड लाइन से लॉन्च किया जाता है, तो दो विकल्प संभव हैं:
- आप अपडेट की गई शाखा को उस शाखा में डालते हैं जिसमें आप नई कार्यक्षमता (विषय शाखा) पर काम कर रहे हैं। बिना किसी वास्तविक कारण के ऐसा विलय बुरा व्यवहार है। "गलत" दिशा में ऐसा विलय केवल तभी किया जाना चाहिए जब उदाहरण के लिए, यदि आपकी नई कार्यक्षमता हाल ही में अपस्ट्रीम में अपनाई गई सुधार पर निर्भर हो। अन्यथा, आपकी शाखा कार्यक्षमता की एक इकाई से संबंधित कमिट्स रखना बंद कर देती है, और, इसके बजाय, विभिन्न स्रोतों से कमिट्स का एक डंप बन जाता है। इस मामले में, नया गिट मर्ज व्यवहार आपके पक्ष में है, जैसा कि कारणों का पता लगाने के लिए अब संशोधन नहीं करना होगा।
- जब एक शाखा को एक एकीकरण शाखा (या परीक्षण शाखा) में नई कार्यक्षमता के साथ इंजेक्ट किया जाता है, तो विलय का कारण आमतौर पर संदर्भ से स्पष्ट होता है - आप परियोजना में तैयार कार्यक्षमता डालते हैं। इस स्थिति में, आप --no-edit पैरामीटर को git-merge कॉल में पास कर सकते हैं और बिना संपादित किए तैयार संदेश को स्वीकार कर सकते हैं

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

रिलीज से पहले 1.7.10 का प्रयास करें और अपनी लिपियों और आदतों को अनुकूलित करें :)
यदि आप के बारे में कोई इच्छा है:
- प्रलेखन
- त्रुटियों, सिफारिशों और अन्य संदेश
- इंटरैक्टिव लॉन्च का निर्धारण करने के लिए तर्क
हम हमेशा git@vger.kernel.org मेलिंग सूची में आपसे सुनकर खुश हैं

संवादात्मक विलय के दौरान संपादक को लॉन्च करने के तथ्य की चर्चा नहीं की गई है। जैसा कि लिनुस ने कहा है - डिफ़ॉल्ट मायने रखता है - और इससे पहले कैसे व्यवहार किया गया विलय वास्तव में "डिफ़ॉल्ट" था

इस समाचार को अपने वातावरण में उपयोगकर्ताओं को लाएँ ताकि वे अपनी आदतों को बदलना शुरू कर सकें।