क्या है "गिट धक्का समस्या: गैर तेज आगे"

यह मिनी-नोट मुख्य रूप से प्रश्न का उत्तर है। चूंकि मेरा खाता केवल-पढ़ने के लिए है, यह उत्तर विधि है। "लेकिन जीवन बेहतर हो रहा है!" ©

प्रश्न और उत्तर पढ़ने के बाद पहला निष्कर्ष - जैसा कि डिफोज़ ने सुझाया है, वैसा न करें। वह समस्या का सार नहीं समझता है, और यदि आप उसके द्वारा सुझाए गए अनुसार करते हैं, तो सबसे अधिक संभावना है कि आप डेटा खो देंगे।
दूसरा: alekciy भी काफी सही नहीं है, लेकिन यहां डेटा खोने की संभावना बहुत कम है। लगभग कोई नहीं।
और तीसरा एक: यह लानत है, जब लोग समझेंगे कि यह वास्तव में उपयोग किए गए उपकरण के लिए आवश्यक है? प्रलेखन पढ़ें!


मैं तुरंत कहूंगा कि बहुत से विवरण और "काम" के "काम" को छोड़ दिया गया है या सरलीकृत किया गया है, लेकिन समझ की गिरावट के लिए नहीं। यह समझ की उपस्थिति और लेख का उद्देश्य है, और यदि आपके पास पहले से ही है, और आप सुनिश्चित हैं कि यह सच है :) - तो आपके लिए यहां कुछ भी नया नहीं होगा। अगर अभी तक कोई समझ नहीं है, तो चलो!

सबसे पहले, पता करें कि आगे क्या तेजी है। यह मर्ज ऑपरेशन करने के लिए विकल्पों (विधियों, रणनीतियों) में से एक है। यह केवल तभी संभव है जब वर्तमान कमेटी (जिसमें से मर्ज होगा, हम इसे ए द्वारा निरूपित करते हैं) मर्ज किए गए कमिट का पूर्वज है (जिस के साथ मर्ज होगा, हम इसे बी द्वारा निरूपित करते हैं)। आलेखीय रूप से, यह ऐसा दिखता है (x केवल अन्य कमिट्स हैं जो हमारे लिए महत्वपूर्ण नहीं हैं):

 ......- xxxxAxxx-B 

यदि प्रतिबद्ध इतिहास ऐसा दिखता है:

 ......- बी- xxxA
          \
           \ xxx- बी

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

अब अगली बात यह समझने की है कि धक्का क्या है। इस ऑपरेशन में दो प्रमुख बिंदु हैं। पहला: यह आपके "दूसरे पक्ष" के बारे में डेटा के हस्तांतरण के लिए नहीं है, बल्कि अनिवार्य बाद के ऑपरेशन को "दूसरी तरफ" मर्ज करने का भी है। और दूसरा: मर्ज ऑपरेशन के लिए "उस तरफ" केवल फास्ट-फॉरवर्ड का उपयोग करेगा। सब कुछ ऐसा क्यों है?

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

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

इन बुनियादी चीजों को समझना स्थिति को "स्पष्ट" करने के लिए पर्याप्त होना चाहिए। लेकिन यह कैसे उत्पन्न हो सकता है?

सब कुछ बहुत सरल है: रिपॉजिटरी का उपयोग एक से अधिक व्यक्ति (या एक, लेकिन कई मशीनों पर) द्वारा किया जाता है, या स्थानीय डिपॉजिटरी में एक रिबास बनाया गया था। इनमें से किसी भी विकल्प में, यह संभव है कि दूसरी तस्वीर में क्या दिखाया गया है। और जब से आपके लिए यह स्थिति उत्पन्न हुई है (अर्थात, आपने "git fetch" किया, और देखा कि सब कुछ ऐसा है), तो चलिए सहमति देते हैं कि HEAD सर्वर पर यह A (रिमोट / मूल / मास्टर) को इंगित करता है, आपके लिए स्थानीय रूप से - बी (मास्टर) पर।

समस्या को कैसे हल करें? दो विकल्प हैं, और दोनों ही इस तथ्य की ओर ले जाते हैं कि ए ऐसी कमेटी के साथ विलय करेगा (चलो इसे एक्स कहते हैं), जिसके लिए ए पूर्वज होगा। इसे कैसे प्राप्त किया जाए?

विकल्प एक: विलय। आपको अपने कोड (B) और सर्वर पर मौजूद ए (A) को स्थानीय रूप से मिलाना होगा। मर्ज आपके स्थानीय इतिहास में एक नई प्रतिबद्धता का परिणाम देगा, वही एक्स - और पुश सर्वर इसके लिए एक पुश करने से इनकार नहीं करेगा। समझाने के लिए - चित्र:

 ......- बी- xxxA-
          \ \ <- मर्ज ऑपरेशन ए से बी: गिट मर्ज मूल / मास्टर
           xxx-बी-एक्स

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

 ......- बी- xxxA
                 \ <- रिबेस ऑपरेशन: गिट रिबेस मूल / मास्टर
                  xxx-बी

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

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

एक तीसरा समाधान है, और यह डिफ्यूज था जिसने उदाहरण के लिए पुश पुश का प्रस्ताव दिया:
git push origin +master

यह आपके कमिट को स्वीकार करने के लिए सर्वर का कारण बनेगा, और यह बिना शर्त अपने HEAD को बदल देगा, ताकि यह आपके कमिट के अंतिम को इंगित करे - से बी। इस प्रकार, सभी "आपके" कमिट करते हैं, जो आपके पास नहीं है (बी से ए तक) सर्वर हैं "मैं भूल जाते हैं।" यह बहुत डेटा हानि है जिसके बारे में मैंने शुरुआत में बात की थी। हालांकि, कभी-कभी ऐसे समय होते हैं जब यह ठीक वही ऑपरेशन होता है जिसकी आपको आवश्यकता होती है। लेकिन अगर आपके पास सिर्फ एक ऐसा मामला है, और आप इसे समझते हैं, तो शायद इस लेख की लंबे समय से आवश्यकता नहीं है।

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

मुझे उम्मीद है कि इस सामग्री ने स्पष्ट किया कि क्या हो रहा है और समस्या को हल करने में मदद करेगा।

PS1: कहानी को देखने के लिए "gitk -a" (linux) का उपयोग करना बहुत सुविधाजनक है
UPD: विंडोज पर भी Terentich काम करता है ।
UPD: eyeofhell और OSX पर, यह भी काम करता है :)
PS2: स्टैश (साथ ही कई अन्य ऑपरेशन) एक और चर्चा का विषय है।