क्या "git मर्ज -s हमारा" का "उनका" संस्करण है?

Question

विषय शाखा "बी" को "ए" के उपयोग से विलय करते समय git merge, मुझे कुछ संघर्ष मिलते हैं। मुझे पता है कि "बी" संस्करण का उपयोग करके सभी संघर्षों को हल किया जा सकता है।

मुझे पता है git merge -s ours। लेकिन मैं जो चाहता हूं वह कुछ ऐसा है git merge -s theirs।

इसका अस्तित्व क्यों नहीं है? मौजूदा gitकमांड के साथ परस्पर विरोधी विलय के बाद मैं एक ही परिणाम कैसे प्राप्त कर सकता हूं ? ( git checkoutबी से हर unmerged फ़ाइल)

अद्यतन: शाखा ए (पेड़ के बी संस्करण में मर्ज कमिट पॉइंट) से कुछ भी छोड़ने का "समाधान" वह नहीं है जो मैं खोज रहा हूं।

Comments

इस उत्तर को भी देखें: stackoverflow.com/questions/928646/… - यह ए के बजाय संस्करण बी का उपयोग करने के लिए उदाहरण बदलने के लिए तुच्छ है

— रॉबी बसाक

अनुकरण करने के लिए सभी मौजूदा तरीकों के लिए एक शाखा को दूसरे की तरह बनाने के लिए SO उत्तर git कमांड देखें । git merge -s their

— VonC

तो आप वास्तव में एक git merge -s theirs(जिसे आसानी से git merge -s oursऔर एक अस्थायी शाखा के साथ प्राप्त किया जा सकता है ) की तलाश नहीं कर रहे हैं , क्योंकि -एस हमारी पूरी तरह से मर्ज से शाखा के परिवर्तनों की अनदेखी करता है ...

— निकोलो मार्टिनी

@Torek - क्या जीआईटी देवों को वास्तव में ऐसा लगता है जोtheirs इसके अलावा प्रदान करने के लिए आक्रामक है ours??? यह गिट में एक उच्च स्तरीय इंजीनियरिंग और डिजाइन समस्याओं में से एक का एक लक्षण है: असंगति।

— jww

@jww यहाँ समस्या "git मर्ज -s ours" आक्रामक होने के बारे में नहीं है, लेकिन इसके बारे में प्रति-सहजता है। आप ओपी के प्रश्न से देख सकते हैं कि यदि ऐसी कोई सुविधा जोड़ी जाएगी तो वह गलती से इसका उपयोग करेगा जब वह वास्तव में करना चाहता है "git मर्ज -s पुनरावर्ती -X उनका"। दूसरी शाखा पर संस्करण के साथ टकराव को देखते हुए एक और शाखा को मर्ज करना आम है, लेकिन वर्तमान शाखा को पूरी तरह से एक दूसरे को बदलने के साथ वर्तमान शाखा को ओवरराइट करना वास्तव में एक अपवाद मामला है।

— थोमाज़ोमरा

Answer 1

का -Xविकल्प जोड़ें theirs। उदाहरण के लिए:

git checkout branchA
git merge -X theirs branchB

सब कुछ वांछित तरीके से विलय होगा।

केवल एक चीज जो मैंने देखी है वह समस्या है यदि ब्रांच से फाइलें डिलीट हो गई हैं। वे संघर्ष के रूप में दिखाते हैं अगर गिट के अलावा कुछ और हटा दिया।

फिक्स आसान है। git rmहटाए गए फ़ाइलों के नाम के साथ बस चलाएं :

git rm {DELETED-FILE-NAME}

उसके बाद -X theirsउम्मीद के मुताबिक काम करना चाहिए।

बेशक, git rmकमांड के साथ वास्तविक निष्कासन करने से संघर्ष को पहले स्थान पर होने से रोका जा सकेगा।

---

नोट : एक लंबा फ़ॉर्म विकल्प भी मौजूद है।

इसका उपयोग करने के लिए, प्रतिस्थापित करें:

-X theirs

साथ में:

--strategy-option=theirs

Comments

मूल प्रश्न के बेहतर समाधान (पॉल प्लाडीज) के लिए नीचे दिए गए अन्य उत्तर देखें।

— मैल्कम

ध्यान दें कि यह "मर्ज रणनीति theirs" के समान नहीं है । -Xtheirs पुनरावर्ती रणनीति के लिए लागू रणनीति विकल्प है । इसका मतलब यह है कि पुनरावर्ती रणनीति अभी भी कुछ भी विलय कर सकती है, और केवल संघर्ष के मामले में "उनके" तर्क पर वापस गिर जाएगी। जबकि ऊपर के अधिकांश मामलों में किसी को इसकी आवश्यकता होती है, यह "सिर्फ शाखा बी से सब कुछ जैसा है" के समान नहीं है। यह वैसे भी असली मर्ज करता है।

— तैमूर

यह अन्य कमांड के साथ भी काम करता है। मैंने सिर्फ एक 'git चेरी-पिक sha1 -X उनका' किया। धन्यवाद!

— मैक्स होहेनगर

यह एक भयानक उत्तर है, क्योंकि यह सही दिखता है, लेकिन वास्तव में गलत है। "git मर्ज -X उनकी" वह नहीं करता है जो "git मर्ज -s उनकी" करता है। यह मर्ज किए गए शाखा की सामग्री के साथ वर्तमान शाखा को प्रतिस्थापित नहीं करता है। यह "उनकी" परिवर्तन पसंद करता है, लेकिन केवल संघर्ष के मामले में। इसलिए, परिणामी प्रतिबद्धता "उनकी" शाखा से काफी भिन्न हो सकती है। यह वह नहीं है जो प्रश्न पोस्टर के मन में था।

— इवान क्रिव्याकोव

@ user3338098: हाँ, आप सही हैं। मैंने प्रश्न को फिर से पढ़ा, और यह भी इतना अच्छा नहीं है। दुर्भाग्य से, भ्रम का मूल कारण उत्तर नहीं है और प्रश्न भी नहीं है। यह एक समान रणनीति को 'हमारा' नाम देने के लिए और विलय की रणनीति 'पुनरावर्ती' के विकल्प के लिए git लेखकों का डिज़ाइन विकल्प है। इस मामले में भ्रम व्यावहारिक रूप से अपरिहार्य है।

— इवान क्रिव्याकोव

Answer 2

ब्रांच को हमारी चेक-आउट ब्रांच में विलय करने के लिए एक संभावित और परीक्षित समाधान:

# in case branchA is not our current branch
git checkout branchA

# make merge commit but without conflicts!!
# the contents of 'ours' will be discarded later
git merge -s ours branchB    

# make temporary branch to merged commit
git branch branchTEMP         

# get contents of working tree and index to the one of branchB
git reset --hard branchB

# reset to our merged commit but 
# keep contents of working tree and index
git reset --soft branchTEMP

# change the contents of the merged commit
# with the contents of branchB
git commit --amend

# get rid off our temporary branch
git branch -D branchTEMP

# verify that the merge commit contains only contents of branchB
git diff HEAD branchB

इसे स्वचालित करने के लिए आप इसे एक स्क्रिप्ट में शाखा और शाखा के रूप में उपयोग कर सकते हैं।

यह समाधान मर्ज कमिट के पहले और दूसरे माता-पिता को सुरक्षित रखता है, जैसा कि आप उम्मीद करेंगे git merge -s theirs branchB।

Comments

प्रश्न: आपको ब्रांच की आवश्यकता क्यों है? क्या आप नहीं कर सकते git reset --soft branchA?

— cdunn2001

@ cdunn2001: किसी तरह मैंने एक ही बात सोची, लेकिन नहीं। ध्यान दें कि git reset --hardपरिवर्तन जो करने के लिए branchAइंगित करता है।

— त्सुयोशी इतो

एक बेवकूफ सवाल पूछने के लिए क्षमा करें, लेकिन यह तरीका बेहतर क्यों है? क्या फायदे / नुकसान हैं

— chrispepper1989

@ chrispepper1989 -x उनकी केवल संघर्षों को प्रभावित करता है , अगर हमारे एक हंक को साफ- सुथरा लगाया जा सकता है, तो यह परिणामी मर्ज के माध्यम से मिलेगा। इस मामले में, जैसा कि अंतिम कमांड द्वारा दिखाया गया है, हमें एक मर्ज मिल रहा है, जो पूरी तरह से ब्रांच के समान है, भले ही संघर्ष हो या न हो।

— अंकलजीव

@UncleZeiv आपको स्पष्टीकरण के लिए धन्यवाद देता है, इसलिए मूल रूप से "उनका" करने से असंबंधित परिवर्तन और फाइलें बनी रहेंगी जिसके परिणामस्वरूप int कोड खींचे गए कोड के समान नहीं होगा।

— chrispepper1989

Answer 3

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

git pull --strategy=theirs remote_branch

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

git fetch origin
git reset --hard origin

हालांकि, खबरदार कि यह एक वास्तविक मर्ज से अलग है। आपका समाधान संभवतः वह विकल्प है जिसकी आप वास्तव में तलाश कर रहे हैं।

Comments

मैं वास्तव में जूनियो हैनो के स्पष्टीकरण को बिल्कुल नहीं समझता। git reset --hard originउनकी शैली के मर्ज का हल कैसे है ? अगर मैं ब्रांच को ब्रांच में विलय करना चाहता था (जैसे एलन डब्लू स्मिथ के जवाब में), तो मैं इसे resetविधि का उपयोग कैसे करूंगा ?

— जेम्स मैकमोहन

@ जेम्स मैकमोहन: जूनियो सी हमानो की बात git reset --hard"उनके" -स्टाइल मर्ज नहीं है। बेशक, git reset --hardउस मामले के लिए कोई मर्ज कमिट, या कोई कमिट नहीं बनाता है। उनका कहना यह है कि हमें एचईएडी को किसी और चीज से बदलने के लिए मर्ज का उपयोग नहीं करना चाहिए । मैं जरूरी नहीं मानता, हालांकि।

— त्सुयोशी इतो

यह शर्म की बात है कि theirsहटा दिया गया क्योंकि औचित्य अधूरा था। यह उन उदाहरणों के लिए अनुमति देने में विफल रहा जहां कोड अच्छा है, इसका बस यह है कि अपस्ट्रीम को एक अलग दार्शनिक आधार पर बनाए रखा गया है, इसलिए उस अर्थ में 'बुरा' है, इसलिए कोई भी व्यक्ति अपस्ट्रीम के साथ डेट करना चाहता है, लेकिन उसी समय अपने अच्छे कोड 'फ़िक्स' को बनाए रखें [git & msysgit के पास इस 'संघर्ष' के कारण उनके कुछ अलग लक्ष्य प्लेटफ़ॉर्म के दर्शन हैं]

— फिलिप ओकले

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

— सेज़िट्लिन

मैं वास्तव में दर्शन को नहीं समझता। मैंने सिर्फ theirsइसलिए इस्तेमाल किया क्योंकि मैंने गलती से कुछ फाइलों को दो अलग-अलग शाखाओं में बदल दिया था और हर फाइल के लिए मैन्युअल रूप से करने के बिना एक के बदलाव को छोड़ना चाहता था।

— सूदो

Answer 4

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

मर्ज का प्रयास करें और संघर्ष के लिए बी का उपयोग करें

यह "उनके लिए संस्करण" नहीं है , git merge -s oursलेकिन "उनके लिए संस्करण git merge -X ours" (जो कि कम है git merge -s recursive -X ours):

git checkout branchA
# also uses -s recursive implicitly
git merge -X theirs branchB

यह वही है जो एलन डब्ल्यू स्मिथ का जवाब है।

केवल B से सामग्री का उपयोग करें

यह दोनों शाखाओं के लिए एक मर्ज कमिट बनाता है लेकिन सभी परिवर्तनों को छोड़ देता है branchAऔर केवल सामग्री को रखता है branchB।

# Get the content you want to keep.
# If you want to keep branchB at the current commit, you can add --detached,
# else it will be advanced to the merge commit in the next step.
git checkout branchB

# Do the merge an keep current (our) content from branchB we just checked out.
git merge -s ours branchA

# Set branchA to current commit and check it out.
git checkout -B branchA

ध्यान दें कि मर्ज अब पहला अभिभावक करता है, वह branchBकेवल और केवल दूसरा होता है branchA। यह वही है जो कि Gandalf458 का जवाब देता है।

केवल B से सामग्री का उपयोग करें और सही मूल क्रम रखें

यह असली "उनके लिए संस्करण git merge -s ours" है। इसमें वही सामग्री है जो पहले (यानी केवल उस से branchB) विकल्प में है, लेकिन माता-पिता का आदेश सही है, यानी पहला माता-पिता से आता है branchAऔर दूसरा से branchB।

git checkout branchA

# Do a merge commit. The content of this commit does not matter,
# so use a strategy that never fails.
# Note: This advances branchA.
git merge -s ours branchB

# Change working tree and index to desired content.
# --detach ensures branchB will not move when doing the reset in the next step.
git checkout --detach branchB

# Move HEAD to branchA without changing contents of working tree and index.
git reset --soft branchA

# 'attach' HEAD to branchA.
# This ensures branchA will move when doing 'commit --amend'.
git checkout branchA

# Change content of merge commit to current index (i.e. content of branchB).
git commit --amend -C HEAD

यह क्या है पॉल Pladijs के जवाब (एक अस्थायी शाखा की आवश्यकता के बिना) करता है।

Comments

विकल्प 3 का क्लीनर संस्करण:git checkout branchA; git merge -s ours --no-commit branchB; git read-tree -um @ branchB; git commit

— jthill

@jthill: जबकि आपका संस्करण अधिक संक्षिप्त है, यह निम्न-स्तर ("प्लंबिंग") कमांड का भी उपयोग करता read-treeहै जो औसत गिट उपयोगकर्ता का उपयोग नहीं किया जा सकता है (कम से कम मैं नहीं; ;-))। उत्तर में समाधान केवल उच्च-स्तरीय ("चीनी मिट्टी के बरतन") का उपयोग करता है, जो अधिकांश उपयोगकर्ताओं को पता होना चाहिए। मैं उन्हें पसंद करता हूं लेकिन फिर भी आपके संस्करण के लिए धन्यवाद!

— siegi

क्या आप दूसरे से अंतिम चरण (चेकआउट ब्रांच) की व्याख्या कर सकते हैं? ऐसा लगता है कि यह नहीं होना चाहिए।

— पैट्रिक

@ पैट्रिक, इस कदम की आवश्यकता है। यदि आप इसे छोड़ देते हैं, तो आपको वही कमिटमेंट मिलेगा, लेकिन आपके पास इस कमिट की ओर इशारा करने वाली शाखा नहीं होगी। इसलिए जैसे ही आप दूसरी कमिट / ब्रांच पर जाते हैं, आपके द्वारा अंतिम कमांड ( …commit --amend…) के साथ किया गया कमिटमेंट "खो" जाएगा। मैं इस उत्तर के लिए कुछ ग्राफिकल स्पष्टीकरण जोड़ने की योजना बना रहा हूं जैसे ही मेरे पास उन्हें करने का समय है ... ;-)

— siegi

Answer 5

मैंने अब से पॉल प्लाडीज के उत्तर का उपयोग किया। मुझे पता चला, आप एक "सामान्य" मर्ज कर सकते हैं, संघर्ष होता है, इसलिए आप करते हैं

git checkout --theirs <file>

दूसरी शाखा से संशोधन का उपयोग करके संघर्ष को हल करने के लिए। यदि आप प्रत्येक फ़ाइल के लिए ऐसा करते हैं, तो आपके साथ वैसा ही व्यवहार होगा जैसा आप उससे अपेक्षा करते हैं

git merge <branch> -s theirs

वैसे भी, यह प्रयास मर्ज-रणनीति के साथ होने की तुलना में अधिक है! (यह git संस्करण 1.8.0 के साथ परीक्षण किया गया था)

Comments

यदि फ़ाइलों की सूची पुनः प्राप्त की जा सकती है तो बहुत अच्छा होगा। उदाहरण के लिए, git ls-files --modified | xargs git addमैं इसे दोनों पक्षों के मर्ज में शामिल करने के लिए करना चाहता था: /

— -हो

वास्तव में गिट दोनों पक्षों की फाइलों में जोड़े गए रिटर्न के साथ है git ls-files --modifiedइसलिए मुझे लगता है कि यह भी एक व्यवहार्य समाधान है।

— औरो

इसे भी जोड़ने के लिए धन्यवाद। अधिक बार तो फ़ाइल-दर-फ़ाइल आधार पर इसकी आवश्यकता नहीं होती है। इसके अलावा, जीआईटी स्थिति बहुत नीचे "अनमर्ज्ड पाथ्स" दिखाती है। अनसुलझे रास्तों की सूची प्राप्त करने के लिए, मैं इस उपनाम का उपयोग करता हूं:git config --global alias.unresolved '!git status --short|egrep "^([DAU])\1"'

— मेल्विन

क्या का अर्थ है -Xऔर क्या बीच का अंतर है -Xऔर -s? कोई दस्तावेज नहीं मिल रहा है।

— लेई यांग

Answer 6

मैंने अपनी समस्या हल कर ली

git checkout -m old
git checkout -b new B
git merge -s ours old

Comments

एक शाखा "बी" "पुरानी" शाखा से

— एलमर्को

Answer 7

जब मर्ज का उपयोग करके "A" में विषय शाखा "B" का विलय किया जाता है, तो मुझे कुछ उलझनें आती हैं। मैं> जानता हूं कि "बी" संस्करण का उपयोग करके सभी संघर्षों को हल किया जा सकता है।

मैं git मर्ज -s हमारे बारे में जानता हूँ। लेकिन मुझे जो चाहिए वो है git मर्ज> -s उनकी तरह।

मैं मान रहा हूं कि आपने मास्टर से एक शाखा बना ली है और अब मास्टर में किसी भी पुराने सामान को ओवरराइड करके, वापस मास्टर में विलय करना चाहते हैं। ठीक वैसा ही जब मैं इस पद पर आया था।

ठीक वैसा ही करें जैसा आप करना चाहते हैं, सिवाय एक शाखा को दूसरे में विलय करने के। मैंने बस यही किया, और इसने बहुत काम किया।

git checkout Branch
git merge master -s ours

फिर, चेकआउट मास्टर और उसमें अपनी शाखा को मर्ज करें (यह अब आसानी से चलेगा):

git checkout master
git merge Branch

Comments

धन्यवाद। यह स्वीकृत उत्तर होना चाहिए, अब तक सबसे सरल और सबसे सही। यदि आपकी शाखा मास्टर के साथ पीछे है / संघर्ष करती है, तो इसकी शाखा नौकरी को विलय करने और सब कुछ वापस करने के लिए काम करने से पहले मास्टर करने के लिए करती है।

— स्टैकहोला

यह बहुत बढ़िया काम किया, धन्यवाद।

— कोडी ग्रंथम

Answer 8

यदि आप शाखा ए पर हैं:

git merge -s recursive -X theirs B

जीआईटी संस्करण 1.7.8 पर परीक्षण किया गया

Answer 9

वास्तव में ठीक से एक मर्ज करना जो शाखा से केवल इनपुट लेता है जिसे आप विलय कर रहे हैं

git merge --strategy=ours ref-to-be-merged

git diff --binary ref-to-be-merged | git apply --reverse --index

git commit --amend

मेरे द्वारा ज्ञात किसी भी परिदृश्य में कोई संघर्ष नहीं होगा, आपको अतिरिक्त शाखाएं बनाने की आवश्यकता नहीं है, और यह सामान्य मर्ज कमिट की तरह काम करता है।

हालांकि यह सबमॉडल्स के साथ अच्छा नहीं खेलता है।

Comments

यहाँ -R क्या करता है?

— पी। मायर नोर

इस तरह से आप "स्थानांतरित और परिवर्तित" फ़ाइलों का इतिहास खो देते हैं। क्या मैं सही हू?

— इलिच

-R है-reverse, मैंने इसका उत्तर अपडेट किया है कि यह अधिक स्व-दस्तावेजीकरण हो।

— एलिजा लिन

यदि आप जिन फ़ाइलों को मर्ज करने का प्रयास कर रहे हैं, उन्हें यह काम नहीं लगता है कि आने वाली शाखा में हटा दिया जाता है।

— सॉल्यूज जे

Answer 10

इसका अस्तित्व क्यों नहीं है?

जबकि मैं " एक और की तरह एक शाखा बनाने के लिए " git कमांड में उल्लेख करता हूं कि कैसे अनुकरण करना है git merge -s theirs, ध्यान दें कि Git 2.15 (Q4 2017) अब स्पष्ट है:

-X<option>मर्ज के लिए ' ' के लिए प्रलेखन भ्रामक रूप से यह सुझाव देने के लिए लिखा गया था कि " -s theirs" मौजूद है, जो मामला नहीं है।

देखें c25d98b प्रतिबद्ध द्वारा (25 सितं, 2017) Junio सी Hamano ( gitster) ।
^{(द्वारा विलय Junio सी Hamano - gitster- में प्रतिबद्ध 4da3e23 , 28 सितं, 2017)}

मर्ज-रणनीतियाँ: " -s theirs" मौजूद होने से बचने से बचें

-Xoursमर्ज विकल्प के विवरण में एक अभिभावक नोट है जो पाठकों को बताता है कि यह बहुत अलग है -s ours, जो सही है, लेकिन इसका वर्णन -Xtheirsइस प्रकार है कि यह लापरवाही से कहता है "यह विपरीत है ours", यह गलत धारणा देता है कि पाठकों को भी इसकी आवश्यकता है चेतावनी दी जानी चाहिए कि यह बहुत अलग है -s theirs, जो वास्तव में मौजूद नहीं है।

-Xtheirsएक रणनीति विकल्प है जो पुनरावर्ती रणनीति पर लागू होता है। इसका मतलब यह है कि पुनरावर्ती रणनीति अभी भी कुछ भी विलय कर सकती है, और theirsसंघर्षों के मामले में केवल " " तर्क पर वापस आ जाएगी ।

theirsमर्ज की रणनीति के बारे में बहस या नहीं, इस सेप्ट 2017 के धागे में हाल ही में वापस लाया गया था ।
यह पुराने (2008) धागे को स्वीकार करता है

संक्षेप में, पिछली चर्चा को "हम नहीं चाहते ' -s theirs' के रूप में संक्षेपित किया जा सकता है क्योंकि यह गलत वर्कफ़्लो को प्रोत्साहित करता है"।

यह उपनाम का उल्लेख करता है:

mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u $1' -

यारोस्लाव हैलेंको उस रणनीति के लिए एक बार फिर से पैरवी करने की कोशिश करता है, लेकिन जूनियो सी। हैमनो कहते हैं :

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

एक बार जब आप तय कर लेते हैं कि उनका इतिहास मेनलाइन है, तो आप विकास की अपनी रेखा को साइड ब्रांच मानकर उस दिशा में एक मर्ज करना चाहेंगे, अर्थात परिणामी मर्ज का पहला अभिभावक अपने इतिहास और दूसरे पर कमिटमेंट करता है। माता-पिता आपके इतिहास का अंतिम बुरा है। तो आप checkout their-history && merge -s ours your-historyपहले-पितृत्व को समझदार बनाए रखने के लिए " " का उपयोग करेंगे ।

और उस बिंदु पर, " -s ours" का उपयोग अब " -s theirs" की कमी के लिए एक समाधान नहीं है ।
यह वांछित शब्दार्थों का एक उचित हिस्सा है, अर्थात् जीवित विहित इतिहास रेखा के दृष्टिकोण से, आप यह संरक्षित करना चाहते हैं कि इसने क्या किया, यह बताकर कि इतिहास की दूसरी पंक्ति ने क्या किया ।

जूनियो कहते हैं, माइक बीटन द्वारा टिप्पणी के रूप में :

git merge -s ours <their-ref>प्रभावी रूप से कहते हैं ' <their-ref>स्थायी रूप से नजरअंदाज किए जाने के रूप में अपनी शाखा पर किए गए निशान शुरू होते हैं ';
और यह इसलिए मायने रखता है, क्योंकि यदि आप बाद में उनकी शाखा के बाद के राज्यों से विलय कर देते हैं, तो बाद में उनके द्वारा किए गए परिवर्तनों को अनदेखा किए बिना लाया जाएगा ।

Comments

यह एक उपयोगी उत्तर है, लेकिन इसमें एक महत्वपूर्ण बिंदु का उल्लेख नहीं किया गया है, जिसे मैं सिर्फ जूनियो सी। हामानो के उत्तर से समझ पाया हूं: git merge -s ours <their-ref>प्रभावी रूप से कहता है कि 'अपनी शाखा पर <उनके रेफरी> के रूप में किए गए निशान स्थायी रूप से नजरअंदाज किए जाते हैं। '; और इस मामले, क्योंकि अगर आप बाद में उनके शाखा के बाद राज्यों से जोड़ देते बाद में सभी परिवर्तनों को अनदेखा बदलाव के बिना में लाया जाएगा कभी में लाया जा रहा है।

— MikeBeaton

@MikeBeaton धन्यवाद। अधिक दृश्यता के उत्तर में मैंने आपकी टिप्पणी शामिल की है।

— VonC

Answer 11

देखें जूनियो हमानो के व्यापक रूप से उद्धृत जवाब : आप प्रतिबद्ध सामग्री त्यागने के लिए जा रहे हैं, बस करता त्यागने, या किसी भी दर पर मुख्य इतिहास के लिए इसे बाहर रहते हैं। भविष्य में पढ़ने वाले हर व्यक्ति को कमिट से ऐसे संदेश क्यों परेशान करते हैं जिनके पास कुछ भी नहीं है?

लेकिन कभी-कभी प्रशासनिक आवश्यकताएं होती हैं, या शायद कुछ और कारण। उन स्थितियों के लिए जहां आपको वास्तव में कमिट करना है जो कुछ भी योगदान नहीं करते हैं, आप चाहते हैं:

(संपादित करें: वाह, क्या मैंने इसे पहले गलत करने का प्रबंधन किया था। यह काम करता है।)

git update-ref HEAD $(
        git commit-tree -m 'completely superseding with branchB content' \
                        -p HEAD -p branchB    branchB:
)
git reset --hard

Answer 12

यह एक git प्लंबिंग कमांड रीड-ट्री का उपयोग करता है, लेकिन कम समग्र वर्कफ़्लो के लिए बनाता है।

git checkout <base-branch>

git merge --no-commit -s ours <their-branch>
git read-tree -u --reset <their-branch>
git commit

# Check your work!
git diff <their-branch>

Answer 13

यह आपके newBranch को मौजूदा baseBranch में मर्ज कर देगा

git checkout <baseBranch> // this will checkout baseBranch
git merge -s ours <newBranch> // this will simple merge newBranch in baseBranch
git rm -rf . // this will remove all non references files from baseBranch (deleted in newBranch)
git checkout newBranch -- . //this will replace all conflicted files in baseBranch

Comments

मैं git commit --amendआपके उदाहरण के अंत में जोड़ने का सुझाव दूंगा , या उपयोगकर्ता मर्ज कमिटमेंट देख सकते हैं git logऔर मान सकते हैं कि ऑपरेशन पूरा हो गया है।

— माइकल आर

Answer 14

मुझे लगता है कि आप वास्तव में क्या चाहते हैं:

git checkout -B mergeBranch branchB
git merge -s ours branchA
git checkout branchA
git merge mergeBranch
git branch -D mergeBranch

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

Answer 15

समतुल्य (जो मूल आदेश रखता है) 'git मर्ज -s उनकी शाखा शाखा'

मर्ज करने से पहले:

!!! सुनिश्चित करें कि आप स्वच्छ स्थिति में हैं !!!

मर्ज करें:

git commit-tree -m "take theirs" -p HEAD -p branchB 'branchB^{tree}'
git reset --hard 36daf519952 # is the output of the prev command

हमने क्या किया ? हमने एक नई कमेटी बनाई, जिसमें दो माता-पिता हमारे और उनके और कमिटमेंट के कंटेस्टेंट हैं-BB

मर्ज करने के बाद:

ज्यादा ठीक:

git commit-tree -m "take theirs" -p HEAD -p 'SOURCE^{commit}' 'SOURCE^{tree}'

Answer 16

यह जवाब पॉल प्लाडीज ने दिया। मैंने बस उसकी आज्ञा ली और सुविधा के लिए एक उपनाम दिया।

अपना .ITconfig संपादित करें और निम्नलिखित जोड़ें:

[alias]
    mergetheirs = "!git merge -s ours \"$1\" && git branch temp_THEIRS && git reset --hard \"$1\" && git reset --soft temp_THEIRS && git commit --amend && git branch -D temp_THEIRS"

फिर आप "git मर्ज -s उनकी ए" को चलाकर कर सकते हैं:

git checkout B (optional, just making sure we're on branch B)
git mergetheirs A

Answer 17

मुझे हाल ही में दो अलग-अलग रिपॉजिटरी के लिए ऐसा करने की आवश्यकता थी जो एक सामान्य इतिहास साझा करते हैं। मैंने इसके साथ शुरुआत की:

• Org/repository1 master
• Org/repository2 master

मैं चाहता था कि उन सभी परिवर्तनों repository2 masterको लागू किया जाए repository1 master, जो रिपॉजिटरी 2 में किए गए सभी परिवर्तनों को स्वीकार करेंगे। Git के संदर्भ में, यह एक रणनीति होनी चाहिए जिसे -s theirsBUT कहा जाता है, यह मौजूद नहीं है। सावधान रहें क्योंकि -X theirsइसका नाम ऐसा है जैसा आप चाहते हैं, लेकिन यह नहीं है समान है (यह मैन पेज में भी ऐसा कहता है)।

जिस तरह से मैंने इसे हल किया वह repository2एक नई शाखा में जाने और बनाने के लिए था repo1-merge। उस शाखा में, मैं भागाgit pull [e-mail]:Org/repository1 -s ours और यह बिना किसी समस्या के ठीक हो । मैं फिर इसे रिमोट पर धकेलता हूं।

फिर मैं वापस जाता हूं repository1और एक नई शाखा बनाता हूं repo2-merge। उस शाखा में, मैं दौड़ता हूंgit pull [e-mail]:Org/repository2 repo1-merge जो मुद्दों के साथ पूरा होगा।

अंत में, आपको या तो repository1इसे नया मास्टर बनाने के लिए एक मर्ज अनुरोध जारी करने की आवश्यकता होगी , या बस इसे एक शाखा के रूप में रखना होगा।

Answer 18

एक सरल और सहज (मेरी राय में) यह करने का दो-चरण तरीका है

git checkout branchB .
git commit -m "Picked up the content from branchB"

के बाद

git merge -s ours branchB

(जो विलय के रूप में दो शाखाओं को चिह्नित करता है)

एकमात्र नुकसान यह है कि यह उन फ़ाइलों को नहीं हटाता है जो आपकी वर्तमान शाखा से शाखा में हटा दी गई हैं। बाद में दो शाखाओं के बीच एक सरल अंतर दिखाएगा कि क्या कोई ऐसी फाइलें हैं।

यह दृष्टिकोण भी संशोधन लॉग से स्पष्ट करता है कि बाद में क्या किया गया था - और क्या इरादा था।

Comments

यह मूल प्रश्न के लिए सही हो सकता है, हालांकि ओपी ने 2008 में प्रश्न को इस तरह से अद्यतन किया कि यह उत्तर गलत है।

— user3338098

@ user3338098 हाँ, इस तरह का अफ़सोस कि उन्होंने भ्रामक शीर्षक छोड़ दिया और सिर्फ सवाल शरीर के अंत में एक नहीं इतना अद्यतन अद्यतन को थप्पड़ मार दिया .... क्योंकि यह जवाब सही ढंग से शीर्षक सवाल का जवाब देता है ।

— रोमेनैवेलेरी

मैं @RomainValeri

— AppleCiderGuy