एक पुल के दौरान उनके परिवर्तनों के पक्ष में Git मर्ज विरोध को हल करें

Question

मैं खींचे गए परिवर्तनों के पक्ष में एक गिट मर्ज संघर्ष कैसे हल करूं?

मूल रूप से मुझे git mergetoolसभी संघर्ष-मुक्त परिवर्तनों को रखते हुए कुछ समय के संघर्ष के माध्यम से जाने के बिना एक काम के पेड़ से सभी परस्पर विरोधी परिवर्तनों को हटाने की आवश्यकता है । अधिमानतः खींचते हुए ऐसा करना, बाद में नहीं।

Comments

git मर्ज

रिमोट से गिट पुल की डुप्लिकेट .. क्या मैं इसे रिपोर्ट संघर्षों के बजाय अधिलेखित करने के लिए मजबूर कर सकता हूं? आप वहीं समाधान देख सकते हैं।

— डैन डस्केलस्क्यू

@DanDascalescu ने स्वीकार किया कि इस प्रश्न का उत्तर नहीं है, इसलिए स्पष्ट रूप से यह डुप्लिकेट नहीं है। साथ ही, अन्य प्रश्न काफी अस्पष्ट है: जो पूछा गया है उसे बताना बहुत कठिन है। सब सब में मैं तुम्हारे साथ सहमत नहीं हो सकता। इसमें आपकी क्या बात है?

— सनमाई

@sanmai आपके पास दो उत्तर हैं - और आपने उनमें से एक को स्वीकार किया है। क्या आप बेहतर तरीके से समझा सकते हैं कि आप एक उत्तर में क्या उम्मीद कर रहे हैं और आप यहां और कितना विस्तार चाहते हैं?

— एडवर्ड थॉमसन

@EdwardThomson अच्छी तरह से, वास्तव में मैं पहले जवाब के लिए यह प्रतिष्ठा देने के लिए सोच रहा था, लेकिन अगर आप पूछें, तो मैं इंतजार कर सकता हूं और देख सकता हूं कि क्या बेहतर जवाब आता है

— sanmai

Answer 1

git pull -s recursive -X theirs <remoterepo or other repo>

या, बस, डिफ़ॉल्ट भंडार के लिए:

git pull -X theirs

यदि आप पहले से ही विवादित स्थिति में हैं ...

git checkout --theirs path/to/file

Comments

ध्यान दें कि -s recursiveयहाँ बेमानी है, क्योंकि यह डिफ़ॉल्ट मर्ज रणनीति है। तो आप इसे सरल बना सकते हैं git pull -X theirs, जो मूल रूप से इसके बराबर है git pull --strategy-option theirs।

यदि मैं ऐसा करता हूं, तो मैं MERGINGराज्य में वापस आ गया हूं । मैं फिर git merge --abortसे कोशिश कर सकता हूं , लेकिन हर बार मैं एक मर्ज के साथ समाप्त होता हूं। ... मुझे पता है कि एक विद्रोह मेरे ऊपर की ओर धकेल दिया गया था, इसलिए शायद यही कारण है?

— बेंजो

से सावधान रहें git checkout --theirs path/to/file। रिबास के दौरान इसका इस्तेमाल किया और अप्रत्याशित परिणाम प्राप्त किए। Doc में मिली व्याख्या: ध्यान दें कि git rebase और git खींचने के दौरान --rebase, हमारी और उनकी अदला-बदली दिखाई दे सकती है; --ours उस शाखा से संस्करण देता है, जिस पर परिवर्तनों को फिर से शुरू किया जाता है, जबकि - वारिस उस शाखा से संस्करण देता है, जो आपके काम को करता है, जिसे फिर से शुरू किया जा रहा है।

— वुक जापिक

ध्यान दें कि git checkout --theirs/--ours pathमैन पेज बताता है कि यह अनर्जित रास्तों के लिए काम करता है । इसलिए यदि पथ में कोई संघर्ष नहीं था, तो यह पहले से ही विलय हो गया है यह कमांड कुछ भी नहीं करेगा। जब आप पूरे उप-फ़ोल्डर के उदाहरण 'उनके' संस्करण के लिए चाहते हैं तो यह समस्या हो सकती है। तो ऐसे मामले में git checkout MERGE_HEAD pathकमिट हैश का उपयोग करना या करना सुरक्षित होगा ।

— fsw

git pull -X theirsयदि कोई विवाद है (जैसे यदि कोई अन्य git push -fदूरस्थ करने के लिए भाग गया) तो मर्ज कमिट बनाता है । यदि आप मर्ज कमिट नहीं चाहते हैं, तो इसके बजाय चलाएँ git fetch && git reset --hard origin/master।

— डैन डस्केल्सस्कु

Answer 2

आप पुनरावर्ती "उनके" रणनीति विकल्प का उपयोग कर सकते हैं :

git merge --strategy-option theirs

से आदमी :

ours
    This option forces conflicting hunks to be auto-resolved cleanly by 
    favoring our version. Changes from the other tree that do not 
    conflict with our side are reflected to the merge result.

    This should not be confused with the ours merge strategy, which does 
    not even look at what the other tree contains at all. It discards 
    everything the other tree did, declaring our history contains all that
    happened in it.

theirs
    This is opposite of ours.

नोट: के रूप में आदमी पेज कहते हैं, "हमारा" मर्ज रणनीति विकल्प "हमारा" मर्ज से बहुत अलग है रणनीति ।

Comments

यहाँ और अधिक विस्तृत विवरण दिया गया है: Lostechies.com/joshuaflanagan/2010/01/29/…

— mPrinC

इसके अलावा git checkout --theirsएक भी परस्पर विरोधी फ़ाइल पर संचालित करने के लिए

— डीवीडी

यदि आप पहले से ही विवाद समाधान स्थिति में हैं तो यह काम नहीं करता है। उस मामले में मेरा मानना ​​है कि हल करने का सबसे अच्छा तरीका है git checkout <ref to theirs> -- the/conflicted.file; और फिर git addउनके परिवर्तन।

— थोरसुमोनर

@ थोरसुमोनर उस मामले में, git चेकआउट है - उसके रास्ते / फ़ाइल का। इस तरह, आपको सही हैश को मैन्युअल रूप से देखने की ज़रूरत नहीं है।

— इक्के सिप

यदि आप मुझसे पूछते हैं तो @ इक्के मूल रूप से इसका अपना उत्तर होना चाहिए (और उस पर स्वीकृत उत्तर)।

— ThorSummoner

Answer 3

यदि आप पहले से ही विवादित स्थिति में हैं, और आप बस उनकी सभी बातों को स्वीकार करना चाहते हैं:

git checkout --theirs .
git add .

यदि आप इसके विपरीत करना चाहते हैं:

git checkout --ours .
git add .

यह बहुत कठोर है, इसलिए सुनिश्चित करें कि आप वास्तव में ऐसा करने से पहले सब कुछ मिटा देना चाहते हैं।

Comments

या, .उस डॉट के स्थान पर फ़ाइल (एस) का उपयोग न करें और निर्दिष्ट करें जिसे आप चेकआउट करना चाहते हैं। कम "कठोर" और वास्तव में आप क्या करना चाहते हैं, संभवतः।

— मैरो

यह काम नहीं करता है यदि फ़ाइल को दूसरी शाखा से हटा दिया गया है: '<file>' में उनका संस्करण नहीं है

— Japster24

अगर मैं कर सकता हूं तो अधिक उत्थान करूंगा, हर बार इस उत्तर पर वापस आता रहूंगा।

— तारिकि

उन git add -uफ़ाइलों को छोड़ने के बजाय उपयोग करें जो संस्करण नियंत्रण में नहीं हैं।

— सुदिप्ता बसक

हाइपोथेटिकल केस, एक फाइल में तीन बदलाव, एक परस्पर विरोधी, दो बिना संघर्ष के? या यह केवल हमारा संस्करण लेगा कि उनकी ओर से गैर-परस्पर विरोधी परिवर्तनों को अनदेखा किया जाए?

— पाद

Answer 4

ठीक है, परिदृश्य मैं बस में था तस्वीर:

आप ए merge, या शायद ए का प्रयास cherry-pickकरते हैं, और आपको रोक दिया जाता है

$ git cherry-pick 1023e24
error: could not apply 1023e24... [Commit Message]
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

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

git checkout --theirs path/to/the/conflicted_file.php
git add path/to/the/conflicted_file.php

इसका कायल (आपके संस्करण के साथ आने वाले संस्करण को ओवरराइट करने के लिए) है

git checkout --ours path/to/the/conflicted_file.php
git add path/to/the/conflicted_file.php

हैरानी की बात है कि मुझे यह जवाब नेट पर बहुत आसानी से नहीं मिला।

Comments

ध्यान दें कि, यदि कोई git statusबीच checkout- बीच में प्रदर्शन करता है add, तो फ़ाइल अभी भी "दोनों संशोधित" के रूप में दिखाई देती है।

— बिशप

क्या आप जानते हैं कि सभी फाइलों के लिए ऐसा करने का एक तरीका है जो एक विवादित स्थिति में हैं? यदि ऐसा है तो यह आपके उत्तर के लिए एक अच्छा विस्तार होगा।

— ड्रू नॉक

मैं ऐसा करता हूं: git reset --hard और फिर git pull [remote server name] [branch name] -Xtheirs(मर्ज को पूर्ववत् करता है, फिर मेरे सामान के ऊपर नया सामान खींचता है) - यह सुनिश्चित नहीं करें कि यह आपको क्या चाहिए।

— ssaltman

Answer 5

git pull -X theirsजवाब एक बदसूरत मर्ज प्रतिबद्ध बना सकते हैं, या एक मुद्दा

त्रुटि: निम्न फ़ाइलों में आपके स्थानीय परिवर्तन मर्ज द्वारा अधिलेखित हो जाएंगे:

यदि आप रेपो से फ़ाइलों के लिए किसी भी स्थानीय संशोधन को अनदेखा करना चाहते हैं, उदाहरण के लिए एक क्लाइंट पर जो हमेशा एक मूल का दर्पण होना चाहिए, तो इसे चलाएं ( masterउस शाखा को बदलें जिसे आप चाहते हैं):

git fetch && git reset --hard origin/master

यह कैसे काम करता है? git fetchकरता है, git pullलेकिन विलय के बिना । फिर git reset --hardअपने काम के पेड़ को अंतिम प्रतिबद्ध से मेल खाता है। रेपो में फ़ाइलों के लिए आपके सभी स्थानीय परिवर्तन को छोड़ दिया जाएगा , लेकिन नई स्थानीय फ़ाइलों को अकेला छोड़ दिया जाएगा।

Comments

+1 - git fetch && git reset --hard {remote}/{branch}क्या मेरी समस्या हल हो गई थी। मुझे एक शाखा के "उनके" राज्य के पक्ष में अपने स्वयं के परिवर्तनों को पूरी तरह से खोदने की आवश्यकता थी, लेकिन git pull -X theirsकुछ स्थानांतरित / नामांकित फ़ाइलों पर घुट। धन्यवाद!

— Ivaylo Slavov

Answer 6

जीआईटी मर्ज के बाद, यदि आप संघर्ष करते हैं और आप या तो अपना या उनका चाहते हैं

git checkout --theirs .
git checkout --ours .

Comments

मैं इसे प्रति विवादित आधार के आधार पर कैसे करूंगा? ऊपर एक फ़ाइल स्तर पर काम करता है, किसी भी गैर-परस्पर विरोधी विखंडन को फेंकने से एक परस्पर विरोधी फ़ाइल हो सकती है।

— जाणी

Answer 7

किसी विशेष शाखा में संस्करण के साथ सभी संघर्षों को हल करने के लिए:

git diff --name-only --diff-filter=U | xargs git checkout ${branchName}

इसलिए, यदि आप पहले से ही विलय की स्थिति में हैं, और आप परस्पर विरोधी फ़ाइलों का मास्टर संस्करण रखना चाहते हैं:

git diff --name-only --diff-filter=U | xargs git checkout master

Comments

और पाइप xargs तक पहुंच के बिना खिड़कियों पर लोगों के लिए, यह कैसे अनुवाद करता है?

— tsemer

क्या यह आपके परिवर्तनों को पूरी तरह से छोड़ देगा? यहां तक ​​कि जो संघर्ष की स्थिति में नहीं हैं?

— वैलेंटाइन हेनिट्ज

यही मैंने समाप्त किया। दुर्भाग्य से यह बाद में या तो एक की आवश्यकता है git cherry-pick --continue या एक git commit --allow-emptyइन परिवर्तनों को प्रतिबद्ध करने के लिए आदेश, और कोई प्रणाली है जो पीछे आदेश की आवश्यकता है, जो इस दर्द को स्वचालित बनाता हो रहा है। मैं वर्तमान में एक .git/COMMIT_EDITMSGफ़ाइल के अस्तित्व के लिए परीक्षण करके इसे हल कर रहा हूं लेकिन यह हैकरी और भंगुर लगता है, और मैं अभी तक आश्वस्त नहीं हूं कि यह हमेशा काम करता है।

— कोनराड रुडोल्फ

यह अच्छा है, इसका मतलब है कि यदि आप मैन्युअल रूप से कुछ (और करते हैं git add) का समाधान करते हैं तो आप शेष को इसके माध्यम से हल कर सकते हैं। git checkout --ours/ git checkout --theirsउपयोगी भी है।

— rcoup

Answer 8

कृपया नहीं कि कभी-कभी यह काम नहीं करेगा :

git checkout --ours path / to / file

या

git checkout - पथ / फ़ाइल के लिए

मैंने इसके बजाय यह मान लिया कि HEAD हमारा है और MERGE_HEAD उनका है

git checkout HEAD -- path/to/file

या:

git checkout MERGE_HEAD -- path/to/file

ऐसा करने के बाद और हम अच्छे हैं:

git add .

यदि आप और अधिक समझना चाहते हैं, तो यहाँ पर शानदार पोस्ट देखें: git checkout --ours अनमैरिड फाइल्स बुक से फाइलें नहीं हटाते हैं

Answer 9

VS कोड (एकीकृत Git) IDE उपयोगकर्ता:

यदि आप संघर्ष फ़ाइल में आने वाले सभी परिवर्तनों को स्वीकार करना चाहते हैं तो निम्न चरण करें।

1. Go to command palette - Ctrl + Shift + P
2. Select the option - Merge Conflict: Accept All Incoming

इसी तरह आप अन्य विकल्पों के लिए भी कर सकते हैं जैसे एक्सेप्ट ऑल बोथ, एक्सेप्ट ऑल करंट आदि।

Comments

ऐसा लगता है कि केवल एक ही फाइल के लिए काम करना है, हालांकि सभी फाइलों को संघर्ष के साथ नहीं।

— योरो

Answer 10

मेरे पास एक लंबे समय से चल रही next-versionशाखा थी develop, जो फाइलों को हटाने के टन के साथ बदल गई थी , फाइलें जो दोनों शाखाओं पर अलग-अलग स्थानों में जोड़ दी गई थीं, आदि।

मैं next-versionशाखा की पूरी सामग्री को developएक ही मर्ज कमिट में लेना चाहता था ।

मेरे लिए काम करने वाले उपरोक्त आदेशों का संयोजन था:

git merge -X theirs next-version
# lots of files left that were modified on develop but deleted on next-version
git checkout next-version .
# files removed, now add the deletions to the commit
git add .
# still have files that were added on develop; in my case they are all in web/
git rm -r web

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

Answer 11

यदि आप पहले से ही विवादित स्थिति में हैं, और एक-एक करके रास्ता नहीं देखना चाहते हैं। आप कोशिश कर सकते हैं

git merge --abort
git pull -X theirs

Answer 12

से https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging

यह मूल रूप से एक नकली मर्ज करेगा। यह माता-पिता के रूप में दोनों शाखाओं के साथ एक नया मर्ज कमिटमेंट दर्ज करेगा, लेकिन यह उस शाखा को भी नहीं देखेगा जिसमें आप विलय कर रहे हैं। यह केवल आपकी वर्तमान शाखा में सटीक कोड को मर्ज करने के परिणामस्वरूप रिकॉर्ड करेगा।

$ git merge -s ours mundo

S हमारी ’रणनीति से बने।

$ git diff HEAD HEAD~

आप देख सकते हैं कि जिस शाखा पर हम थे और मर्ज के परिणाम में कोई अंतर नहीं है।

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

यदि मैं एक नई विषय शाखा के परिवर्तनों को प्रतिबिंबित करने के लिए मास्टर चाहता हूं तो ऐसी स्थिति उपयोगी होगी। मैंने देखा है कि -Xtheirs कुछ परिस्थितियों में संघर्ष के बिना विलय नहीं करता है ... उदा

$ git merge -Xtheirs topicFoo 

CONFLICT (modify/delete): js/search.js deleted in HEAD and modified in topicFoo. Version topicFoo of js/search.js left in tree.

इस मामले में मुझे जो समाधान मिला वह था

$ git checkout topicFoo

topicFoo से, पहले -ss हमारी रणनीति का उपयोग करते हुए मास्टर में विलय करें, यह नकली कमिट बनाएगा जो कि विषयवस्तु की स्थिति है। $ git मर्ज -s हमारा गुरु

निर्मित मर्ज कमेटी की जाँच करें

$ git log

अब मास्टर शाखा की जाँच करें

$ git checkout master

विषय शाखा को वापस मर्ज करें लेकिन इस बार -Xtheirs पुनरावर्ती रणनीति का उपयोग करें, यह अब आपको विषय की स्थिति के साथ एक मास्टर शाखा के साथ प्रस्तुत करेगा।

$ git merge -X theirs topicFoo