GIT उपयोगकर्ता अपने कमिट को क्यों संपादित करते हैं

रेडियो-टी के अंतिम दो मुद्दों में, प्रस्तुतकर्ताओं ने जीआईटी पर चर्चा करने की कोशिश की। यूजीन (@Umputun) को आश्चर्य हुआ कि रिबेज की आवश्यकता क्यों है और जब मैंने पूछा कि क्या वह संपादन कर रहा है तो मुझे बहुत आश्चर्य हुआ। मेरी राय में, GIT को समझने के लिए, यह लिनक्स कर्नेल विकास प्रक्रिया में तल्लीन करने के लिए पर्याप्त है, क्योंकि यह सिर्फ इसके लिए बनाया गया था।

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

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

सबसे अधिक बार मैं एक नया ब्रंच बनाता हूं, सभी कमिट्स (गिट रीसेट) को रोल करता हूं और जीआईटी कमिट - एक्टिव के साथ ब्रेकडाउन शुरू करता हूं। यह आदेश आपको यह चुनने की अनुमति देता है कि कौन से परिवर्तन किस प्रतिबद्धता पर जाते हैं। जब सब कुछ तैयार हो जाता है, तो गिट फॉर्मेट-पैच कमांड का उपयोग करके पैच का गठन किया जा सकता है और उन्हें git send-email का उपयोग करके भेज सकते हैं।

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

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

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