Git Merge और Git Rebase का परिचय: उनका उपयोग क्यों और कब करें

अक्सर, डेवलपर्स के पास मर्ज (मर्ज) और रेबेस (स्थानांतरण) के बीच एक विकल्प होता है। Google में आपको एक अलग राय दिखाई देगी, कई को सलाह दी जाती है कि वे Rebase का उपयोग न करें, क्योंकि इससे गंभीर समस्याएं हो सकती हैं। लेख में, मैं समझाऊंगा कि विलय और गति क्या हैं, आपको उनका उपयोग क्यों करना चाहिए (या नहीं करना चाहिए) और यह कैसे करना है।



Git Merge और Git Rebase एक ही लक्ष्य साझा करते हैं। वे एक शाखा से दूसरी शाखा में परिवर्तन को एकीकृत करने के लिए डिज़ाइन किए गए हैं। यद्यपि अंतिम लक्ष्य समान है, संचालन के सिद्धांत अलग हैं।

कुछ लोग सोचते हैं कि आपको हमेशा रिबेस का उपयोग करना चाहिए, अन्य लोग मर्ज पसंद करते हैं। यह इसके पेशेवरों और विपक्ष है।

गित मर्ज

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

पेशेवरों:

• सादगी;
• पूरा इतिहास और कालानुक्रमिक क्रम बरकरार रखता है;
• एक शाखा संदर्भ रखता है।

विपक्ष:

• कई आवागमन के साथ आवागमन का इतिहास (प्रदूषित) किया जा सकता है;
• डिबगिंग का उपयोग करके गिट बिटकिट प्राप्त कर सकते हैं।

कैसे करना है?

चेकआउट का उपयोग करके मास्टर शाखा को सुविधा शाखा में मर्ज करें और कमांड का विलय करें।

$ git checkout feature $ git merge master (or) $ git merge master feature 

यह फीचर शाखा में एक नया "मर्ज कमिट" बनाएगा, जिसमें दोनों शाखाओं का इतिहास होगा।

रीट रिसेट करें

रिबेस एक शाखा से दूसरी शाखा में बदलाव को आगे बढ़ाने का एक और तरीका है। रीबेस सभी परिवर्तनों को एक पैच में संपीड़ित करता है। फिर यह पैच को लक्ष्य शाखा में एकीकृत करता है।

विलय के विपरीत, चलती इतिहास को अधिलेखित कर देता है क्योंकि यह स्थानांतरण एक शाखा से दूसरे में काम पूरा करता है। प्रक्रिया अवांछित कहानी को समाप्त करती है।



पेशेवरों:

• एक संभावित जटिल कहानी को सरल करता है
• एकल प्रतिबद्धताओं के साथ जोड़तोड़ का सरलीकरण
• व्यस्त रिपोजिटरी और शाखाओं में विलय से बचना
• मध्यवर्ती कमिट को साफ करता है, जिससे उन्हें एक ही प्रतिबद्ध किया जाता है, जो कि DevOps कमांड के लिए उपयोगी है

विपक्ष:

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

यदि आप गलत तरीके से कदम बढ़ाते हैं, तो कहानी बदल जाएगी, और इससे गंभीर समस्याएं हो सकती हैं, इसलिए सुनिश्चित करें कि आप करते हैं!

कैसे करना है?

निम्न आदेशों का उपयोग करके मुख्य शाखा में सुविधा शाखा को स्थानांतरित करें।

 $ git checkout feature $ git rebase master 

यह संपूर्ण फ़ंक्शन शाखा को मुख्य शाखा में ले जाता है। परियोजना का इतिहास बदल रहा है, मुख्य शाखा में प्रत्येक समिति के लिए नए कमिट बनाए जाते हैं।

इंटरएक्टिव आंदोलन

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

 $ git checkout feature $ git rebase -i master 

यह संपादक को खोल देगा, सभी कमिटों को सूचीबद्ध करेगा जिन्हें स्थानांतरित किया जाएगा।

 pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3 

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

कौन सा उपयोग करना है?

तो क्या बेहतर है? विशेषज्ञ क्या सलाह देते हैं?

एकमात्र सही निर्णय करना मुश्किल है, जिसके बारे में उपयोग करना बेहतर है, क्योंकि सभी टीमें अलग हैं। यह सब टीम के भीतर की जरूरतों और परंपराओं पर निर्भर करता है।

Git में टीम की योग्यता के आधार पर निर्णय लें। क्या सादगी या पुनर्लेखन इतिहास आपके लिए महत्वपूर्ण है, या शायद कुछ और?

मैं क्या सुझाऊँ?

जैसे-जैसे टीम बढ़ती है, विलय का उपयोग करके विकास परिवर्तनों को प्रबंधित या ट्रैक करना मुश्किल हो जाता है। एक साफ और समझने योग्य प्रतिबद्ध इतिहास के लिए, रेबेस का उपयोग करना बुद्धिमान है।

रिबेस के लाभ:

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

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

मत भूलो:

 code = coffee + developer