2012-12-11 10 views
35

जब मैं git rebase branch1 अपने branch1-local में करता हूं तो मुझे संघर्ष मिलते हैं। मैं संघर्ष को हल करता हूं, git add <conflicted-add> करता हूं और फिर git rebase --continue करता हूं क्योंकि गिट मुझे करने के लिए कहता है। उसके बाद एक नई प्रतिबद्धता लागू की जाती है। एक नया संघर्ष दिखाता है। लेकिन फिर भी वही संघर्ष है! एक ही फाइल! मैं इसे फिर से करता हूं, git add, git rebase --continue, और तब यह सब दोबारा दोहराया जाता है जब तक कि मैं प्रत्येक प्रतिबद्धता के लिए इसे दोहराने के लिए दोहराता हूं।मुझे एक ही संघर्ष को और अधिक हल करने के लिए क्यों करना है?

मुझे दोबारा एक ही संघर्ष समाधान फिर से दोबारा क्यों दोबारा दोबारा शुरू कर रहा है?

+1

मैंने इसका कभी भी उपयोग नहीं किया, मैंने मुश्किल से अपने दस्तावेज़ों को पढ़ा, लेकिन 'गिट रीरेरे' पर एक नज़र डालें, AFAIK का प्रयोग संघर्ष समाधानों को "रिकॉर्ड" करने और उन्हें दोहराने से बचने के लिए किया जाता है। इस सुविधा के सामान्य गेटचास के लिए http://stackoverflow.com/q/5519244/236871 पर एक नज़र डालें। – KurzedMetal

+0

क्या आपने कभी यह पता लगाया कि ऐसा क्यों हुआ? मेरे पास अन्य लोग एक ही बात की रिपोर्ट कर रहे थे और मैं ऐसी स्थिति का पुनर्निर्माण करने में सक्षम होना चाहूंगा जहां मुझे रीबेज के दौरान * सटीक एक ही विवाद समाधान * कई बार लागू करना होगा। – Christoph

+1

हां, समाधान कभी भी * कभी भी * रीबेज 'का उपयोग कभी नहीं करना था। 'पुल',' मर्ज 'और' एड 'के साथ हल करें, आपको कभी भी – lurscher

उत्तर

10

आप क्या चाहते हैं git rerere जो आपके लिए संघर्ष समाधान रिकॉर्ड करता है। मैंने देखा है कि सबसे अच्छा परिचय from this blog article है। प्रैक्टिस में जब आप रीबेज करते हैं, तो आप पहले की तरह रोकना बंद कर देंगे लेकिन आपको केवल मर्ज विवाद को हल करना होगा, फिर git add इसे हल करना जारी रखें।

0

आपको एक ही संघर्ष नहीं हो रहा है। रीरेरे आपकी मदद नहीं करेगा। इसका मतलब यह है कि जिस कोडबेस को आप फिर से चलाने की कोशिश कर रहे हैं वह इतना अलग है कि प्रत्येक प्रतिबद्ध को इसे समायोजित करने में आपकी सहायता की आवश्यकता होती है। यह रिबेस पर विलय का पक्ष लेने के कारणों में से एक है। रीबेस का उपयोग केवल तभी किया जाना चाहिए जब आवश्यक हो और आपके नियमित वर्कफ़्लो का हिस्सा न हो। रीरे एक मर्ज/रीसेट प्रकार वर्कफ़्लो में बहुत अधिक मदद करेगा। यहां मेरा वर्कफ़्लो है जो रीबेजिंग से बचाता है: http://dymitruk.com/blog/2012/02/05/branch-per-feature/

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

+1

, मैं व्यक्तिगत रूप से विलय का पक्ष लेता हूं (मैंने इसे अन्य परियोजनाओं में सफलतापूर्वक उपयोग किया है, जितना गड़बड़ नहीं है) लेकिन यह नई टीम रीबेज का उपयोग करना चाहती है क्योंकि यह विलय का पेड़ "साफ" दिखता है, और भगवान जानता है कि एक साफ दिखने वाला पेड़ केवल एक बार संघर्ष को ठीक करता है (विशेष रूप से जब लीड पेड़ को देखना चाहता है तो वह कोई संघर्ष समाधान नहीं कर रहा है) – lurscher

+0

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

+0

मेरी इच्छा है, लेकिन संघर्ष संकल्प पीड़ित मेरे ऊपर होगा। लेकिन मैं विलय के लिए कुछ वकालत करने की कोशिश करूंगा। धन्यवाद! – lurscher

संबंधित मुद्दे

 संबंधित मुद्दे