Git: बग्स को ठीक करना और कमिट करना

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


यह माना जाता है कि इस लेख का पाठक पहले से ही गिट की मूल बातें से परिचित है। यदि ऐसा नहीं है, तो सबसे पहले आधार को मास्टर करने की सिफारिश की जाती है, उदाहरण के लिए, इस सामग्री का उपयोग करना।

आवागमन में कीड़े ठीक करें

यहां हम कमिट्स में त्रुटियों और उनके सुधार के लिए कई परिदृश्यों को देखेंगे।

▍ परिदृश्य संख्या 1

मान लीजिए कि आपने बहुत सी फाइलें कीं और महसूस किया कि प्रतिबद्ध संदेश बहुत स्पष्ट नहीं था। उसके बाद, आपने इस संदेश को बदलने का फैसला किया। ऐसा करने के लिए, git commit --amend उपयोग करें। यहाँ इसके आवेदन का एक उदाहरण है:

 git commit --amend -m "New commit message" 

▍ परिदृश्य संख्या 2

मान लीजिए कि आप छह फाइलें बनाना चाहते हैं, लेकिन गलती से केवल पांच ही प्रतिबद्ध हैं। ऐसा लगता है कि आप इस त्रुटि को ठीक कर सकते हैं एक नई कमिट बनाकर और उसमें छठी फाइल को जोड़कर।

इस दृष्टिकोण को जीवन का अधिकार है। लेकिन प्रतिबद्ध इतिहास को अच्छी स्थिति में रखने के लिए, यह संभवतः बेहतर होगा कि एक ही प्रतिबद्ध में बेतरतीब ढंग से छोड़ दी गई फ़ाइल को जोड़ने में सक्षम हो। यह किया जा सकता है, फिर से, git commit --amend । इसका उपयोग इस तरह दिखता है:

 git add file6 git commit --amend --no-edit 

--no-edit फ्लैग का मतलब है कि कमिट मैसेज नहीं बदलता है।

▍ परिदृश्य संख्या 3

Git में आने वाले कमिट्स लेखक के नाम और उसके ईमेल पते से जुड़े होते हैं। आमतौर पर, यह डेटा Git के प्रारंभिक कॉन्फ़िगरेशन को प्रदर्शित करके इंगित किया जाता है। परिणामस्वरूप, जो लोग Git का उपयोग करते हैं, वे प्रत्येक प्रतिबद्ध को क्रियान्वित करते समय, उसके लेखक के बारे में जानकारी की परवाह नहीं कर सकते हैं।

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

 git config user.email "your email id" 

मान लीजिए कि आप यह सेटअप करना भूल गए हैं और पहले से ही पहला काम कर चुके हैं। सही स्थिति पहले से ही हमें टीम amend से परिचित amend । इसका उपयोग करके, आप पिछले प्रतिबद्ध के लेखक के बारे में जानकारी बदल सकते हैं:

 git commit --amend --author "Author Name <Author Email>" 

▍ नोट

केवल अपने स्थानीय भंडार में amend आदेश का उपयोग करें। दूरस्थ रिपोजिटरी में इसके उपयोग से भारी भ्रम हो सकता है।

आदेशों के इतिहास में आदेश डालना

मान लीजिए कि आप किसी प्रोजेक्ट के लिए कोड के एक टुकड़े पर काम कर रहे हैं। आप जानते हैं कि इसमें लगभग दस दिन लगेंगे। इन दस दिनों के दौरान, अन्य डेवलपर्स स्रोत भंडार के लिए प्रतिबद्ध हैं।

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

हर बार जब आप रिमोट से स्थानीय रिपॉजिटरी में कोड डाउनलोड करते हैं, तो स्थानीय रिपॉजिटरी में एक नया मर्ज कमिट बनाया जाता है। इसका मतलब है कि आपके स्थानीय प्रतिबद्ध इतिहास में कई ऐसे कमिट होंगे जो आपके कोड को देखने वाले को भ्रमित कर सकते हैं।


स्थानीय भंडार में आने का इतिहास

कैसे प्रतिबद्ध इतिहास को साफ करने के लिए? इस समस्या को हल करने के लिए, आप git rebase उपयोग कर सकते हैं।

▍Git रीबेज कमांड

उदाहरण के तौर पर git rebase पर विचार करें।


रिलीज़ शाखा और फ़ीचर शाखा में संचार करता है

Release शाखा में तीन कमिट हैं: Rcommit1 , Rcommit2 , और Rcommit3 । आपने अपनी Feature शाखा Release शाखा से बनाई थी जब उसमें केवल एक ही कमिट था - Rcommit1 । उसके बाद, आपने Feature ब्रांच में दो कमिट्स जोड़े। ये Fcommit1 और Fcommit2 । आपका लक्ष्य Release शाखा से अपनी Feature शाखा में अपलोड करना है। ऐसा करने के लिए, आप rebase कमांड का उपयोग करने जा रहे हैं।

हम विचाराधीन दो शाखाओं के लिए नाम release और feature उपयोग करेंगे।

परिणामस्वरूप, rebase का उपयोग इस तरह होगा:

 git checkout feature git rebase release 

Command रिबेस कमांड की विशेषताएं

rebase कमांड rebase उपयोग यह सुनिश्चित करने के लिए किया जाता है कि Feature शाखा में Release शाखा से ताज़ा कोड है।

इस आदेश को लागू करते समय, सिस्टम प्रत्येक शाखा को Feature शाखा में जोड़ने का प्रयास करता है, एक बार में, और संघर्षों की जाँच करता है। यदि यह जटिल लगता है, तो निम्नलिखित आकृति को देखें। यह rebase के आंतरिक तंत्र को दर्शाता है।


फ़ीचर शाखा और रिबेस कमांड के तीन चरण

चरण 1

जब कमांड को बुलाया जाता है, तो Feature शाखा Feature शाखा के प्रमुख की ओर इशारा करती है। उसके बाद, Feature शाखा में तीन कमिट हैं: Rcommit1 , Rcommit2 , और Rcommit3 । शायद यहां आपके सामने एक सवाल होगा कि Fcommit1 और Fcommit2 साथ क्या हुआ। ये कमिट दूर नहीं गए हैं, अगले चरणों में इनका उपयोग किया जाएगा।

चरण 2

Git अब Fcommit1 कमिट को Feature शाखा में जोड़ने का प्रयास कर रहा है। यदि कोई विरोध नहीं है, तो Fcommit1 Rcommit3 बाद जोड़ा गया है। यदि कोई विरोधाभास पाया जाता है, तो गिट इसे रिपोर्ट करेगा और आपको इस संघर्ष को मैन्युअल रूप से हल करना होगा।

चरण 3

Fcommit1 Feature ब्रांच में शामिल किए जाने के बाद, Git वहाँ Fcommit2 को जोड़ने की कोशिश करता Fcommit2 । यहां, फिर से, यदि कोई संघर्ष नहीं है, तो Fcommit2 बाद Fcommit1 जोड़ा Fcommit1 और ऑपरेशन सफलतापूर्वक पूरा होता है। यदि एक संघर्ष का पता चला है, तो Git, पहले की तरह, यह रिपोर्ट करेगा और इससे निपटने की पेशकश करेगा।

Rcommit1 कमांड rebase होने के बाद rebase आप देख सकते हैं कि Feature ब्रांच में Rcommit1 , Rcommit2 , Rcommit3 , Fcommit1 और Fcommit2 ।

▍ नोट

गिट के साथ काम करते समय, merge कमांड और rebase कमांड दोनों का rebase । यह कहना नहीं है कि उनमें से एक दूसरे के लिए बेहतर है।

यदि आप merge कमांड का उपयोग करते हैं, तो आप merge कमिट प्राप्त करेंगे। यदि आप rebase उपयोग करते हैं, तो आपके पास कोई अतिरिक्त rebase नहीं होगा।

यह अनुशंसा की जाती है कि आप विभिन्न स्थितियों में इन आदेशों का उपयोग करें। इसलिए, rebase दूरस्थ रिपॉजिटरी से नवीनतम कोड के आधार पर स्थानीय रिपोजिटरी कोड को अपडेट करने के लिए उपयुक्त है। Release या Master शाखा के साथ Feature शाखा को मर्ज करने के लिए पुल अनुरोध करने के लिए merge कमांड का उपयोग करें।

परिणाम

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

प्रिय पाठकों! क्या आपने गिट कमिट्स में गड़बड़ी का सामना किया है?