सवाल गिट में विलय विवादों को कैसे हल करें


क्या गिट में विलय विवादों को हल करने का तरीका समझाने का एक अच्छा तरीका है?


4134
2017-10-02 11:31


मूल


निम्न ब्लॉग पोस्ट गिट के साथ मर्ज टकराव को संभालने के तरीके पर एक बहुत अच्छा उदाहरण देता है जो आपको सही दिशा में ले जाना चाहिए। गिट में संघर्ष और संघर्ष से बचें - mwilliams
आप एक मर्ज टूल कॉन्फ़िगर कर सकते हैं (kdiff3 jebaird.com/2013/07/08/...) और फिर गिट mergetool का उपयोग करें। जब आप बड़ी डेवलपर टीमों में काम कर रहे हों तो आप हमेशा मर्ज विवादों का सामना करेंगे। - Grady G Cooper
यह न भूलें कि आप नियमित रूप से डाउनस्ट्रीम विलय करके अधिकांश मर्ज विवादों को कम कर सकते हैं! - Ant P
और देखें git-tower.com/learn/git/ebook/command-line/tools-services/... - Pacerier
यह एक विस्तृत ट्यूटोरियल प्रतीत होता है - githubtraining.com/fix-merge-conflict-git-using-sourcetree - Rajavanya Subramaniyan


जवाब:


प्रयत्न: git mergetool

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

@JoshGlover टिप्पणी के अनुसार:

आदेश तब तक एक जीयूआई नहीं खोलता जब तक आप एक स्थापित नहीं करते। चल रहा है git mergetool मेरे लिए परिणामस्वरूप vimdiff उपयोग किया जा रहा है। आप इसके बजाय इसका उपयोग करने के लिए निम्न में से एक टूल इंस्टॉल कर सकते हैं: meld, opendiff, kdiff3, tkdiff, xxdiff, tortoisemerge, gvimdiff, diffuse, ecmerge, p4merge, araxis, vimdiff, emerge

उपयोग करने के लिए नमूना प्रक्रिया नीचे है vimdiff हल विलय संघर्ष के लिए। पर आधारित यह लिंक

चरण 1: अपने टर्मिनल में निम्न आदेश चलाएं

git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false

यह vimdiff को डिफ़ॉल्ट मर्ज टूल के रूप में सेट करेगा।

चरण 2: टर्मिनल में निम्न आदेश चलाएं

git mergetool

चरण 3: आप निम्नलिखित प्रारूप में एक vimdiff प्रदर्शन देखेंगे

  +----------------------+
  |       |      |       |
  |LOCAL  |BASE  |REMOTE |
  |       |      |       |
  +----------------------+
  |      MERGED          |
  |                      |
  +----------------------+

ये 4 विचार हैं

स्थानीय - यह वर्तमान शाखा से फाइल है

आधार - सामान्य पूर्वज, दोनों परिवर्तनों से पहले फ़ाइल को कैसे देखा जाता था

रिमोट - फाइल जो आप अपनी शाखा में विलय कर रहे हैं

मर्ज किया गया - परिणाम विलय करें, यह रेपो में सहेजा जाता है

आप इन विचारों के बीच नेविगेट कर सकते हैं ctrl+w। आप सीधे मर्ज किए गए दृश्य तक पहुंच सकते हैं ctrl+w के बाद j

Vimdiff नेविगेशन के बारे में अधिक जानकारी यहाँ तथा यहाँ

चरण 4। आप निम्नलिखित तरीके से मर्ज किए गए दृश्य को संपादित कर सकते हैं

यदि आप रिमोट से परिवर्तन प्राप्त करना चाहते हैं

:diffg RE  

यदि आप BASE से परिवर्तन प्राप्त करना चाहते हैं

:diffg BA  

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

:diffg LO 

चरण 5। सहेजें, बाहर निकलें, प्रतिबद्ध करें और साफ़ करें

:wqa बचाओ और वी से बाहर निकलें

git commit -m "message"

git clean Diff टूल द्वारा बनाई गई अतिरिक्त फ़ाइलों को निकालें (उदा। * .Orig)।


2425
2017-10-02 17:50



एफवाईआई आप उपयोग कर सकते हैं git mergetool -y यदि आप एक साथ कई फाइलों को विलय कर रहे हैं तो कुछ कीस्ट्रोक को सहेजने के लिए। - davr
खैर, जब तक आप एक स्थापित नहीं करते हैं, तब तक यह एक जीयूआई नहीं खोलता है। चल रहा है git mergetool मेरे लिए परिणामस्वरूप vimdiff उपयोग किया जा रहा है। आप इसके बजाय इसका उपयोग करने के लिए निम्न में से एक टूल इंस्टॉल कर सकते हैं: meld opendiff kdiff3 tkdiff xxdiff tortoisemerge gvimdiff diffuse ecmerge p4merge araxis vimdiff emerge। - Josh Glover
अच्छा बिंदु जोश। उबंटू पर मैंने मिलल्ड के साथ सबसे अच्छा भाग्य लिया है, इसके तीन तरीके विलय प्रदर्शन खराब नहीं है। ओएसएक्स गिट पर एक अच्छा डिफ़ॉल्ट चुना। - Peter Burns
यह KDiff3 खोला गया। जो मेरे पास बिल्कुल उपयोग नहीं है कि कैसे उपयोग करें। - David Murdoch
मुझे समझ में नहीं आ रहा है कि इस जवाब को इतने सारे अपवॉट क्यों प्राप्त हुए, यह वास्तव में बहुत उपयोगी नहीं है क्योंकि इसमें केवल एक ही आज्ञा है और बिल्कुल इसका कोई स्पष्टीकरण नहीं है कि इसका उपयोग कैसे किया जाए। जैसा कि अन्य ने कहा, यह एक विमडिफ खोला गया और यहां तक ​​कि अगर मुझे पता है कि विम का उपयोग कैसे करें (कम से कम खिड़कियां स्विच करें या उन्हें बंद करें) मुझे यह भी नहीं पता कि प्रत्येक विंडो किस प्रकार प्रतिनिधित्व करती है और न ही परिवर्तनों की तुलना या स्वीकार कैसे करती है। यह जानना अच्छा लगता है कि ऐसा आदेश है, लेकिन इसका उपयोग करने या अन्य तीसरे टूल्स को स्थापित करने के बारे में कोई स्पष्टीकरण नहीं है, यह बेकार जवाब है - Petr


शीर्ष पर एक संभावित उपयोग-केस यहां दिया गया है:

आप कुछ बदलाव खींचने जा रहे हैं, लेकिन ओह, आप अद्यतित नहीं हैं:

git fetch origin
git pull origin master

From ssh://gitosis@example.com:22/projectname
 * branch            master     -> FETCH_HEAD
Updating a030c3a..ee25213
error: Entry 'filename.c' not uptodate. Cannot merge.

तो आप अद्यतित हो जाते हैं और पुनः प्रयास करते हैं, लेकिन एक संघर्ष है:

git add filename.c
git commit -m "made some wild and crazy changes"
git pull origin master

From ssh://gitosis@example.com:22/projectname
 * branch            master     -> FETCH_HEAD
Auto-merging filename.c
CONFLICT (content): Merge conflict in filename.c
Automatic merge failed; fix conflicts and then commit the result.

तो आप परिवर्तनों पर नज़र डालने का फैसला करते हैं:

git mergetool

ओह, ओह, अपस्ट्रीम ने कुछ चीजें बदल दीं, लेकिन सिर्फ मेरे परिवर्तनों का उपयोग करने के लिए ... नहीं ... उनके परिवर्तन ...

git checkout --ours filename.c
git checkout --theirs filename.c
git add filename.c
git commit -m "using theirs"

और फिर हम अंतिम बार कोशिश करते हैं

git pull origin master

From ssh://gitosis@example.com:22/projectname
 * branch            master     -> FETCH_HEAD
Already up-to-date.

टा-दा!


1610
2017-08-04 17:04



यह बहुत उपयोगी था क्योंकि मेरे पास द्विआधारी फाइलों (कला संपत्तियों) के साथ बहुत सारी त्रुटियां थीं और विलय करना हमेशा असफल रहता है, इसलिए मुझे इसे हमेशा नई फ़ाइल के साथ ओवरराइट करना होगा और "विलय" नहीं करना होगा - petrocket
सावधान! --Ours और --theirs का अर्थ उलट दिया गया है। --ours == रिमोट। --theirs == स्थानीय। देख git merge --help - mmell
मेरे मामले में, मैं पुष्टि करता हूं कि --theirs = रिमोट रिपोजिटरी, --ours = मेरा खुद का स्थानीय भंडार। यह @mmell टिप्पणियों के विपरीत है। - Aryo
जाहिर है, @mmell केवल एक rebase पर। देख this question - Navin
दोस्तों, "हमारा" और "उनका" इस बात से संबंधित है कि आप विलय कर रहे हैं या नहीं। अगर तुम हो विलय, फिर "हमारा" का मतलब है कि जिस शाखा में आप विलय कर रहे हैं, और "उनका" वह शाखा है जिसमें आप विलय कर रहे हैं। जब आप हों रिबेसिंग, फिर "हमारा" का मतलब है कि आप जिस पर काम कर रहे हैं, जबकि "उनका" उन कार्यों को संदर्भित करता है जिन्हें आप रीबेज करना चाहते हैं।


मुझे लगता है कि विलय उपकरण शायद ही कभी मुझे संघर्ष या संकल्प को समझने में मदद करते हैं। मैं आम तौर पर पाठ संपादक में संघर्ष मार्करों को देखकर और पूरक के रूप में गिट लॉग का उपयोग करके अधिक सफल हूं।

यहां कुछ सलाह हैं:

टिप वन

सबसे अच्छी बात यह है कि "diff3" विलय संघर्ष शैली का उपयोग करना है:

git config merge.conflictstyle diff3

यह इस तरह के संघर्ष मार्कर पैदा करता है:

<<<<<<<
Changes made on the branch that is being merged into. In most cases,
this is the branch that I have currently checked out (i.e. HEAD).
|||||||
The common ancestor version.
=======
Changes made on the branch that is being merged in. This is often a 
feature/topic branch.
>>>>>>>

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

यदि संघर्ष केवल कुछ पंक्तियां है, तो यह आम तौर पर संघर्ष को बहुत स्पष्ट बनाता है। (संघर्ष को ठीक करने का तरीका जानना बहुत अलग है; आपको इस बात से अवगत होना चाहिए कि अन्य लोग क्या काम कर रहे हैं। अगर आप उलझन में हैं, तो शायद उस व्यक्ति को अपने कमरे में बुलाएं, ताकि वे देख सकें कि आप क्या देख रहे हैं पर।)

यदि संघर्ष लंबा है, तो मैं तीनों खंडों में से प्रत्येक को तीन अलग-अलग फाइलों में कट और पेस्ट कर दूंगा, जैसे कि "मेरा", "सामान्य" और "उनका"।

फिर मैं दो कमांड शिकारी देखने के लिए निम्न आदेश चला सकता हूं जो संघर्ष का कारण बनते हैं:

diff common mine
diff common theirs

यह मर्ज टूल का उपयोग करने जैसा नहीं है, क्योंकि मर्ज टूल में सभी गैर-विरोधाभासी diff शिकारी भी शामिल होंगे। मुझे लगता है कि विचलित होना है।

टिप दो

किसी ने पहले से ही इसका उल्लेख किया है, लेकिन प्रत्येक diff हंक के पीछे इरादे को समझना आम तौर पर यह समझने में बहुत उपयोगी होता है कि एक संघर्ष कहाँ से आया और इसे कैसे संभाला जाए।

git log --merge -p <name of file>

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

टिप तीन

स्वचालित उपकरणों के साथ अपने परिवर्तन सत्यापित करें।

यदि आपके पास स्वचालित परीक्षण हैं, तो उनको चलाएं। अगर आपके पास एक है एक प्रकार का वृक्ष, इसे चलाओ। यदि यह एक बिल्ड करने योग्य प्रोजेक्ट है, तो इसे प्रतिबद्ध करने से पहले इसे बनाएं, आदि। सभी मामलों में, आपको यह सुनिश्चित करने के लिए थोड़ा परीक्षण करना होगा कि आपके परिवर्तनों ने कुछ भी तोड़ दिया नहीं है। (बिल्ली, संघर्ष के बिना भी विलय कार्य कोड तोड़ सकता है।)

टिप चार

आगे की योजना; सहकर्मियों के साथ संवाद करें।

आगे की योजना बनाना और दूसरों के बारे में जागरूक होने के बारे में जागरूक होने से विवादों को विलय रोकने में मदद मिल सकती है और / या उन्हें पहले हल करने में मदद मिल सकती है - जबकि विवरण अभी भी दिमाग में ताजा हैं।

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

कोड के बड़े हिस्से में कटौती करने वाले प्रमुख रिफैक्टरिंग के लिए, आपको दृढ़ता से काम करने पर विचार करना चाहिए: हर कोई कोड के उस क्षेत्र पर काम करना बंद कर देता है जबकि एक व्यक्ति पूर्ण रिफैक्टरिंग करता है।

यदि आप क्रमशः काम नहीं कर सकते हैं (शायद समय के दबाव के कारण), तो अपेक्षित विलय संघर्षों के बारे में संचार करना कम से कम समस्याओं को हल करने में आपकी मदद करता है जबकि विवरण अभी भी दिमाग में ताजा हैं। उदाहरण के लिए, यदि एक सह-कार्यकर्ता एक हफ्ते की अवधि के दौरान एक विघटनकारी श्रृंखला बना रहा है, तो आप उस सप्ताह के दौरान प्रत्येक दिन एक या दो बार उस सहकर्मियों की शाखा में विलय / पुन: विलय करना चुन सकते हैं। इस तरह, यदि आप विलय / विवाद विवादों को पाते हैं, तो आप एक बड़े गांठ में सबकुछ एक साथ मर्ज करने के लिए कुछ हफ्तों तक प्रतीक्षा करते हैं, तो आप उन्हें अधिक तेज़ी से हल कर सकते हैं।

टिप पांच

यदि आप विलय के बारे में अनिश्चित हैं, तो इसे मजबूर मत करो।

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

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


685
2017-09-28 21:08



Diff3 विकल्प विलय के साथ एक महान विशेषता है। एकमात्र जीयूआई जो मैंने पार किया है, यह दिखाता है कि यह पर्सफोर्स है p4merge, जिसे स्थापित किया जा सकता है और पेर्सफोर्स के अन्य टूल्स से अलग इस्तेमाल किया जा सकता है (जिसे मैंने उपयोग नहीं किया है, लेकिन शिकायतों के बारे में सुना है)। - alxndr
इंटरनेट पर "यह आपके मर्ज विवादों को ठीक करने के तरीके" के बारे में यह सबसे अच्छा ट्यूटोरियल है! - Venkat Sudheer Reddy Aedama
यह जवाब वह है जो वोटों के योग्य है; उपर्युक्त दो जो मतों से बाढ़ में हैं; - DJphy
एक रिबेस प्रयास के बाद जिसके परिणामस्वरूप विलय विवाद हुआ: $ git log --merge -p build.xml आउटपुट: घातक: - MERGE_HEAD के बिना कम करें? - Ed Randall
क्या होगा अगर मेरे पास शाखा 1 से एक फ़ाइल में परिवर्तन हो और शाखा 2 में उस फ़ाइल को हटा दिया जाए। मैं उस विलय संघर्ष को कैसे हल कर सकता हूं? क्या गिट का उपयोग करने का कोई तरीका है जहां मैं एक शाखा के परिवर्तनों को रखकर उन्हें विलय कर सकता हूं? - Honey


  1. पहचानें कि कौन सी फाइलें संघर्ष में हैं (गिट आपको यह बताना चाहिए)।

  2. प्रत्येक फ़ाइल खोलें और diffs की जांच करें; गिट उन्हें बताता है। उम्मीद है कि यह स्पष्ट होगा कि प्रत्येक ब्लॉक का कौन सा संस्करण रखना है। आपको कोड करने वाले साथी डेवलपर्स के साथ चर्चा करने की आवश्यकता हो सकती है।

  3. एक बार जब आप एक फ़ाइल में संघर्ष हल कर लेंगे git add the_file

  4. एक बार आप हल हो गए हैं सब संघर्ष, करो git rebase --continue या जो भी आदेश गिट ने पूरा करने के लिए कहा था।


321
2017-10-02 12:41



@ जस्टिन गिट के बारे में सोच के रूप में सोचो सामग्री फ़ाइलों को ट्रैक करने के बजाय। फिर यह देखना आसान है कि आपने जो सामग्री अपडेट की है नहीं है भंडार में और जोड़ने की जरूरत है। सोचने का यह तरीका यह भी बताता है कि क्यों गिट खाली फ़ोल्डरों को ट्रैक नहीं करता है: हालांकि वे तकनीकी रूप से फाइलें हैं, ट्रैक करने के लिए कोई सामग्री नहीं है। - Gareth
सामग्री वहां है, संघर्ष होता है क्योंकि सामग्री के 2 संस्करण होते हैं। इसलिए "गिट एड" सही नहीं लगता है। और यह काम नहीं करता है (गिट एड, गिट प्रतिबद्ध) यदि आप संघर्ष के बाद केवल एक ही फाइल को प्रतिबद्ध करना चाहते हैं ("घातक: विलय के दौरान आंशिक प्रतिबद्धता नहीं कर सकता।") - Dainius
हां, तकनीकी रूप से, यह सवाल पूछता है जैसा कि पूछा गया है, लेकिन मेरी राय में, एक उपयोगी उत्तर नहीं है, क्षमा करें। क्या है बिंदु एक शाखा को दूसरे के समान बनाना? बेशक एक विलय संघर्ष होगा .. - Thufir
Thulfir: एक शाखा बनाने के बारे में कुछ भी किसने कहा था? ऐसे कई परिदृश्य हैं जहां आपको "एक शाखा को दूसरे के समान बनाने" के बिना विलय करने की आवश्यकता है। एक ऐसा होता है जब आप विकास शाखा के साथ होते हैं और मास्टर शाखा में अपने परिवर्तनों को शामिल करना चाहते हैं; इसके बाद, विकास शाखा हटा दी जा सकती है। एक और ऐसा तब होता है जब आप मास्टर में अंतिम अंतिम विलय को कम करने के लिए अपनी विकास शाखा को पुन: पेश करना चाहते हैं। - Teemu Leisti
@JustinGrant git add सूचकांक में चरण फाइलें; ऐसा होता है नहीं भंडार में कुछ भी जोड़ें। git commit चीजों को भंडार में जोड़ता है। यह उपयोग विलय के लिए समझ में आता है - विलय स्वचालित रूप से उन सभी परिवर्तनों को चरणबद्ध करता है जिन्हें स्वचालित रूप से विलय किया जा सकता है; बाकी परिवर्तनों को मर्ज करना और आपके द्वारा किए जाने पर इंडेक्स में जोड़ने की आपकी ज़िम्मेदारी है। - Mark E. Haase


स्टैक ओवरफ़्लो प्रश्न में उत्तर देखें गिट में एक विलय को छोड़ना, ख़ास तौर पर चार्ल्स बेली का जवाब जो दिखाता है कि फ़ाइल के विभिन्न संस्करणों को समस्याओं के साथ कैसे देखना है, उदाहरण के लिए,

# Common base version of the file.
git show :1:some_file.cpp

# 'Ours' version of the file.
git show :2:some_file.cpp

# 'Theirs' version of the file.
git show :3:some_file.cpp

97
2017-10-03 15:15



"Git checkout -m" को "-m" विकल्प भी देखें - यह आपको विभिन्न कार्यस्थलों को वापस अपने कार्यक्षेत्र में निकालने की अनुमति देता है - qneill
यह मुझे बचाया। प्रत्येक फाइल को अलग-अलग देखते हुए मुझे याद रखने की इजाजत दी गई कि मैं प्रत्येक शाखा में क्या कर रहा था। तो मैं चुनने का फैसला कर सकता था। - Rohmer


संघर्ष विलय तब होता है जब एक ही समय में एक फ़ाइल में परिवर्तन किए जाते हैं। यहां हल करने का तरीका बताया गया है।

git CLI

जब आप विवादित स्थिति में जाते हैं तो सरल कदम यहां दिए गए हैं:

  1. विवादित फ़ाइलों की सूची के साथ नोट करें: git status (के अंतर्गत Unmerged paths अनुभाग)।
  2. प्रत्येक फ़ाइल के लिए अलग-अलग दृष्टिकोणों में से एक द्वारा विवादों को अलग-अलग हल करें:

    • संघर्षों को हल करने के लिए जीयूआई का प्रयोग करें: git mergetool (सबसे आसान तरीका)।

    • दूरस्थ / अन्य संस्करण को स्वीकार करने के लिए, उपयोग करें: git checkout --theirs path/file। यह उस फ़ाइल के लिए किए गए किसी भी स्थानीय परिवर्तन को अस्वीकार कर देगा।

    • स्थानीय / हमारे संस्करण को स्वीकार करने के लिए, उपयोग करें: git checkout --ours path/file

      हालांकि आपको सावधान रहना होगा, क्योंकि रिमोट चेंज के कारण कुछ कारणों से संघर्ष किए गए थे।

      सम्बंधित: गिट में "हमारा" और "उनका" का सटीक अर्थ क्या है?

    • विवादित फ़ाइलों को मैन्युअल रूप से संपादित करें और कोड ब्लॉक के बीच देखें <<<<</>>>>> फिर संस्करण को ऊपर या नीचे से चुनें =====। देख: संघर्ष कैसे प्रस्तुत किए जाते हैं

    • पथ और फ़ाइल नाम विवादों द्वारा हल किया जा सकता है git add/git rm

  3. अंत में, उपयोग करने के लिए तैयार फ़ाइलों की समीक्षा करें: git status

    यदि आपके पास अभी भी कोई फाइल है Unmerged paths, और आपने मैन्युअल रूप से संघर्ष को हल किया है, तो गिट को यह पता चले कि आपने इसे हल किया है: git add path/file

  4. यदि सभी संघर्ष सफलतापूर्वक हल किए गए थे, तो इनके द्वारा परिवर्तनों को प्रतिबद्ध करें: git commit -a और हमेशा के रूप में दूरस्थ करने के लिए धक्का।

यह भी देखें: कमांड लाइन से एक विलय संघर्ष को हल करना गिटहब में

DiffMerge

मैंने सफलतापूर्वक उपयोग किया है DiffMerge जो विंडोज, मैकोज़ और लिनक्स / यूनिक्स पर फ़ाइलों की दृष्टि से तुलना और विलय कर सकता है।

यह ग्राफिक रूप से 3 फाइलों के बीच परिवर्तन दिखा सकता है और यह स्वचालित विलय (ऐसा करने के लिए सुरक्षित होने पर) और परिणामी फ़ाइल को संपादित करने पर पूर्ण नियंत्रण की अनुमति देता है।

DiffMerge

छवि स्रोत: DiffMerge (लिनक्स स्क्रीनशॉट)

बस इसे डाउनलोड करें और रेपो में चलाएं:

git mergetool -t diffmerge .

मैक ओ एस

मैकोज़ पर आप इसके माध्यम से स्थापित कर सकते हैं:

brew install caskroom/cask/brew-cask
brew cask install diffmerge

और शायद (यदि प्रदान नहीं किया गया है) तो आपको अपने पैथ में दिए गए अतिरिक्त अतिरिक्त सरल आवरण की आवश्यकता है (उदा। /usr/bin):

#!/bin/sh
DIFFMERGE_PATH=/Applications/DiffMerge.app
DIFFMERGE_EXE=${DIFFMERGE_PATH}/Contents/MacOS/DiffMerge
exec ${DIFFMERGE_EXE} --nosplash "$@"

फिर आप निम्न कीबोर्ड शॉर्टकट का उपयोग कर सकते हैं:

  • -ऑल्ट-ऊपर/नीचे पिछले / अगले परिवर्तनों पर कूदने के लिए।
  • -ऑल्ट-बाएं/सही बाएं या दाएं से परिवर्तन स्वीकार करने के लिए

वैकल्पिक रूप से आप इसका उपयोग कर सकते हैं opendiff (एक्सकोड टूल्स का हिस्सा) जो आपको एक तिहाई फ़ाइल या निर्देशिका बनाने के लिए दो फाइलों या निर्देशिकाओं को एक साथ मर्ज करने देता है।


88
2017-08-05 14:29





यदि आप लगातार छोटी कमियां कर रहे हैं, तो प्रतिबद्ध टिप्पणियों को देखकर शुरू करें git log --merge। फिर git diff आपको संघर्ष दिखाएगा।

उन संघर्षों के लिए जिनमें कुछ पंक्तियों से अधिक शामिल है, बाहरी जीयूआई उपकरण में क्या हो रहा है यह देखना आसान है। मुझे opendiff पसंद है - गिट भी vimdiff, gvimdiff, kdiff3, tkdiff, meld, xxdiff का समर्थन करता है, बॉक्स से बाहर निकलता है और आप दूसरों को स्थापित कर सकते हैं: git config merge.tool "your.tool" आपके चुने हुए टूल को सेट करेगा और फिर git mergetool असफल विलय के बाद आपको संदर्भ में अंतर दिखाई देगा।

प्रत्येक बार जब आप किसी विवाद को हल करने के लिए फ़ाइल संपादित करते हैं, git add filename इंडेक्स अपडेट करेगा और आपका डिफ अब इसे नहीं दिखाएगा। जब सभी संघर्षों को संभाला जाता है और उनकी फाइलें होती हैं git add-ईडी, git commit आपका विलय पूरा करेगा।


73
2017-10-02 16:11



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