मैं एक मर्ज संघर्ष में भाग गया। मैं मर्ज को कैसे समाप्त कर सकता हूं?

Question

मैंने इस्तेमाल किया git pullऔर एक मर्ज संघर्ष था:

unmerged:   _widget.html.erb

You are in the middle of a conflicted merge.

मुझे पता है कि फ़ाइल का दूसरा संस्करण अच्छा है और मेरा खराब है इसलिए मेरे सभी परिवर्तनों को छोड़ दिया जाना चाहिए। मैं यह कैसे कर सकता हूँ?

Comments

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

— rjmunro

मुझे यह कहते हुए समान मामला मिला कि स्वचालित मर्ज विफल हो गया; संघर्षों को ठीक करें और फिर परिणाम दें:[rejected] gh-pages -> gh-pages (non-fast-forward)

— चेतबाहन

ग्विन, यहां एक स्वीकृत उत्तर का चयन करना उपयोगी हो सकता है। शीर्ष मतदान कुछ अधिक तारीख की तारीखों की तुलना में थोड़ा कम सुरक्षित है, इसलिए मुझे लगता है कि यह दूसरों को इस पर प्रकाश डालने में मदद करेगा :)

— Amicable

Answer 1

चूँकि आपकी pullअसफलता तब थी HEAD(नहीं HEAD^) आपकी शाखा पर अंतिम "वैध" है:

git reset --hard HEAD

आप जो दूसरा टुकड़ा चाहते हैं, वह यह है कि आप अपने बदलावों को अपने बदलावों पर सवार होने दें।

पुराने संस्करणों के git ने आपको "उनकी" मर्ज रणनीति का उपयोग करने की अनुमति दी:

git pull --strategy=theirs remote_branch

लेकिन यह तब से हटा दिया गया है, जैसा कि जुनियो हैमनो (गिट अनुचर ) द्वारा इस संदेश में समझाया गया है । जैसा कि लिंक में बताया गया है , इसके बजाय आप ऐसा करेंगे:

git fetch origin
git reset --hard origin

Comments

एक हार्ड रीसेट करने के बजाय, आप इसे अधिक दानेदार स्तर पर ला सकते हैं: git fetch origin -> git reset origin (soft reset, your changes are still present) ->> git checkout file_to_use_their_version_of another_file (steamroll your own changes back to match the origin) मैं कभी भी गिट पुल का उपयोग नहीं करता। चूंकि मेरे नवीनतम कोड और मूल के बीच लड़ाई में, उत्पत्ति को हमेशा जीतना चाहिए, मैं हमेशा git fetchऔर git rebase origin। यह वास्तव में मेरे विलय और संघर्ष को कुछ और दूर के बीच बनाता है।

— काजकाई

मैं सहमत हूँ। मैं भी पहले उठना पसंद करता हूं, और फिर अपस्ट्रीम परिवर्तन ( git log ..@{upstream}या git diff ..@{upstream}) की जांच करता हूं । उसके बाद, आप की तरह, मैं अपने काम को वापस कर दूँगा।

— पैट नोट्ज़

जैसा कि हाल ही के एक उत्तर में उल्लेख किया गया है, संस्करण 1.6.1 के रूप में, 'git reset --merge' का उपयोग करना संभव है

— मैट बॉल

मैं प्रयोग किया जाता है git merge -X theirs remote_branchके बजाय git pull --strategy=theirs remote_branchके रूप में theirsकी एक विकल्प की तरह दिखता हैrecursive

— एम एल टी

git merge --abortबहुत बेहतर है।

— डैनियल कैसिडी

Answer 2

यदि आपका git संस्करण> = 1.6.1 है, तो आप उपयोग कर सकते हैं git reset --merge।

इसके अलावा, @Michael जॉनसन का उल्लेख है, अगर आपका git संस्करण> = 1.7.4 है, तो आप भी उपयोग कर सकते हैं git merge --abort।

हमेशा की तरह, सुनिश्चित करें कि मर्ज शुरू करने से पहले आपके पास कोई अनकहा परिवर्तन नहीं है।

से Git मर्ज आदमी पेज

git merge --abortgit reset --mergeजब MERGE_HEADमौजूद है उसके बराबर है ।

MERGE_HEAD एक मर्ज प्रगति पर है जब मौजूद है।

मर्ज शुरू करने के दौरान भी अनपेक्षित परिवर्तनों के बारे में:

यदि आपके पास ऐसे बदलाव हैं जो आप मर्ज शुरू करने से पहले नहीं करना चाहते हैं, तो git stashउन्हें मर्ज करने से पहले और मर्ज git stash popको खत्म करने या इसे समाप्त करने के बाद करें।

Comments

दिलचस्प - लेकिन मैनुअल मुझे डराता है। जब वास्तव में उपयोग करना उचित है? आपको वैकल्पिक कब निर्दिष्ट करना होगा <commit>? #GitMoment: -O

— conny

जब आप शुरू से मर्ज को फिर से करना चाहते हैं तो आप आमतौर पर इसका इस्तेमाल करेंगे। मुझे खुद को वैकल्पिक प्रतिबद्ध बताने की आवश्यकता नहीं है, इसलिए डिफ़ॉल्ट (कोई वैकल्पिक <प्रतिबद्ध>) ठीक नहीं है।

— कार्ल

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

— जय टेलर

मर्ज किए गए परिवर्तन से पहले भी मर्ज से पहले राज्य को बहाल करने में सक्षम था। अच्छा!

— T3rm1

क्या git merge --abortकेवल एक पर्यायवाची है git reset --merge? नाम निश्चित रूप से अधिक समझ में आता है, लेकिन क्या इसकी कार्यक्षमता समान है?

— तिखन जेल्विस

Answer 3

git merge --abort

वर्तमान संघर्ष रिज़ॉल्यूशन प्रक्रिया को रद्द करें, और पूर्व-मर्ज स्थिति को फिर से बनाने का प्रयास करें।

यदि मर्ज शुरू होने पर वर्तमान में कार्यविहीन परिवर्तन मौजूद थे, तो git merge --abortक्या कुछ मामलों में इन परिवर्तनों का पुनर्निर्माण करने में असमर्थ होंगे। इसलिए यह सलाह दी जाती है कि git मर्ज चलाने से पहले अपने परिवर्तनों को हमेशा कमिट करें या स्टास् करें।

git merge --abortके बराबर है git reset --mergeजब MERGE_HEADमौजूद है।

http://www.git-scm.com/docs/git-merge

Comments

यह git v1.7.4 के बाद से उपलब्ध है। यह git रीसेट --merge के लिए एक उपनाम है।

— माइकल जॉनसन

Answer 4

यह बहुत आसान हैं।

git merge --abort

जब आप इस प्रकार की परेशानी में होते हैं और git स्टेटस कमांड चलाते हैं, तो Git आपको समाधान दिखाता है।

git status

उम्मीद है कि इससे लोगों को मदद मिलेगी।

Answer 5

मुझे लगता है कि यह git resetआपकी जरूरत है।

खबरदार जिसका git revertअर्थ कुछ अलग है, कहते हैं, svn revert- तोड़फोड़ में रिवर्ट आपके (अप्राप्त) परिवर्तनों को छोड़ देगा, फ़ाइल को रिपॉजिटरी से वर्तमान संस्करण में लौटा देगा, जबकिgit revert "कमिट" करता है।

git resetके बराबर करना चाहिए svn revert, अर्थात्, अपने अवांछित परिवर्तनों को त्यागें।

Answer 6

इस विशेष उपयोग के मामले में, आप वास्तव में मर्ज को समाप्त नहीं करना चाहते हैं, बस एक विशेष तरीके से संघर्ष को हल करें।

अलग रणनीति के साथ मर्ज को रीसेट करने और प्रदर्शन करने की कोई विशेष आवश्यकता नहीं है। संघर्ष को सही ढंग से गिट द्वारा उजागर किया गया है और अन्य पक्षों के परिवर्तनों को स्वीकार करने की आवश्यकता केवल इस एक फ़ाइल के लिए है।

एक संघर्षित गिट में एक अनमैरिड फ़ाइल के लिए इंडेक्स में फ़ाइल का सामान्य आधार, स्थानीय और दूरस्थ संस्करण उपलब्ध कराता है। (यह वह जगह है जहाँ से उन्हें 3-वे डिफरेंशियल टूल द्वारा उपयोग के लिए पढ़ा जाता है git mergetool।) आप git showउन्हें देखने के लिए उपयोग कर सकते हैं।

# common base:
git show :1:_widget.html.erb

# 'ours'
git show :2:_widget.html.erb

# 'theirs'
git show :3:_widget.html.erb

दूरस्थ संस्करण वर्बेटिम का उपयोग करने के लिए संघर्ष को हल करने का सबसे सरल तरीका है:

git show :3:_widget.html.erb >_widget.html.erb
git add _widget.html.erb

या, git> = 1.6.1 के साथ:

git checkout --theirs _widget.html.erb

Comments

संकेत के लिए धन्यवाद। यह एक गरीब गिट यूजर इंटरफेस की कमी नहीं है, हालांकि?

— पीटर

@ अभिनेता: मैं आश्वस्त नहीं हूं। वांछित विकल्प सरल विकल्पों के साथ कुछ बुनियादी आदेशों के साथ प्राप्त करने योग्य है। आप क्या सुधार सुझाएंगे?

— सीबी बेली

मुझे लगता है कि git 1.6.1कमांड बहुत मायने रखता है, और अच्छा है। ठीक यही मैं चाहता था। मुझे लगता है कि पूर्व-1.6.1 समाधान असंगत है और इसे अन्य भागों के बारे में ज्ञान की आवश्यकता होती है जिन्हें मर्ज रिज़ॉल्यूशन प्रक्रिया से अलग किया जाना चाहिए। लेकिन नया संस्करण बहुत अच्छा है!

— पीटर

Answer 7

परिदृश्य की तरह, मैंने किया git fetchऔर git pullफिर महसूस किया कि अपस्ट्रीम शाखा मास्टर शाखा नहीं थी, जिसके परिणामस्वरूप अवांछित टकराव हुआ।

git reset --merge 

यह मेरे स्थानीय परिवर्तनों को रीसेट किए बिना वापस लौट आया।

Answer 8

टिप्पणियाँ सुझाव है कि के git reset --mergeलिए एक उपनाम है git merge --abort। यह ध्यान देने योग्य है कि git merge --abortकेवल एक के बराबर है git reset --mergeजो कि MERGE_HEADमौजूद है। यह मर्ज कमांड के लिए git सहायता में पढ़ा जा सकता है।

git मर्ज --abort git reset --merge के बराबर है जब MERGE_HEAD मौजूद है।

एक असफल मर्ज के बाद, जब कोई नहीं होता है MERGE_HEAD, तो असफल मर्ज को पूर्ववत किया जा सकता है git reset --merge, लेकिन जरूरी नहीं कि इसके साथ git merge --abort। वे केवल एक ही चीज़ के लिए पुराने और नए वाक्यविन्यास नहीं हैं ।

व्यक्तिगत रूप से, मुझे git reset --mergeवर्णित एक के समान परिदृश्यों के लिए बहुत अधिक शक्तिशाली लगता है, और सामान्य रूप से विफल विलय।

Comments

यहाँ वास्तव में "विफल मर्ज" से क्या मतलब है? संघर्षों के साथ विलय या कुछ और? या इसे फिर से लिखना: जब MERGE_HEAD मौजूद नहीं है? मेरा अनुवर्ती प्रश्न "git reset --merge" के बेहतर उपयोग को समझने के लिए है।

— ईवोक्स

@ इवोक git stash applyने मेरे लिए एक मर्ज संघर्ष का कारण बना, लेकिन git merge --abortमदद नहीं की git reset --merge।

— nitzel

Answer 9

यदि आप मर्ज संघर्ष के साथ समाप्त होते हैं और आपके पास करने के लिए कुछ भी नहीं है, लेकिन फिर भी एक मर्ज त्रुटि प्रदर्शित की जा रही है। नीचे दिए गए सभी आदेशों को लागू करने के बाद,

git reset --hard HEAD
git pull --strategy=theirs remote_branch
git fetch origin
git reset --hard origin

कृपया निकालें

.git \ index.lock

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

git reset --hard HEAD
git reset --hard origin

उम्मीद है की वो मदद करदे!!!

Answer 10

एक विकल्प, जो कार्यशील प्रतिलिपि की स्थिति को संरक्षित करता है:

git stash
git merge --abort
git stash pop

मैं आम तौर पर इसके खिलाफ सलाह देता हूं, क्योंकि यह प्रभावी रूप से तोड़फोड़ में विलय करने जैसा है क्योंकि यह शाखा के रिश्तों को निम्नलिखित प्रतिबद्ध में फेंक देता है।

Comments

मुझे यह दृष्टिकोण तब उपयोगी लगा जब मैं गलती से एक git-svn शाखा में विलीन हो गया, जो कि अच्छी तरह से संभालती नहीं है। स्क्वैश मर्ज या चेरी पिक्स बेहतर होते हैं जब git-svn ट्रैकिंग शाखाओं के साथ काम करते हैं। वास्तव में मेरा समाधान तथ्य के बाद एक मर्ज को स्क्वैश मर्ज में बदल देता है।

— एलेन ओ'डे जूल

इस सवाल का सबसे अच्छा जवाब

— फवाद बुडक्रेडिन

Answer 11

चूंकि Git 1.6.1.3 git checkoutमर्ज के दोनों ओर से चेकआउट करने में सक्षम है:

git checkout --theirs _widget.html.erb

Answer 12

मैंने पाया कि मेरे लिए निम्नलिखित काम किया गया (पूर्व-विलय राज्य में एक फ़ाइल को वापस लाएं):

git reset *currentBranchIntoWhichYouMerged* -- *fileToBeReset*

Answer 13

Sourcetree

क्योंकि आप अपना मर्ज नहीं करते हैं, तो बस दूसरी ब्रांच पर डबल क्लिक करें (जिसका मतलब है कि चेकआउट करें) और जब sourcetree आपसे सभी बदलावों को छोड़ने के बारे में पूछे तो सहमत होना :)