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