गिट सममित में विलय कर रहे हैं?

Question

चलें कहते हैं कि हम दो शाखाओं (बी और सी) है कि एक आम पूर्वज एक से भिन्न हो गए हैं की है। बी से विलय होगासेल्सियस तकसीकरने के लिए बी से विलय के रूप में एक ही परिणाम का उत्पादन?

A 
    | 
/\ 
B C 

स्पष्टीकरण के लिए- मुझे लगता है कि कोई भी मैन्युअल विलय संघर्ष संकल्प दोनों दिशाओं में होगा। लेकिन क्या कोई भी स्वचालित विलय होगा जो उसी कोड में चुना जा रहा है? यही वह है जो मैं मान रहा हूं, क्योंकि प्रतिबद्धता तिथियां दोनों दिशाओं में समान हैं।

आगे स्पष्टीकरण के लिए - मुझे पता है कि दिशा में आधारित एक दूसरे के "मिरर छवियों" में वास्तविक विलय परिणाम। मैं बस स्वचालित रूप से हल किए गए संघर्षों के बारे में पूछ रहा हूं।

Answer 1

उत्तर डिफ़ॉल्ट विलय के लिए हाँ है। एक तीन-तरफा विलय एक आम पूर्वज पाता है और फिर दोनों तरफ से मतभेद लागू करता है, एक ऑपरेशन जो ऑर्डर निर्भर नहीं है। मर्ज-ऑर्डरिंग और कम्यूटिटीविटी के विषय ने git list पर एक आकर्षक चर्चा उत्पन्न की है (यदि आप उस तरह की चीज में हैं, तो यह है)। नोट B into C और C into B सममित होना चाहिए, लेकिन (B into C) into A बनाम B into (C into A) के लिए यह आवश्यक नहीं कहा जा सकता है।

---

में थोड़ा और अधिक विस्तार करने के लिए नीचे दिए गए विन्स की टिप्पणी और प्रश्न पर seh की टिप्पणी के आधार पर, वहाँ B into C और C into B के बीच दो ध्यान देने योग्य मतभेद हैं, जिनमें से न तो प्रश्न में संदर्भित स्वत: मर्ज संकल्प को प्रभावित किया जाएगा।

पहला, इतिहास अलग होगा। विलय प्रतिबद्धता के माता-पिता विलय आदेश के आधार पर बदल जाएंगे। इन उदाहरणों के लिए, मैं "first_branch" और "second_branch" का उपयोग करने जा रहा हूं, इसलिए मैं कामों का प्रतिनिधित्व करने के लिए अक्षरों को आरक्षित कर सकता हूं।

git checkout first_branch && git merge second_branch 

E <- merge commit 
|\ 
| D <- second_branch's tip 
| | 
| C <- another commit on second_branch 
| | 
| B <- and another 
|/ 
A <- first_branch's tip before the merge 

इस मामले में, ई, E^1 की "पहले माता-पिता", मर्ज से पहले first_branch के टिप है। second_branch विलय प्रतिबद्धता, उर्फ ​​E^2 का "दूसरा अभिभावक" है। अब रिवर्स पर विचार करें:

git checkout second_branch && git merge first_branch 

E <- merge commit 
|\ 
| D <- first_branch's tip 
| | 
| C <- another commit on first_branch 
| | 
| B <- and another 
|/ 
A <- second_branch's tip before the merge 

माता-पिता को उलट दिया जाता है। E^1 विलय से पहले second_branch की नोक है। E^2 first_branch की नोक है।

दूसरा, विवादों का प्रदर्शन क्रम विपरीत होगा।पहले मामले में, एक संघर्ष इस प्रकार दिखाई देंगे:

<<<<<<< HEAD 
This line was added from the first_branch branch. 
======= 
This line was added from the second_branch branch. 
>>>>>>> second_branch 

दूसरे मामले में, एक ही संघर्ष इस प्रकार दिखाई देगा:

<<<<<<< HEAD 
This line was added from the second_branch branch. 
======= 
This line was added from the first_branch branch. 
>>>>>>> first_branch 

इन मतभेदों की न तो स्वत: मर्ज संकल्प को प्रभावित है, लेकिन वे जब आप तीन-तरफा मर्ज ऑर्डर रिवर्स करते हैं तो दिखाई दें।

Answer 2

नहीं, मुझे लगता है कि यह सममित नहीं होगा। सबसे पहले आप मर्ज रणनीति विकल्प सेट कर सकते हैं, खासकर आपके मामले में theirs या ours जो यह निर्धारित करता है कि बी या सी चुना जाएगा या नहीं।

स्वचालित विलय में, मुझे लगता है कि उदाहरण के लिए रिमोट शाखा को आपके परिवर्तनों पर प्राथमिकता है यदि आप अपने विलय में हैं तो इसका मतलब है कि बी से git merge C पर कॉल करने के परिणामस्वरूप सी परिवर्तनों का चयन किया जा रहा है। हालांकि मैं 100% निश्चित नहीं हूं, इसलिए आप इसे अपने आप आज़मा सकते हैं और हमें बता सकते हैं।

Answer 3

यह "उसी परिणाम" से आपका क्या मतलब है इस पर निर्भर करता है। एक सामग्री परिप्रेक्ष्य से, यह मानते हुए कि कोई संघर्ष नहीं है, या सभी मौजूदा संघर्षों को ठीक उसी तरह हल किया गया है, परिणामी नए विलय प्रतिबद्धता की सामग्री समान होनी चाहिए।

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