गिट: एक छोटी, लेकिन बहुत पुरानी शाखा कैसे विलय करें?

Question

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

A 
| 
X---(a few changes)--- B 
| 
|(hundreds of changes) 
| 
HEAD/master 

अगर मैं शाखा से "Git मर्ज मास्टर" करते हैं, कई मर्ज संघर्ष दिखाए जाते हैं, क्योंकि बी और सिर अब बहुत अलग हैं। लेकिन ऐसा लगता है (मूर्खतापूर्ण, मेरे लिए) गलत: बी ट्रंक से बहुत दूर नहीं है, यह समय पर वापस एक लंबा रास्ता है।

क्या इस तथ्य का लाभ उठाने का कोई तरीका है? क्या मुझे कोशिश करनी चाहिए और पहले बी को वापस एक्स में विलय करना चाहिए, फिर वहां से हेड तक? क्या आदेश होगा:

1. पहचानें संशोधन एक्स
कि नई विलय संस्करण से
3. अद्यतन सिर के

है एक्स के साथ बी और एक्स

मर्ज बी के बीच मतभेदों को देखें वहां एक और दृष्टिकोण है कि लोग इन परिस्थितियों में उपयोग करते हैं?

(काफी संभवतः मैं ने कहा है कि पूर्ववर्ती में कुछ बहुत ही बेवकूफ और अन-Git-तरह बातें - उन्हें बाहर बात करने के लिए स्वतंत्र लग रहा है :)।)

Answer 1

एक नई शाखा "एक्स" बनाना बिंदु है जहां बी से और मास्टर अलग हो गए और फिर बी में एक्स विलय करने से आपकी मदद नहीं होगी। यह बस एक तेजी से आगे विलय होगा; सचमुच बी में मास्टर विलय के कारण होने वाले संघर्षों के लिए कोई परिवर्तन नहीं होगा। आपका एकमात्र विकल्प बी के विलय को मास्टर में करना और संघर्षों को संबोधित करना है। संघर्ष वे हैं जो वे हैं, और उनके आसपास "चारों ओर" कोई रास्ता नहीं है।

Answer 2

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

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

git rebase version-2 old-branch 
# deal with conflicts if they happen 
git rebase version-3 old-branch 
# and so on... 
# until old-branch is based on a recent version 
git checkout master 
git merge old-branch 

यह प्रभावी रूप से आप के बजाय एक ही बार में यह सब से निपटने का, हर कदम में छोटे परिवर्तन से निपटने के जाने हैं।