मैं एक जटिल मर्ज के पास कैसे जा सकता हूं


25

यहाँ सौदा है, मैं एक नई कंपनी में शामिल हो गया हूँ और मुझे एक शाखा पर काम खत्म करने के लिए कहा गया है जिसे लगभग एक साल से नहीं छुआ गया है। इस बीच, मास्टर शाखा स्थिर गति से बढ़ रही है। आदर्श रूप से मैं मास्टर ब्रांच से सभी बदलावों को फीचर ब्रांच में मर्ज करना चाहता हूं और वहां से काम जारी रखना चाहता हूं, लेकिन मुझे यकीन नहीं है कि यह कैसे होगा।

मैं शाखा के दोनों किनारों पर महत्वपूर्ण परिवर्तनों को संरक्षित करते हुए सुरक्षित रूप से इस मर्ज का प्रदर्शन कैसे करूं?


भयानक प्रतिक्रिया के लिए आप सभी को धन्यवाद। मैं git-imerge को देने जा रहा हूँ और अगर वह गन्दा हो जाता है तो मैं एक नई शाखा दृष्टिकोण का उपयोग करूँगा!
व्लाद स्प्रेइज़

क्या कोई समझा सकता है कि हम git cherry-pickयहां क्यों नहीं इस्तेमाल कर सकते ?
संतोष कुमार

1. प्रार्थना। 2. छूट। 3. परीक्षण। 4. मर्ज।
AK_

1
मैं इस स्थिति में पुन: विकास करना पसंद करता हूं क्योंकि यह प्रतिबद्ध होकर जाएगा। यह मर्ज किए गए कोड को उपलब्ध कराने से पहले आपको नई सुविधा को स्क्वैश करने की भी अनुमति देगा। YMMV।
स्टीफन

जवाबों:


27

इसके दिल में, कोड के दो (संभवतः गैर-संगत) टुकड़ों को कैसे जोड़ा जाए, यह एक विकास समस्या है , न कि संस्करण नियंत्रण समस्या। इस प्रक्रिया में Git मर्ज कमांड मदद कर सकता है, लेकिन यह समस्या के आकार पर निर्भर करता है।

आधार के साथ दोनों संस्करणों की तुलना सबसे पहले समझ में आता है। यह आपको आगे ले जाने के लिए सबसे अच्छी रणनीति का विचार देगा। आपका दृष्टिकोण प्रत्येक शाखा में होने वाले परिवर्तनों की प्रकृति और ओवरलैप के आधार पर भिन्न हो सकता है।

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

बेशक, यह लगभग निश्चित रूप से मामला नहीं होगा, लेकिन सवाल यह है: इस आदर्श परिदृश्य से कितनी दूर हो जाएगा? यानी परिवर्तन कैसे हुए हैं?

इसके अलावा, पुरानी फीचर शाखा कितनी परिपक्व थी? क्या यह एक अच्छा काम करने की स्थिति में था, या नहीं (या अज्ञात)? सुविधा का कितना हिस्सा समाप्त हो गया था?

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

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


+1 "मैं नवीनतम और फिर से पुरानी सुविधा को फिर से शामिल करने का एक नया कांटा बनाने पर विचार कर सकता हूं"
मिका

1
पहला मुख्य प्रश्न है: क्या पुरानी सुविधा शाखा का निर्माण होता है? क्या यह चलता है? यदि नहीं तो अपने मर्ज का परीक्षण करना बहुत कठिन होगा।
मो।

22

अपने सीमित गित अनुभव में मैं कह सकता हूं कि कभी-कभी यह सुविधा शाखा को फिर से शुरू करने के लिए तेज़ होता है अगर मास्टर अलग हो गया हो।

कोड के पीछे के इतिहास को जाने बिना दो शाखाओं को मिला देना (यह देखते हुए कि आप अभी परियोजना में शामिल हुए हैं) वास्तव में मुश्किल है, और मुझे यकीन है कि शुरुआत से परियोजना का पालन करने वाले एक डेवलपर भी विलय में कुछ गलतियाँ करेंगे।

यह निश्चित रूप से समझ में आता है कि यदि सुविधा शाखा बहुत बड़ी नहीं है, लेकिन आप बस पुरानी सुविधा शाखा को खोलकर रख सकते हैं , फिर से मास्टर से शाखा और मैन्युअल रूप से उस सुविधा को बनाने वाले परिवर्तनों को फिर से पेश कर सकते हैं। मुझे पता है कि यह सबसे मैनुअल तरीका है, लेकिन यह आपको लापता या स्थानांतरित कोड के मामले में पूर्ण नियंत्रण में रहने की अनुमति देता है।

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

मैंने माना कि कम से कम एक मर्ज करने की कोशिश करना स्पष्ट रूप से सबसे अच्छी बात है। यदि वह विफल हो जाता है या बहुत मुश्किल हो जाता है, तो चेरी को उठाने की कोशिश करें, अगर वह गलत हो जाता है तो मैनुअल तरीके से जाएं।


2
सही दृष्टिकोण नहीं है।
एंडी

12
नहीं, यह सही तरीका है - यदि आपके पास एक प्राचीन शाखा है, और आपको कोड नहीं पता है, तो विलय करने की कोशिश बहुत सफल नहीं होने वाली है और यह बहुत जोखिम भरा होने वाला है। मूल रूप से किए गए परिवर्तनों का निर्धारण, यह जांचना कि क्या वे नए कोड के लिए भी प्रासंगिक हैं, और फिर उन्हें समझ में लाने के लिए आवेदन करना ऐसा करने का तरीका है। यह एक मैनुअल तरीका है, लेकिन इन परिस्थितियों में, केवल एक ही सुरक्षित है। बेशक, मैं अभी भी पहले एक मर्ज करने की कोशिश करूँगा, बस यह देखने के लिए कि क्या होता है, और मैं लॉग देखने के लिए जाँच करूँगा कि शाखा में कितना परिवर्तन हुआ है - तुच्छ हो सकता है।
gbjbaanb

10
@ डैविडपैकर: मुझे नहीं लगता कि गेवियानोग्राफोनी सभी कामों को खत्म करने का सुझाव देते हैं। वह पुरानी शाखा से मैन्युअल रूप से विकास की वर्तमान रेखा में, चरण-दर-चरण तरीके से परिवर्तनों को स्थानांतरित करने का सुझाव देता है। वह पुराने इतिहास को फेंक देगा , अधिक नहीं।
डॉक्टर ब्राउन

3
@ डैविडपैकर 1: शाखा एक वर्ष पुरानी है, दूसरा: इसे खत्म करने वाले व्यक्ति को कोड का पता नहीं होता है। इन 2 कारकों को देखते हुए, कार्य को अपनाने के लिए एक मैनुअल री-अप्लाई एकमात्र यथार्थवादी तरीका है। पुरानी शाखा के टिप संशोधन के लिए कोई भी सरल कॉपी-पेस्ट का सुझाव नहीं दे रहा है।
gbjbaanb

5
@ दाविदपकर: भारी संघर्ष बुराई बन सकता है - अगर आपको एक बार फिर से एक संकलन योग्य और परीक्षण योग्य स्थिति में कार्यक्रम प्राप्त करने से पहले उनमें से 500 को हल करना है। ओपी यहां जिस तरह की उम्मीद कर रहा है, वैसी ही स्थिति है। यदि आपको लगता है कि इस "ऑल-एंड-नथिंग" स्थिति से बचने के लिए एक कुशल तरीके से गिट का उपयोग करना संभव है, तो आप अपने उत्तर को संपादित क्यों नहीं करते हैं और ओपी को बताएं कि यह कैसे पूरा किया जा सकता है?
डॉक्टर ब्राउन

16

git-imerge को इस उद्देश्य के लिए डिज़ाइन किया गया है। यह एक गिट टूल है जो वृद्धिशील विलय के लिए एक विधि प्रदान करता है । वृद्धिशील रूप से विलय करके, आपको केवल दो संस्करणों के बीच टकराव से निपटने की आवश्यकता है, कभी भी अधिक नहीं। इसके अलावा, विलय की एक बड़ी संख्या स्वचालित रूप से की जा सकती है क्योंकि व्यक्तिगत परिवर्तन छोटे होते हैं।


6

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

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

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

आप अन्य परिवर्तनों में विलय की भूमिका के लिए बासी शाखा के प्रमुख से शाखा करना चाह सकते हैं। यह सुनिश्चित करने के बारे में अधिक है कि जब कोई पीछे हटता है तो इतिहास और इतिहास स्पष्ट होता है और यह बताता है कि प्रत्येक शाखा की भूमिका और नीति क्या है। बासी शाखा एक सुविधा शाखा थी। जिस से आप काम कर रहे हैं वह एक संचय और सामंजस्य शाखा है।

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

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

एक तरफ के रूप में, यह अन्य संस्करण नियंत्रण प्रणालियों के लिए भी काम करता है। मुझे कभी-कभी एक विशेषता के लिए एक शाखा (चेरी पिकिंग) में svn commits के एक विशिष्ट समूह को मर्ज करने की आवश्यकता होती है, उस सुविधा के साथ काम करने के लिए शाखा को ठीक करें, और उसके बाद svn commits के अगले समूह को एक थोक svn करने के बजाय मर्ज करें मर्ज करें।

एक ओर जहां कर सकते हैं एक Git कर यहाँ चेरी लेने, और उस में लाने की अनुमति नहीं है विशिष्ट कमिट, यह कुछ नुकसान है कि इस प्रक्रिया को जटिल बना सकता है। चेरी पिक आपके द्वारा चुनी गई प्रतिबद्धताओं के बारे में जानकारी नहीं दिखाएगी (आप इसे प्रतिबद्ध संदेश में जोड़ सकते हैं)। यह वास्तव में इतिहास के कमिट्स को ट्रैक करना कठिन बनाता है।

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

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


+1 यह एक दिलचस्प संभावित वैकल्पिक समाधान है जो बड़े परिवर्तनों को शामिल करने के लिए मर्ज का उपयोग करता है। हालाँकि, मैं एक नकारात्मक पहलू देख सकता हूं: मान लीजिए कि आपके पास प्रमुख संस्करण ABCDE हैं और आप सुविधा शाखा A1 को ई में शामिल करना चाहते हैं। बीसी और डी में कोड को विलय करने के लिए बहुत सारे व्यर्थ प्रयास हो सकते हैं। उदाहरण के लिए, यदि डी से ई था तो क्या होगा। एक बड़ा डिजाइन परिवर्तन जिसने बी, सी और डी अप्रासंगिक में वृद्धिशील परिवर्तनों का प्रतिपादन किया? इसके अलावा, यह फिर से इस बात पर निर्भर करता है कि पहले स्थान पर यह फीचर कितना परिपक्व था। एक उपयोगी संभावित दृष्टिकोण, लेकिन शुरू करने से पहले इसकी उपयुक्तता पर विचार किया जाना चाहिए।

1

चरण 1. कोड के बारे में जानें, इसकी वास्तुकला और नवीनतम आम पूर्वजों के बाद से दोनों शाखाओं पर किए गए परिवर्तनों का विश्लेषण करें।

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

चरण 3. संघर्ष के क्षेत्रों का विश्लेषण करें, कार्यात्मक प्रभाव और कारणों को विस्तार से समझें। यहाँ प्रकाश में आने वाली व्यावसायिक आवश्यकताओं में आसानी से टकराव हो सकता है। उपयुक्त के रूप में बीए, अन्य देवों के साथ चर्चा करें। हस्तक्षेप को हल करने के साथ शामिल जटिलता के लिए एक महसूस करें।

चरण 4. उपरोक्त के प्रकाश में, यह तय करें कि क्या केवल उन हिस्सों को मर्ज / चेरी-पिक / कट-पेस्ट करना है या नहीं जो परस्पर विरोधी टुकड़ों को फिर से नहीं लिखते हैं, या खरोंच से पूरी सुविधा को फिर से लिखना है या नहीं ।


0

1. उस शाखा पर स्विच करें जिसका उपयोग मुख्य डेवलपर / रिलीज शाखा के रूप में किया जाता है।

यह वह शाखा है जिसमें सिस्टम में नवीनतम परिवर्तन होते हैं। हो सकता है master, core, dev, यह कंपनी पर निर्भर करता है। आपके मामले में यह masterसीधे तौर पर है।

git checkout master
git pull

यह सुनिश्चित करने के लिए खींच लें कि आपके पास मुख्य विकास शाखा का नवीनतम संस्करण है।

2. उस शाखा को चेकआउट और खींचें जिसमें वह कार्य हो जिसे आप समाप्त करने वाले हैं।

आप यह सुनिश्चित करने के लिए खींचते हैं कि आपके पास वास्तव में शाखा की नवीनतम सामग्री है। इसे सीधे चेक करके, इसे स्थानीय रूप से बनाए बिना, आप सुनिश्चित करें कि इसमें master(या मुख्य देव शाखा से क्रमशः) नई सामग्री न हो।

git checkout <name of the obsolete branch>
git pull origin <name of the obsolete branch>

3. मुख्य विकास शाखा को अप्रचलित शाखा में विलय करना।

निम्न आदेश चलाने से पहले, या तो टाइपिंग द्वारा, यह सुनिश्चित कर लें git branchया git statusकि आप अप्रचलित शाखा पर हैं।

git merge master

git mergeआदेश निर्दिष्ट शाखा से सामग्री विलय करने के लिए इस मामले में, की कोशिश करेंगे master, शाखा आप वर्तमान में कर रहे हैं करने के लिए।

पर जोर देने की कोशिश करेंगे । मर्ज संघर्ष हो सकता है, जिसे आपको और आपको ही हल करना होगा।

4. मर्ज संघर्ष को ठीक करें, प्रतिबद्ध करें और संघर्ष को ठीक करें

सभी फ़ाइलों में मर्ज संघर्ष को ठीक करने के बाद, जहां, स्टेज, कमिट करें और संघर्ष रिज़ॉल्यूशन को पुश करें origin

git add .
git commit -m "fixed the merge conflict from the past year to update the branch"
git push

आप आम तौर पर git add .प्रतिबद्ध के लिए सभी फ़ाइलों को चरणबद्ध करने के लिए कॉल कर सकते हैं। मर्ज संघर्ष से निपटने के दौरान, आप चाहते हैं कि सभी आवश्यक फाइलें अपडेट की जाएं।

अतिरिक्त नोट

मर्ज संघर्ष को हल करना एक थकाऊ काम हो सकता है। खासकर यदि आप किसी कंपनी में नए हैं। आपके पास अभी तक सभी मर्ज संघर्षों को हल करने के लिए उचित ज्ञान नहीं हो सकता है, फिर भी।

अपने काम को जारी रखने से पहले, उन सभी संघर्षों का सावधानीपूर्वक निरीक्षण करें, जो आपके द्वारा किए गए संघर्षों को ठीक से और उचित रूप से ठीक करते हैं।


ऐसा हो सकता है, आप एक साल पुरानी शाखा पर काम करना शुरू करते हैं, वर्तमान विकास की स्थिति को मर्ज करते हैं और इसमें कोई भी मर्ज संघर्ष नहीं होगा।

यह तब होता है जब भले ही सिस्टम वर्ष में बहुत बदल गया हो, किसी ने भी उन फाइलों को नहीं छुआ है जो वास्तव में एक वर्ष पुरानी शाखा में बदल दिए गए थे।


6
# 4 संभावित रूप से समस्या है। यदि पिछले वर्ष में बहुत सारे बदलाव हुए हैं, तो पुरानी सुविधा में बड़े बदलाव की आवश्यकता हो सकती है। मर्ज करके ऐसा करने से आपको सभी को एक बार में कोड में बड़े बदलाव करने की आवश्यकता होती है और आशा है कि यह काम करता है, जो अच्छा विकास अभ्यास नहीं है। इसके अलावा कौन जानता है कि अपूर्ण सुविधा की स्थिति क्या थी? आप गैर-कार्यशील कोड की एक बड़ी गड़बड़ी के साथ समाप्त हो सकते हैं, और कौन जानता है कि क्या यह आपके द्वारा किए गए मूल या परिवर्तनों के साथ समस्याओं के कारण था?

डेविड, जब तक यह मानक दृष्टिकोण काम करता है, यह ठीक है, और ओपी को पहले यह प्रयास करना चाहिए। लेकिन निश्चित रूप से इस "ऑल-एंड-नथिंग" तरीके से उन्हें संभालने के लिए वर्णित स्थिति में बहुत सारे मर्ज टकराव होने का जोखिम है।
डॉक्टर ब्राउन

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

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

@ dan1111 यदि किसी ने एक वर्ष के लिए एक अलग शाखा में एक सुविधा स्थान को नहीं छुआ है, तो यह सिस्टम परिवर्तनों को प्रतिबिंबित करने वाला नहीं है। यह अप्रचलित (6+ महीने पुरानी) शाखाओं के साथ मेरे स्वयं के अनुभव से आता है।
एंडी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.