विशिष्ट फ़ाइलों ("हमारा", "मेरा", "उनका") के लिए Git मर्ज रणनीति चुनें

Question

मैं एक के बाद रिबासिंग के बीच में हूं git pull --rebase। मेरे पास कुछ फाइलें हैं, जिनमें मर्ज का टकराव है। मैं विशिष्ट फ़ाइलों के लिए "उनके" परिवर्तन या "मेरे" परिवर्तनों को कैसे स्वीकार कर सकता हूं?

$ git status
# Not currently on any branch.
# You are currently rebasing.
#   (fix conflicts and then run "git rebase --continue")
#   (use "git rebase --skip" to skip this patch)
#   (use "git rebase --abort" to check out the original branch)
#
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:  CorrectlyMergedFile
#
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add <file>..." to mark resolution)
#
#       both modified: FileWhereIWantToAcceptTheirChanges
#       both modified: FileWhereIWantToAcceptMyChanges

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

इसके अलावा, ध्यान दें कि मैं केवल प्रत्येक फ़ाइल के लिए एक मर्ज रणनीति चुनने में सक्षम होऊंगा जब मैं देखता हूं कि क्या फाइल टकराती है संभवतः एक टकराव होता है।

Comments

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

— स्टीवन वेक्सलर

मैंने इस प्रश्न को अधिक सामान्य होने के लिए संपादित किया: stackoverflow.com/questions/278081/… । हो सकता है कि हम इस प्रश्न को उसी के डुप्लिकेट के रूप में बंद कर दें? क्या यह उचित है?

@ शादो मुझे उचित लगती है।

— स्टीवन वेक्सलर

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

पूरी तरह से git का उपयोग करके एक पूरी फ़ाइल पर 'अपना स्वीकार' या 'मेरा स्वीकार' करने के लिए सरल टूल की संभावित डुप्लिकेट ।

Answer 1

आपके द्वारा प्राप्त प्रत्येक विवादित फ़ाइल के लिए, आप निर्दिष्ट कर सकते हैं

git checkout --ours -- <paths>
# or
git checkout --theirs -- <paths>

से git checkoutडॉक्स

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...

--ours
--theirs
अनुक्रमणिका से पथों की जाँच करते समय , अनर्जित पथों के लिए चरण # 2 ( ours) या # 3 ( theirs) देखें।

पिछले विफल मर्ज के कारण अनुक्रमणिका में अनमैरिड प्रविष्टियाँ हो सकती हैं। डिफ़ॉल्ट रूप से, यदि आप इंडेक्स से ऐसी प्रविष्टि की जांच करने का प्रयास करते हैं, तो चेकआउट ऑपरेशन विफल हो जाएगा और कुछ भी चेक आउट नहीं होगा। का उपयोग करते हुए -fइन unmerged प्रविष्टियों की उपेक्षा करेंगे। मर्ज के एक विशिष्ट पक्ष से सामग्री का उपयोग करके --oursया सूचकांक से बाहर की जाँच की जा सकती है --theirs। साथ -m, काम कर पेड़ फाइल करने के लिए त्याग किया जा सकता करने के लिए किए गए परिवर्तनों को मूल विरोध हुआ मर्ज परिणाम फिर से बनाते हैं।

Comments

क्या उन सभी फ़ाइलों के लिए उनकी स्वीकार करना संभव है जिन्हें umerged छोड़ दिया गया है?

— aslakjo

@ दासलज्जो git rebase -s recursive -X <ours/theirs>या git merge -s recursive -X <ours/theirs>। ध्यान रखें कि एक रिबेस के लिए, "हमारा" और "उनका" एक मर्ज के दौरान क्या होता है, इससे उलट होता है। आप शायद किसी फ़ाइल / शेल ग्लब का भी उपयोग कर सकते हैं, जैसे git checkout --theirs -- *.txt।

बहुत धन्यवाद, @ चुप, रिबास के ours/theirsसाथ अप्रत्याशित उलटफेर मुझे पागल कर रहा था !! (अब यह समझ में आता है कि मैं इस बारे में सोचता हूं कि वास्तव में एक रिबास कैसे काम करता है, लेकिन सभी सहज ज्ञान युक्त नहीं।)

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

सामान्य रूप से @DanLenski रिबास केवल लोगों को समझने के लिए एक बहुत ही मुश्किल उपकरण है, लेकिन एक बार जब आप समझ जाते हैं कि यह कैसे काम करता है, तो आप इसके साथ वास्तव में सभी प्रकार की शक्तिशाली चीजें कर सकते हैं।

@VincentSels वास्तव में, आपको * चरित्र को मुखौटा करने की आवश्यकता है, अन्यथा, शेल इसे विस्तारित करने का प्रयास करेगा। इसलिए आपके मामले में आपका git checkout --outs -- "**/*.csproj"वही मतलब होगा जो आप चाहते हैं। वही सच है उदाहरण के लिए git lfs track "*.jpg"। यदि आपके CWD में कुछ jpg-फाइल्स हैं, बिना उद्धरण के, केवल इन पर नज़र रखी जाएगी।

— eFloh

Answer 2

हालांकि इस सवाल का जवाब दिया गया है, उदाहरण के लिए "उनका" और "हमारा" के रूप में एक उदाहरण प्रदान करने का अर्थ है गिट रीबेस बनाम मर्ज। इस लिंक को देखें

Git रिबेस
theirs वास्तव में के मामले में वर्तमान शाखा है रिबेस । इसलिए कमांड के नीचे सेट वास्तव में दूरस्थ शाखा पर आपके वर्तमान शाखा परिवर्तन को स्वीकार कर रहे हैं।

# see current branch
$ git branch
... 
* branch-a
# rebase preferring current branch changes during conflicts
$ git rebase -X theirs branch-b

Git मर्ज
के लिए मर्ज , के अर्थ theirsऔर oursउलट है। तो, मर्ज के दौरान समान प्रभाव प्राप्त करने के लिए , अर्थात, oursदूरस्थ शाखा में विलय की जा रही अपनी वर्तमान शाखा परिवर्तन ( ) को रखें ( theirs)।

# assuming branch-a is our current version
$ git merge -X ours branch-b  # <- ours: branch-a, theirs: branch-b

Comments

खैर, यह काफी महत्वपूर्ण अंतर है! स्पष्टीकरण देने के लिए धन्यवाद।

— मौखिक

Answer 3

ध्यान दें कि या तो या संस्करण का चयन करके फ़ाइलों को पूरी तरहgit checkout --ours|--theirs से अधिलेखित कर दिया जाएगा , जो हो सकता है या हो सकता है कि आप क्या करना चाहते हैं (यदि आपके पास दूसरी तरफ से आने वाले कोई भी गैर-विवादित परिवर्तन हैं, तो वे खो जाएंगे)।theirsours

यदि इसके बजाय आप फ़ाइल पर तीन-तरफ़ा मर्ज करना चाहते हैं, और केवल विवादित हॉक का उपयोग करके हल करते हैं --ours|--theirs, तो दोनों पक्षों से गैर-विवादित हॉक को रखते हुए , आप का सहारा लेना चाह सकते हैं git merge-file; इस उत्तर में विवरण देखें ।

Comments

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

— 22 मई को ktamlyn

@ktamlyn द्वारा "गैर-परस्पर विरोधी परिवर्तन" मेरा मतलब उसी फ़ाइल में परिवर्तन था। उदाहरण के लिए, वहाँ दो बदली हुई जिसे (भागों) में हैं example.txtमें oursसंस्करण, एक विरोध हुआ है (यह भी में बदलtheirs संशोधन), अन्य गैर विरोध हुआ है। यदि आप करते हैं git checkout --theirs example.txt, तो यह पूरी तरह से theirsसंशोधन पर पूरी फ़ाइल को नेत्रहीन पढ़ेगा , और अंतर का गैर-विवादित हिस्सा खो जाएगा।

— याकूब

धन्यवाद! मेरे लिए यह एक आवश्यक स्पष्टीकरण था, भले ही "उसी फ़ाइल में परिवर्तन" इस संदर्भ में सबसे अधिक समझ में आता है।

— ktamlyn

यह स्वीकृत उत्तर होना चाहिए, ठीक है, हालांकि यह वास्तव में एक उत्तर नहीं देता है, लेकिन अन्य प्रस्तावित समाधान में एक महत्वपूर्ण मुद्दा बताता है।

— टोमसैनी

यदि आप मूल विवादित फ़ाइल पर वापस जाना चाहते हैं तो आप चला सकते हैं git checkout --merge <path>।

— एंड्रयू केटॉन