আমিও আগ্রহী। আমি উত্তর জানি না, কিন্তু ...
একটি জটিল সিস্টেম যা কাজ করে তা অনায়াসে কাজ করে এমন একটি সাধারণ সিস্টেম থেকে বিকশিত হয়
আমি মনে করি গিটের সংশ্লেষ অত্যন্ত পরিশীলিত এবং এটি বোঝা খুব কঠিন হবে - তবে এর কাছে যাওয়ার একটি উপায় তার পূর্বসূরীদের থেকে এবং আপনার উদ্বেগের হৃদয়কে কেন্দ্র করে। এটি হ'ল দুটি ফাইল দেওয়া আছে যার সাধারণ পূর্বপুরুষ নেই, গিট মার্জ কীভাবে তাদের একত্রিত করতে পারে এবং কোথাও বিরোধ রয়েছে?
আসুন কিছু পূর্ববর্তী অনুসন্ধান করার চেষ্টা করুন। থেকে 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.wikedia.org/wiki/Git_%28software%29 -> http://en.wikedia.org/wiki/Three-way_ विस ## ত্রি- ওয়ে_ব্রিজ -> http: //en.wikedia .org / wiki / Diff3 -> http://www.cis.upenn.edu/~bcpierce/papers/diff3-short.pdf
সেই শেষ লিঙ্কটি একটি কাগজের পিডিএফ যা diff3বিস্তারিতভাবে অ্যালগরিদমকে বর্ণনা করে । এখানে একটি গুগল পিডিএফ-ভিউয়ার সংস্করণ । এটি কেবল 12 পৃষ্ঠার দীর্ঘ এবং অ্যালগরিদমটি কেবল কয়েকটি পৃষ্ঠাগুলি - তবে গাণিতিক একটি সম্পূর্ণ চিকিত্সা। এটি কিছুটা আনুষ্ঠানিক বলে মনে হতে পারে তবে আপনি যদি গিটের मर्জটি বুঝতে চান তবে আপনাকে প্রথমে সহজ সংস্করণটি বুঝতে হবে। আমি এখনও চেক করি নি, তবে এর মতো একটি নাম দিয়ে diff3আপনাকে সম্ভবত ডিফ বুঝতে হবে (যা একটি দীর্ঘকালীন সাধারণ উপগোষ্ঠী অ্যালগরিদম ব্যবহার করে)। তবে, diff3যদি আপনার কোনও গুগল থাকে তবে সেখানে আরও একটি স্বজ্ঞাত ব্যাখ্যা হতে পারে ...
এখন, আমি শুধু একটি পরীক্ষা তুলনা করেনি diff3এবং git merge-file। তারা একই তিন ইনপুট ফাইল নিতে version1 oldversion version2 এবং মার্ক দ্বন্দ্ব পথ একই সঙ্গে <<<<<<< version1, =======, >>>>>>> version2( diff3এছাড়াও আছে ||||||| oldversion), তাদের সাধারণ ঐতিহ্য দেখাচ্ছে।
আমি একটি খালি ফাইল ব্যবহার oldversion , এবং কাছাকাছি অভিন্ন ফাইল version1 এবং version2 মাত্র এক অতিরিক্ত লাইন দিয়ে যোগ করা version2 ।
ফলাফল: git merge-fileএকক পরিবর্তিত রেখাকে দ্বন্দ্ব হিসাবে চিহ্নিত করেছে; তবে diff3পুরো দুটি ফাইলকে দ্বন্দ্ব হিসাবে বিবেচনা করেছেন। এইভাবে, ডিফ 3 হিসাবে পরিশীলিত হ'ল, গিটের সংযোজন এমনকি আরও পরিশীলিত, এমনকি এই সাধারণতম ক্ষেত্রেও।
এখানে আসল ফলাফল রয়েছে (আমি পাঠ্যের জন্য @ টওয়ালবার্গের উত্তর ব্যবহার করেছি)। প্রয়োজনীয় বিকল্পগুলি নোট করুন (স্বতন্ত্র ম্যানেজগুলি দেখুন)।
$ 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
আপনি যদি সত্যিই এটিতে আগ্রহী হন তবে এটি খরগোশের একটি গর্ত। আমার কাছে এটি নিয়মিত প্রকাশের মতোই গভীর বলে মনে হয়, দীর্ঘতম, সাধারণ প্রেক্ষাপটে ব্যাকরণ বা সম্পর্কিত বীজগণিতের সাধারণ দীর্ঘসূত্রতা অ্যালগরিদম। আপনি যদি এর নীচে যেতে চান তবে আমার মনে হয় আপনি এটি করতে পারেন তবে এটি কিছু নির্ধারিত অধ্যয়ন গ্রহণ করবে।