विवरण में 'git मर्ज' कैसे काम करता है?

Question 1

मैं 'git मर्ज' के पीछे एक सटीक एल्गोरिदम (या पास) जानना चाहता हूं। कम से कम इन उप-प्रश्नों के उत्तर सहायक होंगे:

जीआईटी एक विशेष गैर-परस्पर विरोधी परिवर्तन के संदर्भ का पता कैसे लगाता है?
Git को कैसे पता चलता है कि इन सटीक लाइनों में संघर्ष है?
ऑटो-मर्ज किन चीजों से होता है?
जब मर्जिंग शाखाओं के लिए कोई सामान्य आधार नहीं होता है तो प्रदर्शन कैसे होता है?
जब मर्जिंग शाखाओं के लिए कई सामान्य आधार होते हैं, तो प्रदर्शन कैसे होता है?
जब मैं एक साथ कई शाखाएँ मिलाता हूँ तो क्या होता है?
मर्ज रणनीतियों के बीच अंतर क्या है?

लेकिन एक पूरे एल्गोरिथ्म का वर्णन बहुत बेहतर होगा।

Question 2

3-तरफा मर्ज एल्गोरिथ्म के विवरण की तलाश में आप सर्वश्रेष्ठ हो सकते हैं। एक उच्च-स्तरीय विवरण कुछ इस तरह होगा:

एक उपयुक्त मर्ज बेस खोजें B- फ़ाइल का एक संस्करण जो दोनों नए संस्करणों ( Xऔर Y) का पूर्वज है , और आमतौर पर सबसे हाल का ऐसा आधार (हालांकि ऐसे मामले हैं जहां इसे आगे वापस जाना होगा, जो कि एक है gitडिफ़ॉल्ट डिफ़ॉल्ट recursiveमर्ज की विशेषताएं )
की डिफ प्रदर्शन Xके साथ Bऔर Yसाथ B।
दो अलग-अलग हिस्सों में पहचाने गए परिवर्तन ब्लॉकों से गुजरें। यदि दोनों पक्ष एक ही स्थान पर समान परिवर्तन का परिचय देते हैं, तो दोनों में से किसी एक को स्वीकार करें; यदि एक परिवर्तन का परिचय देता है और दूसरा उस क्षेत्र को छोड़ता है, तो अंतिम में परिवर्तन का परिचय दें; यदि दोनों एक स्थान में परिवर्तन शुरू करते हैं, लेकिन वे मेल नहीं खाते हैं, तो एक संघर्ष को मैन्युअल रूप से हल करने के लिए चिह्नित करें।

पूर्ण एल्गोरिथ्म बहुत अधिक विस्तार से इससे संबंधित है, और यहां तक कि पृष्ठों के साथ कुछ दस्तावेज़ीकरण ( https://github.com/git/git/blob/master/Documentation/technical/trivial-merge.txt भी है git help XXX, जहां XXX में से एक है merge-base, merge-file, merge, merge-one-fileऔर संभवतः कुछ अन्य)। यदि यह पर्याप्त गहरा नहीं है, तो हमेशा स्रोत कोड होता है ...

Question 3

जब मर्जिंग शाखाओं के लिए कई सामान्य आधार होते हैं, तो प्रदर्शन कैसे होता है?

यह लेख बहुत सहायक था: http://codicesoftware.blogspot.com/2011/09/merge-recursive-strategy.html (यहाँ भाग 2 है )।

पुनरावर्ती उपयोग करता है diff3 पुनरावर्ती रूप से एक आभासी शाखा उत्पन्न करने के लिए जिसे पूर्वज के रूप में उपयोग किया जाएगा।

उदाहरण के लिए:

(A)----(B)----(C)-----(F)
        |      |       |
        |      |   +---+
        |      |   |
        |      +-------+
        |          |   |
        |      +---+   |
        |      |       |
        +-----(D)-----(E)

फिर:

git checkout E
git merge F

2 सर्वश्रेष्ठ सामान्य पूर्वज (सामान्य पूर्वज जो किसी अन्य के पूर्वज नहीं हैं), Cऔर हैं D। Git उन्हें एक नई आभासी शाखा में विलय कर देता है V, और फिर Vआधार के रूप में उपयोग करता है ।

(A)----(B)----(C)--------(F)
        |      |          |
        |      |      +---+
        |      |      |
        |      +----------+
        |      |      |   |
        |      +--(V) |   |
        |          |  |   |
        |      +---+  |   |
        |      |      |   |
        |      +------+   |
        |      |          |
        +-----(D)--------(E)

मुझे लगता है कि Git अभी भी जारी रहेगा यदि Vअगले सबसे अच्छे पूर्वजों का विलय हो गया , तो अगले के साथ विलय हो जाएगा।

लेख में कहा गया है कि अगर वर्चुअल ब्रांच जनरेट करते समय कोई मर्ज संघर्ष होता है, तो बस संघर्ष मार्करों को छोड़ देता है जहां वे हैं और जारी है।

जब मैं एक साथ कई शाखाएँ मिलाता हूँ तो क्या होता है?

जैसा कि @Nevik Rehnel ने समझाया, यह रणनीति पर निर्भर करता है, यह man git-merge MERGE STRATEGIESखंड पर अच्छी तरह से समझाया गया है ।

केवल octopusऔर एक ही बार में कई शाखाओं को मिलाने का समर्थन ours/theirsrecursive उदाहरण के लिए नहीं करता है।

octopus यदि कोई विरोध होगा, तो विलय करने से इंकार कर देगा ours एक तुच्छ विलय है, इसलिए कोई टकराव नहीं हो सकता है।

उन आदेशों से एक नई प्रतिबद्धता उत्पन्न होती है जिसमें 2 से अधिक माता-पिता होंगे।

मैंने एक किया merge -X octopus Git 1.8.5 पर संघर्ष के बिना यह देखने के लिए कि यह कैसे जाता है।

प्रारम्भिक अवस्था:

   +--B
   |
A--+--C
   |
   +--D

क्रिया:

git checkout B
git merge -Xoctopus C D

नई स्थिति:

   +--B--+
   |     |
A--+--C--+--E
   |     |
   +--D--+

जैसी कि उम्मीद थी, E3 माता-पिता हैं।

TODO: एकल फाइल संशोधनों पर ऑक्टोपस कैसे संचालित होता है। पुनरावर्ती दो-दो-तीन तरह से विलय?

जब मर्जिंग शाखाओं के लिए कोई सामान्य आधार नहीं होता है तो प्रदर्शन कैसे होता है?

@ टॉर्क का उल्लेख है कि 2.9 के बाद से मर्ज बिना विफल रहता है --allow-unrelated-histories।

मैंने इसे जीआईटी 1.8.5 पर अनुभवजन्य रूप से आज़माया:

git init
printf 'a\nc\n' > a
git add .
git commit -m a

git checkout --orphan b
printf 'a\nb\nc\n' > a
git add .
git commit -m b
git merge master

a शामिल हैं:

a
<<<<<<< ours
b
=======
>>>>>>> theirs
c

फिर:

git checkout --conflict=diff3 -- .

a शामिल हैं:

<<<<<<< ours
a
b
c
||||||| base
=======
a
c
>>>>>>> theirs

व्याख्या:

आधार खाली है
जब आधार खाली होता है, तो किसी भी फाइल पर किसी भी संशोधन को हल करना संभव नहीं होता है; केवल नई फ़ाइल जोड़ जैसी चीजों को हल किया जा सकता है। उपरोक्त संघर्ष को आधार के साथ 3-वे मर्ज पर हल किया जाएगाa\nc\n एकल लाइन जोड़ के रूप में
मुझे लगता है कि बिना बेस फाइल के 3-वे मर्ज को 2-वे मर्ज कहा जाता है, जो सिर्फ एक अंतर है

Question 4

मुझे भी दिलचस्पी है। मैं जवाब नहीं जानता, लेकिन ...

एक जटिल प्रणाली जो काम करती है वह हमेशा एक सरल प्रणाली से विकसित होती है जो काम करती है

मुझे लगता है कि जीआईटी का विलय अत्यधिक परिष्कृत है और इसे समझना बहुत मुश्किल होगा - लेकिन इसके संपर्क का एक तरीका इसके अग्रदूतों से है, और अपनी चिंता के दिल पर ध्यान केंद्रित करना है। अर्थात्, दो फाइलें दी गई हैं, जिनके पास एक सामान्य पूर्वज नहीं है, git मर्ज कैसे कार्य करता है कि उन्हें कैसे मर्ज किया जाए, और कहां विरोध हैं?

आइए कुछ अग्रदूतों को खोजने का प्रयास करें। से git help merge-file:

git merge-file is designed to be a minimal clone of RCS merge; that is,
       it implements all of RCS merge's functionality which is needed by
       git(1).

विकिपीडिया से: http://en.wikipedia.org/wiki/Git_%28software%29 -> http://en.wikipedia.org/wiki/Three-way_merge#Tree-way_merge - http: //en.wikipedia .org / wiki / Diff3 -> http://www.cis.upenn.edu/~bcpierce/papers/diff3-short.pdf

वह आखिरी कड़ी diff3एल्गोरिदम के बारे में विस्तार से वर्णन करते हुए एक कागज का एक पीडीएफ है। यहाँ एक google pdf-दर्शकों का संस्करण है । यह केवल 12 पेज लंबा है, और एल्गोरिथ्म केवल कुछ पृष्ठों का है - लेकिन एक पूर्ण-गणितीय उपचार। यह थोड़ा औपचारिक लग सकता है, लेकिन अगर आप गिट के मर्ज को समझना चाहते हैं, तो आपको पहले सरल संस्करण को समझना होगा। मैंने अभी तक जाँच नहीं की है, लेकिन जैसे नाम के साथ diff3, आपको संभवतः अंतर समझने की भी आवश्यकता होगी (जो सबसे लंबे समय तक सामान्य एल्गोरिथ्म का उपयोग करता है )। हालाँकि, वहाँ एक और अधिक सहज ज्ञान युक्त स्पष्टीकरण हो सकता है diff3, अगर आपके पास एक Google है ...

अब, मैंने सिर्फ एक प्रयोग किया diff3और तुलना की git merge-file। वे एक ही तीन इनपुट फ़ाइलें ले version1 oldversion version2 और मार्क संघर्ष रास्ता एक ही है, साथ <<<<<<< version1, =======, >>>>>>> version2( diff3भी ||||||| oldversion), उनकी साझी विरासत को दर्शाता है।

मैं के लिए एक खाली फ़ाइल का उपयोग किया oldversion , और के लिए लगभग समान फ़ाइलों version1 और version2 सिर्फ एक अतिरिक्त लाइन के साथ करने के लिए जोड़ा version2 ।

परिणाम: git merge-fileसंघर्ष के रूप में एकल परिवर्तित रेखा की पहचान की; लेकिन diff3पूरे दो फाइलों को एक संघर्ष के रूप में माना जाता है। इस प्रकार, diff3 जितना परिष्कृत है, git का मर्ज और भी अधिक परिष्कृत है, यहां तक कि इस सरलतम मामलों के लिए भी।

यहां वास्तविक परिणाम हैं (मैंने पाठ के लिए @ टालबर्ग के उत्तर का उपयोग किया है)। आवश्यक विकल्पों पर ध्यान दें (संबंधित मानपत्र देखें)।

$ git merge-file -p fun1.txt fun0.txt fun2.txt

You might be best off looking for a description of a 3-way merge algorithm. A
high-level description would go something like this:

    Find a suitable merge base B - a version of the file that is an ancestor of
both of the new versions (X and Y), and usually the most recent such base
(although there are cases where it will have to go back further, which is one
of the features of gits default recursive merge) Perform diffs of X with B and
Y with B.  Walk through the change blocks identified in the two diffs. If both
sides introduce the same change in the same spot, accept either one; if one
introduces a change and the other leaves that region alone, introduce the
change in the final; if both introduce changes in a spot, but they don't match,
mark a conflict to be resolved manually.
<<<<<<< fun1.txt
=======
THIS IS A BIT DIFFERENT
>>>>>>> fun2.txt

The full algorithm deals with this in a lot more detail, and even has some
documentation (/usr/share/doc/git-doc/technical/trivial-merge.txt for one,
along with the git help XXX pages, where XXX is one of merge-base, merge-file,
merge, merge-one-file and possibly a few others). If that's not deep enough,
there's always source code...

$ diff3 -m fun1.txt fun0.txt fun2.txt

<<<<<<< fun1.txt
You might be best off looking for a description of a 3-way merge algorithm. A
high-level description would go something like this:

    Find a suitable merge base B - a version of the file that is an ancestor of
both of the new versions (X and Y), and usually the most recent such base
(although there are cases where it will have to go back further, which is one
of the features of gits default recursive merge) Perform diffs of X with B and
Y with B.  Walk through the change blocks identified in the two diffs. If both
sides introduce the same change in the same spot, accept either one; if one
introduces a change and the other leaves that region alone, introduce the
change in the final; if both introduce changes in a spot, but they don't match,
mark a conflict to be resolved manually.

The full algorithm deals with this in a lot more detail, and even has some
documentation (/usr/share/doc/git-doc/technical/trivial-merge.txt for one,
along with the git help XXX pages, where XXX is one of merge-base, merge-file,
merge, merge-one-file and possibly a few others). If that's not deep enough,
there's always source code...
||||||| fun0.txt
=======
You might be best off looking for a description of a 3-way merge algorithm. A
high-level description would go something like this:

    Find a suitable merge base B - a version of the file that is an ancestor of
both of the new versions (X and Y), and usually the most recent such base
(although there are cases where it will have to go back further, which is one
of the features of gits default recursive merge) Perform diffs of X with B and
Y with B.  Walk through the change blocks identified in the two diffs. If both
sides introduce the same change in the same spot, accept either one; if one
introduces a change and the other leaves that region alone, introduce the
change in the final; if both introduce changes in a spot, but they don't match,
mark a conflict to be resolved manually.
THIS IS A BIT DIFFERENT

The full algorithm deals with this in a lot more detail, and even has some
documentation (/usr/share/doc/git-doc/technical/trivial-merge.txt for one,
along with the git help XXX pages, where XXX is one of merge-base, merge-file,
merge, merge-one-file and possibly a few others). If that's not deep enough,
there's always source code...
>>>>>>> fun2.txt

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

Question 5

यहाँ मूल कार्यान्वयन है

http://git.kaarsemaker.net/git/blob/857f26d2f41e16170e48076758d974820af685ff/git-merge-recursive.py

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

Question 6

जीआईटी एक विशेष गैर-परस्पर विरोधी परिवर्तन के संदर्भ का पता कैसे लगाता है?
कैसे पता चलता है कि इन सटीक रेखाओं में कोई विरोध है?

यदि मर्ज के दोनों तरफ एक ही रेखा बदल गई है, तो यह एक संघर्ष है; यदि वे नहीं हैं, तो एक तरफ से परिवर्तन (यदि अस्तित्व में है) स्वीकार किया जाता है।

ऑटो-मर्ज किन चीजों से होता है?

परिवर्तन जो संघर्ष नहीं करते हैं (ऊपर देखें)

जब मर्जिंग शाखाओं के लिए कई सामान्य आधार होते हैं, तो प्रदर्शन कैसे होता है?

Git मर्ज-बेस की परिभाषा से , केवल एक ही (नवीनतम सामान्य पूर्वज) है।

जब मैं एक साथ कई शाखाएँ मिलाता हूँ तो क्या होता है?

यह मर्ज रणनीति पर निर्भर करता है (केवल octopusऔर ours/ / theirsरणनीति दो शाखाओं से अधिक विलय का समर्थन करती है)।

मर्ज रणनीतियों के बीच अंतर क्या है?

इसे git mergeमैनपेज में समझाया गया है ।