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


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

unmerged:   _widget.html.erb

You are in the middle of a conflicted merge.

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


1913
2017-09-19 13:21


मूल


मुझे एहसास है कि यह एक बहुत पुराना सवाल है, लेकिन क्या आप इसे रद्द करना चाहते हैं पूरा का पूरा मर्ज करें, और उस शाखा को छोड़ दें जिसे आप अनर्जित विलय कर रहे थे, या केवल एक फ़ाइल को एक बड़े विलय के हिस्से के रूप में अनदेखा करते हैं, जिससे अन्य सभी फाइलें सामान्य रूप से विलय हो जाती हैं? मेरे लिए, आपका शीर्षक पूर्व का तात्पर्य है, आपका प्रश्न शरीर उत्तरार्द्ध चाहता है। जवाब चीजों को स्पष्ट किए बिना दोनों करते हैं। - rjmunro
मुझे प्रतिबद्धता के समान मामला मिला कि स्वचालित विलय विफल रहा; संघर्ष को ठीक करें और फिर परिणाम दें: [rejected] gh-pages -> gh-pages (non-fast-forward) - Chetabahana
ग्विन, यहां एक स्वीकृत उत्तर चुनने के लिए उपयोगी हो सकता है। शीर्ष वोट दिया गया कुछ अधिक अद्यतित समाधानों की तुलना में थोड़ा कम सुरक्षित है, इसलिए मुझे लगता है कि इससे दूसरों को हाइलाइट करने में मदद मिलेगी :) - Amicable


जवाब:


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

git reset --hard HEAD

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

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

git pull --strategy=theirs remote_branch

लेकिन बाद में इसे हटा दिया गया है, जैसा कि समझाया गया है Junio ​​Hamano द्वारा यह संदेश (गिट रखरखाव)। जैसा कि में उल्लेख किया गया है सम्बन्ध, इसके बजाय आप यह करेंगे:

git fetch origin
git reset --hard origin

1731
2017-09-19 14:33



हार्ड रीसेट करने के बजाय, आप इसे करके अधिक बारीक स्तर पर ला सकते हैं: 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। यह वास्तव में मेरे विलय और संघर्ष के बीच कुछ और दूर बनाता है। - Kzqai
मैं सहमत हूँ। मैं पहले भी लाने के लिए पसंद करता हूं, और फिर अपस्ट्रीम परिवर्तनों की जांच करता हूं (git log ..@{upstream} या git diff ..@{upstream})। उसके बाद, आप की तरह, मैं अपने काम को दोबारा दूंगा। - Pat Notz
जैसा कि हालिया उत्तर में उल्लेख किया गया है, संस्करण 1.6.1 के अनुसार, 'गिट रीसेट --मेर' का उपयोग करना संभव है - Matt Ball
मैंनें इस्तेमाल किया git merge -X theirs remote_branch के बजाय git pull --strategy=theirs remote_branch जैसा theirs एक विकल्प की तरह दिखता है recursive - mlt
कोई रणनीति नहीं है theirs। - srcspider


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

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

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

वहाँ से गिट मर्ज मैन पेज

git merge --abort के बराबर है git reset --merge कब MERGE_HEAD उपस्थित है।

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

इसके अलावा, विलय शुरू करते समय असामान्य परिवर्तनों के बारे में:

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


1592
2018-03-28 23:16



दिलचस्प - लेकिन मैनुअल मुझे डराता है। जब उपयोग करना उचित है? आपको वैकल्पिक निर्दिष्ट कब करना होगा <commit>? #GitMoment: -o - conny
जब आप शुरुआत से विलय को फिर से करना चाहते हैं तो आप आमतौर पर इसका उपयोग करेंगे। मुझे कभी भी वैकल्पिक प्रतिबद्धता निर्दिष्ट नहीं करनी पड़ी, इसलिए डिफ़ॉल्ट (कोई वैकल्पिक <प्रतिबद्ध>) ठीक नहीं है। - Carl
मेरी इच्छा है कि इस जवाब में और वोट होंगे! इस बिंदु पर, यह कई मामलों में सबसे प्रासंगिक समाधान की तरह लगता है। - Jay Taylor
चूंकि गिट v1.7.4 गिट मर्ज --बॉर्ट भी काम करता है। - Michael Johnson
यहां तक ​​कि असामान्य परिवर्तनों के साथ भी गिट विलय से पहले राज्य को बहाल करने में सक्षम था। अच्छा! - T3rm1


git merge --abort

वर्तमान संघर्ष समाधान प्रक्रिया को रोकें, और पुनर्निर्माण करने का प्रयास करें   पूर्व विलय राज्य।

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

git merge --abort के बराबर है git reset --merge कब    MERGE_HEAD उपस्थित है।

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


378
2017-11-12 21:40



यह गिट v1.7.4 के बाद से उपलब्ध है। यह गिट रीसेट --merge के लिए एक उपनाम है। - Michael Johnson
ऑक्टोपस विलय संघर्ष के साथ काम नहीं करता है। - ks1322


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

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

एक विवाद गिट में एक unmerged फ़ाइल के लिए सूचकांक में फ़ाइल के सामान्य आधार, स्थानीय और दूरस्थ संस्करण उपलब्ध कराता है। (यह वह जगह है जहां उन्हें 3-तरफा diff उपकरण में उपयोग के लिए पढ़ा जाता है 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

या, गिट के साथ> = 1.6.1:

git checkout --theirs _widget.html.erb

73
2017-09-20 10:41



संकेत के लिए धन्यवाद। हालांकि, खराब गिट यूजर इंटरफेस का यह स्मैक नहीं है? - Peter
@ पीटर: मुझे विश्वास नहीं है। वांछित परिणाम सरल विकल्पों के साथ कुछ बुनियादी आदेशों के साथ प्राप्त करने योग्य है। आप क्या सुधार करेंगे? - CB Bailey
मुझे लगता है git 1.6.1 आदेश बहुत समझ में आता है, और अच्छा है। यही वही है जो मैं चाहता था। मुझे लगता है कि पूर्व 1.6.1 समाधान सुरुचिपूर्ण है और गिट के अन्य हिस्सों के बारे में ज्ञान की आवश्यकता है जिसे विलय समाधान प्रक्रिया से अलग किया जाना चाहिए। लेकिन नया संस्करण बहुत अच्छा है! - Peter


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

सावधान रहें git revert इसका मतलब है कि कुछ बहुत अलग है, कहो, svn revert - सबवर्सन में रिवर्ट आपके (असामान्य) परिवर्तनों को त्याग देगा, फाइल को वर्तमान संस्करण में रिपोजिटरी से वापस कर देगा, जबकि git revert एक प्रतिबद्धता "undoes"।

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


72
2017-09-19 13:25





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

git merge --abort is equivalent to git reset --merge when MERGE_HEAD is present.

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

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


29
2018-04-02 12:16



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


गिट 1.6.1.3 के बाद से git checkout एक विलय के दोनों ओर से चेकआउट करने में सक्षम है:

git checkout --theirs _widget.html.erb

16
2017-07-17 01:29