'git merge'如何在细节中工作？ [英] How does 'git merge' work in details?

问题描述

我想知道'git merge'背后的确切算法（或接近）。至少对这些子问题的答案将是有帮助的：

• git如何检测特定非冲突变化的上下文？


• git如何发现这些行中存在冲突？
  
• git自动合并哪些内容？


• 当合并分支没有共同的基础时，git如何执行


• 当合并分支有多个公共基础时，git如何执行


• 一次合并多个分支会发生什么情况？


• 合并策略有什么区别？

但是整个算法的描述会更好。 解决方案

了解3路合并算法的描述。高级描述应该如下所示：

1. 找到一个合适的合并基< B - 两个新版本（ X 和 Y ）的祖先文件的版本，并且通常是最新的这样的基础（尽管有些情况下它将不得不进一步回退，这是 git 的默认的特征之一）递归合并）


2. 用 B X 的差异$ c>和 Y 与 B 。


3. 浏览更改块在两个差异中确定。如果双方在同一地点引入相同的变化，则接受任意一个;如果一个人引入了一个变化，另一个人离开了这个区域，那么在最后引入这个变化;如果两种情况都引入了某个点的变化，但它们不匹配，请将冲突标记为手动解决。 完整算法成交有更详细的介绍，甚至还有一些文档（ /usr/share/doc/git-doc/technical/trivial-merge.txt ），以及 git help XXX 页面，其中XXX是 merge-base 之一，合并文件， merge ， merge-one-file 以及其他几个可能）。如果这还不够深，总会有源代码...
   
   

   I want to know an exact algorithm (or near that) behind 'git merge'. The answers at least to these sub-questions will be helpful:

   • How does git detect the context of a particular non-conflicting change?
   • How does git find out that there is a conflict in these exact lines?
   • Which things does git auto-merge?
   • How does git perform when there is no common base for merging branches?
   • How does git perform when there are multiple common bases for merging branches?
   • What happens when I merge multiple branches at once?
   • What is a difference between merge strategies?

   But the description of a whole algorithm will be much better.

   解决方案

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

   1. 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)
   2. Perform diffs of X with B and Y with B.
   3. 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...

   这篇关于'git merge'如何在细节中工作？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！