🛸 🚭 🚡 समृद्ध गिट-मर्ज की पेचीदगियां 🙋🏽 👩‍❤️‍👨 🍴

उद्घाटन टिप्पणी

यह माना जाता है कि "हत्यारा विशेषताएं" SLE Git एक हल्की शाखा है। मैंने इस लाभ को पूरी तरह से महसूस किया, क्योंकि मैंने एसवीएन के साथ गिट में स्विच किया, जहां ब्रांचिंग काफी महंगी प्रक्रिया थी: एक शाखा बनाने के लिए, आपको पूरी कामकाजी निर्देशिका को कॉपी करना होगा। Git में सब कुछ सरल है: एक शाखा बनाने का अर्थ है केवल एक नया सूचक बनाने के लिए एक विशिष्ट कमिट। .git/refs/heads फ़ोल्डर में, जो कि 40 बाइट्स ऑफ़ टेक्स्ट, एक कमिट हैश के साथ एक फ़ाइल है।

Git में ब्रांचिंग के लिए मुख्य उपयोगकर्ता-स्तरीय कमांड्स git-branch, git-checkout, git-rebase, git-log और, ज़ाहिर है, git-merge हैं। खुद के लिए, मैं सबसे बड़ी जिम्मेदारी के क्षेत्र, विशाल जादुई ऊर्जा और महान अवसरों के क्षेत्र को मर्ज-मर्ज मानता हूं। लेकिन यह एक जटिल टीम है, और यहां तक कि गिट के साथ एक काफी लंबा अनुभव कभी-कभी अपनी सभी सूक्ष्मताओं और इसे किसी भी असामान्य स्थिति में सबसे प्रभावी ढंग से लागू करने की क्षमता में महारत हासिल करने के लिए अपर्याप्त है।

आइए, गिट-मर्ज की पेचीदगियों को समझने की कोशिश करें और इस महान जादू को वश में करें।

यहां मैं केवल एक सफल विलय के मामले पर विचार करना चाहता हूं , जिसके द्वारा मेरा मतलब है बिना संघर्ष के विलय। संघर्ष को संसाधित करना और हल करना एक अलग लेख के योग्य एक अलग दिलचस्प विषय है। मैं अत्यधिक अनुशंसा करता हूं कि आप लेख Git internals: data storage and merge को भी पढ़ें, जिसमें बहुत सारी महत्वपूर्ण जानकारी शामिल है, जिस पर मैं भरोसा करता हूं।

टीम शरीर रचना

मैनुअल के अनुसार, कमांड में निम्नलिखित सिंटैक्स होता है:

 
  git मर्ज [-n] [--stat] [--no-प्रतिबद्ध] [--squash] [- [नहीं] ईमेल] 
  [-s <रणनीति>] [-X <रणनीति-विकल्प>] 
  [- [नहीं-] rereere-autoupdate] [-m <msg>] [<प्रतिबद्ध> ...] 
  git मर्ज <msg> HEAD <प्रतिबद्ध> ... 
  git मर्ज --abort

By और बड़े, Git में दो प्रकार के विलय होते हैं: तेजी से आगे विलय और सही विलय। दोनों मामलों के कुछ उदाहरणों पर विचार करें।

सच मर्ज

हम कई सुधार बग का परिचय देने के लिए मास्टर शाखा से विचलित होते ~~हैं~~ । कमिट्स का इतिहास इस प्रकार है:

 
  मास्टर: ए - बी - सी - डी 
                   \ 
  सुविधा: एक्स - वाई

मास्टर git merge feature शाखा पर चलाएँ:

 
  मास्टर: ए - बी - सी - डी - (एम) 
                   \ / 
  सुविधा: एक्स - वाई

यह सबसे आम मर्ज पैटर्न है। इस मामले में, एक नई प्रतिबद्ध (एम) मास्टर शाखा में बनाई गई है, जो दो माता-पिता को संदर्भित करेगी: डी और प्रतिबद्ध वाई; और मास्टर पॉइंटर को कमिट (M) करने के लिए सेट किया गया है। इस तरह, Git समझ जाएगा कि प्रतिबद्ध (M) में कौन से परिवर्तन हैं और कौन सी प्रतिबद्ध मास्टर शाखा में अंतिम है। आमतौर पर, "मर्ज शाखा 'फीचर' जैसे संदेश के साथ एक मर्ज कमिट किया जाता है, लेकिन आप -m स्विच का उपयोग करके अपने स्वयं के प्रतिबद्ध संदेश को भी परिभाषित कर सकते हैं।

आइए एक टेस्ट रिपॉजिटरी में कमिट्स का इतिहास देखें, जो मैंने विशेष रूप से इस केस के लिए बनाया था:

 
  $ गिट लॉग - ऑनलाइन 
  92384bd (M) 
  bceb5a4 D 
  5dce5b1 Y 
  76f13e7 एक्स 
  d1920dc सी 
  3 ए 5 सी 217 बी 
  844af94 ए

अब देखते हैं कमिटेड जानकारी (M):

 
  $ git बिल्ली-फ़ाइल -p 92384bd 
  पेड़ 2b5c78f9086384bd86a2ab9d00c7e41a56f01d04 
  जनक bceb5a4ad88e80467404473b94c3e0758dd8e0be 
  जनक 5dce5b1edef64bd0d4e1039061a77be4d7182678 
  लेखक आंद्रे <andrey.prokopyuk@gmail.com> 1380475972 +0400 
  कमेंटरी आंद्रे <andrey.prokopyuk@gmail.com> 1380475972 +0400 

  (एम)

हम दो माता-पिता को देखते हैं, एक पेड़ वस्तु जो रिपॉजिटरी फ़ाइलों की दी गई स्थिति के अनुरूप है, साथ ही इस बात की जानकारी भी है कि कौन दोषी है।

आइए देखें कि मास्टर पॉइंटर का संदर्भ कहां है:

 
  $ बिल्ली .it / refs / सिर / मास्टर 
  92384bd77304c09b81dcc4485da165923b96ed5f

दरअसल, अब इसे कमिटमेंट (M) में धकेल दिया गया है।

स्क्वैश और नो-कमिट

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

मुख्य शाखा में अधूरा काम करना बुरा है, और आपको इसके बारे में कुछ करने की आवश्यकता है। एक तरीका है, और शायद सबसे आसान, - --squash विकल्प है।

git merge feature --squash के सभी कमिट के बदलावों को git merge feature --squash करता है, उन्हें मास्टर ब्रांच में स्थानांतरित करता है, और उन्हें इंडेक्स में जोड़ता है। इस स्थिति में, मर्ज कमिट नहीं बनाई जाएगी , आपको इसे मैन्युअल रूप से करने की आवश्यकता होगी।

विलय करते समय --no-commit पैरामीटर पास करके आप स्क्वैश पैरामीटर के बिना समान व्यवहार प्राप्त कर सकते हैं।

यदि यह मर्ज लागू किया जाता है, तो सुविधा शाखा कमिट हमारे इतिहास में शामिल नहीं होगी, लेकिन Sq कमिट में उनके सभी परिवर्तन शामिल होंगे:

 
  मास्टर: ए - बी - सी - डी - एसक्यू 
                   \  
  सुविधा: एक्स - वाई

बाद में, यदि आप "क्लासिक" git merge feature चलाते git merge feature तो आप इसे ठीक कर सकते हैं। फिर कहानी निम्नलिखित रूप लेगी:

 
  मास्टर: A - B - C - D - Sq - (M) 
                   \ / 
  सुविधा: एक्स - वाई

यदि आप बिना मर्ज किए गए और फिर महसूस किया कि आपने एक घातक त्रुटि की है, तो आप एक साधारण कमांड के साथ सब कुछ पूर्ववत कर सकते हैं: git merge --abort । यदि विलय के दौरान संघर्ष हुआ था, तो वही आदेश लागू किया जा सकता है, लेकिन आप उन्हें फिलहाल हल नहीं करना चाहते हैं।

रिवाइंड (फास्ट-फॉरवर्ड मर्ज)

इतिहास के एक और मामले पर विचार करें:

 
  मास्टर: ए - बी - सी 
                   \ 
  सुविधा: एक्स - वाई

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

 
  मास्टर, फ़ीचर: ए - बी - सी - एक्स - वाई

रिवाइंडिंग को रोकने के लिए, आप --no-ff विकल्प का उपयोग कर सकते हैं।
यदि हम git merge feature --no-ff -m '(M)' , तो हमें निम्नलिखित चित्र मिलेगा:

 
  मास्टर: ए - बी - सी - (एम) 
                   \ / 
  सुविधा: एक्स - वाई

यदि फास्ट-फॉरवर्ड हमारे लिए एकमात्र स्वीकार्य व्यवहार है, तो हम --ff-only विकल्प को निर्दिष्ट कर सकते हैं। इस मामले में, यदि रिवाइंडिंग मर्ज पर लागू नहीं है, तो एक संदेश प्रदर्शित किया जाएगा जो विलय की असंभवता को दर्शाता है। यदि हम पहले ही उदाहरण में --ff-only विकल्प --ff-only , तो यह मामला होगा, जहां, शाखा सुविधा के बाद, मास्टर शाखा में एक प्रतिबद्ध C बनाया गया था।

आप जोड़ सकते हैं कि जब आप git pull origin branch_name , तो --ff-only । यही है, यदि मूल / शाखा_नाम शाखा के साथ विलय करते समय रिवाइंडिंग स्वीकार्य नहीं है, तो ऑपरेशन रद्द हो जाता है और निष्पादन की असंभवता के बारे में एक संदेश प्रदर्शित होता है।

विलय की रणनीति

गिट-मर्ज टीम का एक दिलचस्प विकल्प है, - --strategy , रणनीति। Git निम्नलिखित मर्ज रणनीतियों का समर्थन करता है:

संकल्प
पुनरावर्ती
हमारा
ऑक्टोपस
सबट्री

रणनीति को हल करें

रिज़ॉल्यूशन रणनीति क्लासिक तीन-तरफा मर्ज है। मानक तीन-तरफा मर्ज एल्गोरिथ्म का उपयोग दो फ़ाइलों के लिए एक सामान्य पूर्वज के साथ किया जाता है। पारंपरिक रूप से, इस एल्गोरिथम को निम्नलिखित चरणों के रूप में दर्शाया जा सकता है:

एक सामान्य पूर्वज की खोज,
एक सामान्य पूर्वज के सापेक्ष दोनों संस्करणों में बदल गए ब्लॉकों की खोज,
अपरिवर्तित रहने वाले ब्लॉक दर्ज किए जाते हैं,
ब्लॉक जो केवल एक वंश में बदल गया है, जैसे ही दर्ज किया जाता है,
ब्लॉक जो दोनों संस्करणों में बदल गए हैं, केवल तभी दर्ज किए जाते हैं यदि परिवर्तन समान हैं, अन्यथा एक संघर्ष घोषित किया जाता है, जिसका संकल्प उपयोगकर्ता को प्रदान किया जाता है।

इस रणनीति में एक खामी है: सबसे सामान्य आम प्रतिबद्धताओं को हमेशा दो शाखाओं के सामान्य पूर्वज के रूप में चुना जाता है। हमारे पहले उदाहरण के मामले में, यह डरावना नहीं है, आप सुरक्षित रूप से git merge feature -s resolve उपयोग कर सकते हैं, और परिणाम अपेक्षित होगा:

 
  मास्टर: ए - बी - सी - डी - (एम) 
                   \ / 
  सुविधा: एक्स - वाई

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

किस मामले में एक संकल्प रणनीति की कमी स्वयं प्रकट होती है? यह खुद को प्रकट करता है कि अगर प्रतिबद्ध (एम) के लिए हमें संघर्षों को हल करना था, जिसके बाद हमने विकास जारी रखा और एक बार फिर से git merge feature -s resolve करना चाहते हैं। इस स्थिति में, प्रतिबद्ध C का उपयोग फिर से एक सामान्य पूर्वज के रूप में किया जाएगा, और संघर्ष फिर से होगा और हमारे हस्तक्षेप की आवश्यकता होगी।

पुनरावर्ती रणनीति

यह रणनीति संकल्प रणनीति की समस्याओं को हल करती है। यह तीन-तरफा विलय को लागू करता है, लेकिन एक वास्तविक नहीं, बल्कि एक "आभासी" पूर्वज, जो निम्नलिखित सशर्त एल्गोरिथम के अनुसार निर्मित होता है, का उपयोग पूर्वज के रूप में किया जाता है:

एक सामान्य पूर्वज के लिए सभी उम्मीदवारों की खोज की जाती है,
श्रृंखला उम्मीदवारों को विलय कर देती है, जिसके परिणामस्वरूप एक नया "आभासी" पूर्वज होता है, जिसमें हाल ही में एक उच्च प्राथमिकता होती है, जो संघर्षों के पुन: प्रकटन से बचा जाता है।

इस क्रिया के परिणाम को सामान्य पूर्वज के रूप में लिया जाता है और तीन-तरफा विलय किया जाता है।

इस रणनीति का वर्णन करने के लिए, आइए लेख से एक उदाहरण उधार लेते हैं प्लास्टिसिक्स ब्लॉग से पुनरावर्ती रणनीति मर्ज करें:

पुनरावर्ती विलय करें

तो, हमारी दो शाखाएँ हैं: मुख्य और टास्क001। और इसलिए यह पता चला कि हमारे डेवलपर्स विकृतियों के एक अच्छे न्यायाधीश हैं: उन्होंने टास्क001 शाखा से 12 के साथ मुख्य शाखा से 15 में विलय कर दिया, साथ ही प्रतिबद्ध 16 के साथ 16 प्रतिबद्ध। जब हमें शाखाओं को विलय करने की आवश्यकता हुई, तो यह पता चला कि वास्तविक पूर्वज एक धन्यवाद रहित कार्य था , लेकिन एक "आभासी" पूर्वज के निर्माण के साथ पुनरावर्ती रणनीति हमारी मदद करेगी। परिणामस्वरूप, हमें निम्न चित्र मिलते हैं:

पुनरावर्ती विलय करें

पुनरावर्ती रणनीति में कई विकल्प हैं जो कि -X स्विच का उपयोग करके git-merge कमांड को दिया जाता है:

हमारा और उनका
स्वचालित रूप से संघर्षों को हल करने के लिए उपयोग किया जाता है। हमारा - "हमारा" संस्करण पसंद करते हैं, "dst" का संस्करण, उनका - "उनका" संस्करण पसंद करते हैं।
पुनर्जन्म
विभिन्न प्रकार की लाइन फ़ीड के साथ विकल्पों को मर्ज करने पर गलत विरोध को रोकता है।
diff-algorithm = [धैर्य | न्यूनतम | हिस्टोग्राम | मायर्स] , साथ ही धैर्य विकल्प
फ़ाइल भेदभाव एल्गोरिथ्म की पसंद।
इन विकल्पों पर आगे की जानकारी git-diff प्रलेखन में पाई जा सकती है। संक्षेप में, इन एल्गोरिदम के गुण निम्नानुसार हैं:
डिफ़ॉल्ट, मायर्स एक मानक, लालची एल्गोरिथ्म है। यह डिफ़ॉल्ट रूप से उपयोग किया जाता है।
न्यूनतम - न्यूनतम परिवर्तनों की खोज करता है, जिसमें अतिरिक्त समय लगता है।
धैर्य - "धैर्य अलग" एल्गोरिथ्म का उपयोग करें। आप एल्गोरिथ्म के लेखक से या एसओ पर एक संक्षिप्त संस्करण में इसके बारे में पढ़ सकते हैं।
हिस्टोग्राम - "निम्न-निम्न सामान्य तत्वों का समर्थन" के रूप में वर्णित लक्ष्य के साथ धैर्य एल्गोरिथ्म का विस्तार करता है। ईमानदार होने के लिए, मुझे इस सवाल का स्पष्ट जवाब नहीं मिल पाया कि कौन से विशिष्ट मामले निहित हैं और अगर कोई व्यक्ति इस उत्तर को खोजने में मदद करता है तो मुझे बहुत खुशी होगी।
इग्नोरेंस-स्पेस-चेंज, इग्नोर-ऑल-स्पेस, इग्नोर-स्पेस-एट-एओल
इन विकल्पों की जड़ें, फिर से, गिट-डिफरेंस में हैं और विलय के दौरान भेदभाव को दर्ज करने के लिए संबंधित हैं।
उपेक्षा-स्थान-परिवर्तन - एक पंक्ति में रिक्त स्थान की संख्या और साथ ही एक पंक्ति के अंत में रिक्त स्थान की संख्या में अंतर को अनदेखा करता है,
अनदेखी-सभी-स्थान - तुलना करते समय रिक्त स्थान पूरी तरह से नजरअंदाज कर दिए जाते हैं,
इग्नोर-स्पेस-एट-एओल - लाइन के अंत में स्पेस में अंतर को अनदेखा किया जाता है।
नाम बदलें-दहलीज = <n>
यह विकल्प उस सीमा को निर्धारित करता है जिस तक पहुँचने पर फ़ाइल को नया नहीं माना जा सकता है, बल्कि एक फ़ाइल का नाम बदल दिया जाता है, जिसे git-diff नहीं गिना जाता। उदाहरण के लिए, -Xrename-threshold=90% तात्पर्य है कि एक फ़ाइल जिसमें कुछ हटाई गई फ़ाइल की सामग्री का 90% होता है, का नाम बदला जाता है।
सबट्री [= <path>]
इस विकल्प के साथ एक पुनरावर्ती मर्ज करना, सबट्री रणनीति का एक और अधिक उन्नत संस्करण होगा, जहां एल्गोरिथ्म इस धारणा पर आधारित है कि मर्ज के दौरान पेड़ों को एक साथ कैसे फिट होना चाहिए। इसके बजाय, इस मामले में एक विशिष्ट विकल्प का संकेत दिया जाता है।

ऑक्टोपस की रणनीति

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

इस रणनीति में संभावित संघर्षों के बारे में बहुत सावधानी शामिल है। इस संबंध में, ऑक्टोपस रणनीति का उपयोग करते समय विलय करने से इनकार करना कभी-कभी संभव होता है।

हमारी रणनीति

हमारी पुनरावर्ती रणनीति के साथ हमारे भ्रमित मत करो।

प्रदर्शन git merge -s ours obsolete , आप का कहना है कि: मैं शाखाओं के इतिहास को मर्ज करना चाहता हूं, लेकिन अप्रचलित शाखा में होने वाले सभी परिवर्तनों को अनदेखा करना चाहता हूं। इसके बजाय, हम कभी-कभी हमारे बजाय निम्नलिखित विकल्प का उपयोग करने की सलाह देते हैं:

 
  $ git चेकआउट अप्रचलित है 
  $ git मर्ज -s पुनरावर्ती -Xtheirs मास्टर

हमारी रणनीति अधिक कट्टरपंथी साधन है।

सबट्री रणनीति

इस रणनीति का वर्णन करने के लिए, आइए "प्रो गिट" पुस्तक के अध्याय मर्जिंग उपप्रकारों से एक उदाहरण लेते हैं।

हमारी परियोजना में एक नया दूरस्थ भंडार जोड़ें, रैक:

 
  $ git रिमोट add रैक_remote git@github.com: schacon / रैक.जित 
  $ जीएटी का रैक रैक_मोट 
  चेतावनी: कोई आम नहीं करता है 
  दूरस्थ: गिनती की वस्तुओं: 3184, किया। 
  दूरस्थ: संपीड़ित वस्तुएं: 100% (1465/1465), किया। 
  रिमोट: कुल 3184 (डेल्टा 1952), पुन: उपयोग 2770 (डेल्टा 1675) 
  प्राप्त वस्तुएं: 100% (3184/3184), 677.42 KiB |  4 कीबी / एस, किया। 
  समाधान डेल्टा: 100% (1952/1952), किया। 
  Git@github.com से: schacon / रैक 
   * एक नई शाखा] निर्माण -> रैक_मोट / निर्माण 
   * [एक नई शाखा] मास्टर -> रैक_ सुप्रीम / मास्टर 
   * [एक नई शाखा] रैक-0.4 -> रैक_्रेमोट / रैक-0.4 
   * एक नई शाखा] रैक-0.9 -> रैक_्रेमोट / रैक-0.9 
  $ git चेकआउट -b रैक_ब्रंच रैक_आर्मोट / मास्टर 
  सुदूर शाखा को ट्रैक करने के लिए स्थापित शाखा रैक_ब्रांच / रेपो / रेमो_मोट / मास्टर। 
  एक नई शाखा "rack_branch" पर स्विच किया गया

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

 
  $ गिट चेकआउट मास्टर 
  $ git मर्ज - ssashash -s सबट्री --no-प्रतिबद्ध रैक_ब्रंच 
  स्क्वैश कमिट - HEAD अपडेट नहीं करना 
  स्वचालित मर्ज ठीक चला;  अनुरोध के अनुसार करने से पहले बंद कर दिया

अब रैक परियोजना की फाइलें हमारी कार्यशील निर्देशिका में हैं।

अंतिम शब्द

इसलिए, मैंने उन सभी ज्ञान को इकट्ठा किया, जो मैंने जीट के साथ काम करते हुए हासिल किए। मुझे खुशी होगी अगर यह किसी की मदद करता है, लेकिन मुझे भी खुशी होगी अगर कोई मुझे सामग्री के पूरक या गलतियां और गलतियों को सुधारने में मदद करता है, अगर मैं अचानक ऐसा बना हूं।

समृद्ध गिट-मर्ज की पेचीदगियां