😈 🥊 ❣️ गिट गाइड भाग संख्या 2: सुनहरा नियम और रिबेस की अन्य मूल बातें 👰🏻 👼🏿 💪🏿

आइए देखें कि क्या होता है जब आप गिट रिबास चलाते हैं और आपको सावधान रहने की आवश्यकता क्यों होती है। Mail.ru क्लाउड सॉल्यूशंस टीम द्वारा अनुवादित पियरे डे वुल्फ ब्लॉग से गिट गाइड

का यह दूसरा और तीसरा भाग है । पहला भाग यहाँ पढ़ा जा सकता है ।

रिबेस का सार

वास्तव में रिबेट कैसे होता है:

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

यहां मुख्य शब्द लागू करना है, क्योंकि रिबेस केवल किसी अन्य शाखा में कॉपी-पेस्ट शाखाएं नहीं है। रिबास क्रमिक रूप से चयनित शाखा से सभी आवागमन लेता है और उन्हें नई शाखा में पुन: लागू करता है।

यह व्यवहार दो बिंदुओं की ओर जाता है:

फिर से लागू होने से, Git नए कमिट बनाता है। यहां तक कि अगर उनमें समान परिवर्तन होते हैं, तो गिट को नए और स्वतंत्र रूप से माना जाता है।
Git rebase कमिट ओवरराइड करता है और पुराने को डिलीट नहीं करता है। इसका मतलब यह है कि रिबास पूरा होने के बाद, आपके पुराने कमिट्स .it फ़ोल्डर के / सबजेक्ट फ़ोल्डर में संग्रहीत किए जाते रहेंगे। यदि आप पूरी तरह से समझ नहीं पाते हैं कि Git कैसे स्टोर करता है और क्या मानता है, तो इस लेख का पहला भाग पढ़ें।

रिबास के दौरान क्या होता है, इसकी एक और सही व्याख्या इस प्रकार है:

जैसा कि आप देख सकते हैं, सुविधा शाखा में पूरी तरह से नए कमिट हैं। जैसा कि पहले उल्लेख किया गया है, परिवर्तन का एक ही सेट, लेकिन गिट के दृष्टिकोण से पूरी तरह से नई वस्तुएं।

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

अब हम स्वर्णिम नियम की चर्चा करते हैं।

स्वर्ण विद्रोह नियम

गोल्डन रिबेस नियम है: “ कभी भी एक साझा शाखा को रिबास न करें! "। एक साझा शाखा एक ऐसी शाखा को संदर्भित करती है जो नेटवर्क रिपॉजिटरी में मौजूद होती है और जो आपके अलावा अन्य लोगों के साथ काम कर सकती है।

अक्सर यह नियम उचित समझ के बिना लागू किया जाता है, इसलिए, हम विश्लेषण करेंगे कि यह क्यों दिखाई दिया, खासकर जब से यह गिट के काम को बेहतर ढंग से समझने में मदद करेगा।

आइए एक स्थिति देखें जहां एक डेवलपर सुनहरा नियम तोड़ता है, और इस मामले में क्या होता है।

मान लीजिए कि बॉब और अन्ना एक प्रोजेक्ट पर साथ काम कर रहे हैं। नीचे बॉब और अन्ना रिपॉजिटरी और GitHub पर मूल रिपॉजिटरी जैसी दिखती है:

सभी उपयोगकर्ताओं के पास GitHub के साथ सिंक्रनाइज़ किए गए रिपॉजिटरी हैं।

अब बॉब, सुनहरा नियम तोड़ते हुए, एक रिबास करता है, और एक ही समय में, सुविधा शाखा में काम करने वाले अन्ना एक नया इतिहास बनाते हैं:

देखते हैं क्या होगा?

बॉब एक पुश कमिट को अंजाम देने की कोशिश कर रहा है, उसे कुछ इस तरह से मना कर दिया जाता है:

Git सफल नहीं था क्योंकि Git को यह नहीं पता था कि GitHub की फीचर शाखा के साथ बॉब की फीचर शाखा को कैसे जोड़ा जाए।

एकमात्र समाधान जो बॉब को पुश करने की अनुमति देता है, वह बल कुंजी का उपयोग करना है, जो कि सुविधा शाखा को हटाने के लिए गिटहब रिपॉजिटरी को बताता है और एक को स्वीकार करता है कि बॉब इस शाखा के लिए जोर दे रहा है। उसके बाद हमें निम्न स्थिति मिलती है:

अब अन्ना अपने बदलाव शुरू करना चाहता है, और यहाँ है:

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

स्थानीय और GitHub शाखाओं में पुल कमिट करने से पहले इस तरह दिखें:

A--B--C--D'   origin/feature // GitHub
A--B--D--E    feature        // Anna

जब आप खींचते हैं, तो Git रिपॉजिटरी में अंतर को खत्म करने के लिए विलय कर देता है। और इसलिए, इससे क्या होता है:

कमिट एम एक मर्ज कमिट है। अंत में, अन्ना और गिटहब की फीचर शाखाओं को पूरी तरह से मिला दिया गया है। अन्ना ने राहत की सांस ली, सभी संघर्षों को हल किया गया, वह एक धक्का दे सकती है।

बॉब खींच रहा है, अब सब कुछ सिंक में है:

परिणामी गड़बड़ी को देखते हुए, आपको सुनहरे शासन के महत्व को सुनिश्चित करना था। यह भी ध्यान रखें कि ऐसी गड़बड़ी सिर्फ एक डेवलपर द्वारा बनाई गई थी और एक शाखा पर जो सिर्फ दो लोगों के बीच साझा की गई है। दस लोगों की टीम में होने की कल्पना करो।

Git के कई लाभों में से एक यह है कि आप किसी भी समय बिना किसी समस्या के वापस रोल कर सकते हैं। लेकिन जितनी अधिक गलतियाँ की जाती हैं, जैसे वर्णन किया जाता है, उतना ही मुश्किल होता है।

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

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

ओह, वह बॉब !!!!

यह पाठ आपको यह सोचने पर मजबूर कर सकता है कि रिबास का उपयोग केवल एक शाखा को दूसरी शाखा के शीर्ष पर ले जाने के लिए किया जाता है। यह वैकल्पिक है - आप एक ही शाखा पर रिबेस कर सकते हैं।

सौंदर्य पुल रिबास

जैसा कि आपने ऊपर देखा, अगर वह पुल रिबेज का इस्तेमाल करतीं, तो अन्ना की समस्याओं से बचा जा सकता था। आइए इस प्रश्न पर अधिक विस्तार से विचार करें।

मान लीजिए कि बॉब उस शाखा में काम करता है जो गुरु से विदा लेता है, तो उसकी कहानी इस तरह दिख सकती है:

बॉब ने फैसला किया कि यह खींचने का समय है, जो कि जैसा कि आप पहले से ही समझ चुके हैं, कुछ भ्रम पैदा करेगा। चूंकि बॉब का भंडार GitHub से दूर जा रहा था, Git पूछेगा कि क्या मर्ज किया गया है, और परिणाम इस तरह होगा:

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

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

यह जटिल लगता है, इसलिए हम स्पष्ट करते हैं:

Git केवल उन आवागमन पर ध्यान देता है जो आपके और नेटवर्क रिपॉजिटरी दोनों में हैं:

यह GitHub रिपॉजिटरी के एक स्थानीय क्लोन की तरह दिखता है।
Git रीबेज लोकल कमिट्स:

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

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

आमतौर पर, आप निम्नलिखित दृष्टिकोण का उपयोग कर सकते हैं: एक बड़ा परिवर्तन एक लंबे समय से पहले किया गया मर्ज है, हाल ही में एक पुल-रिबास में किए गए दो छोटे बदलाव।

बल पर छूट

मान लीजिए कि आपका प्रतिबद्ध इतिहास इस तरह दिखता है:

तो आप मास्टर शाखा में सुविधा 2 शाखा को फिर से बनाना चाहते हैं। यदि आप मास्टर शाखा पर नियमित छूट देते हैं, तो इसे प्राप्त करें:

यह अतार्किक है कि D दोनों शाखाओं में मौजूद है: फ़ीचर 1 और फ़ीचर 2 में। यदि आप फ़ीचर 1 ब्रांच को मास्टर ब्रांच के अंत में ले जाते हैं, तो यह पता चलता है कि प्रतिबद्ध D को दो बार लागू किया जाएगा।

मान लीजिए कि आपको एक अलग परिणाम प्राप्त करने की आवश्यकता है:

इस तरह के परिदृश्य को लागू करने के लिए, जीआईटी रिबास पर वास्तव में यही इरादा है।

सबसे पहले, प्रलेखन पढ़ें:

SYNOPSIS
       git rebase [-i | --interactive] [<options>] [--exec <cmd>]
               [--onto <newbase> | --keep-base] [<upstream> [<branch>]]
       git rebase [-i | --interactive] [<options>] [--exec <cmd>] 
[--onto <newbase>]
               --root [<branch>]
       git rebase (--continue | --skip | --abort | --quit | --edit-todo 
| --show-current-patch)

हम इस में रुचि रखते हैं:

OPTIONS
       --onto <newbase>
          Starting point at which to create the new commits. If the 
--onto option is not specified, the starting point is <upstream>. May be 
any valid commit, and not just an existing branch name.

इस विकल्प का उपयोग करके इंगित करें कि किस बिंदु पर नए कमिट बनाएं।

यदि यह विकल्प निर्दिष्ट नहीं है, तो अपस्ट्रीम शुरुआती बिंदु बन जाएगा।

समझने के लिए, मैं एक और तस्वीर दूंगा:

A--B--C        master
    \
     D--E      feature1
         \
          F--G feature2

Here we want to rebase feature2 to master beginning from feature1
                           |                                |
                        newbase                         upstream

यही है, मास्टर शाखा newbase है, और सुविधा 1 शाखा अपस्ट्रीम है।

इस प्रकार, यदि आप अंतिम आकृति के अनुसार परिणाम प्राप्त करना चाहते हैं, तो आपको फीचर 2 शाखा में git rebase --onto मास्टर फीचर 1 चलाना होगा।

सौभाग्य Mail.ru Cloud Solutions के

समर्थन से अनुवादित । विषय पर और क्या पढ़ें :

गिट गाइड भाग संख्या 2: सुनहरा नियम और रिबेस की अन्य मूल बातें

रिबेस का सार

स्वर्ण विद्रोह नियम

सौंदर्य पुल रिबास

बल पर छूट

More articles: