你什么时候会使用不同的git合并策略？ [英] When would you use the different git merge strategies?
问题描述
从git-merge的手册页中，可以使用许多合并策略。
-
resolve -
这只能解析两个头（即当前分支和你从另一个分支拉出）使用3路合并算法。它试图仔细检测交叉融合歧义，并且通常被认为是安全和快速的。 只能使用3路合并算法解析两个头。当有多个可用于三路合并的共同祖先时，它将创建一个共同祖先的合并树并将其用作三路合并的参考树。据报道，这会导致更少的合并冲突，而不会导致从Linux 2.6内核开发历史记录中进行的实际合并提交所做的测试错误合并。此外，这可以检测并处理涉及重命名的合并。这是拉取或合并一个分支时的默认合并策略。 头部的情况下，但拒绝做复杂的合并，需要手动解决。它主要用于将主题分支主题捆绑在一起。这是拉动或合并多个分支时的默认合并策略。 的头，但合并的结果总是当前的分支头。它是用来取代旧分支的发展历史。 -
子树 -
这是一个修改过的递归策略。当合并树A和B时，如果B对应于A的子树，则首先调整B以匹配A的树结构，而不是读取处于相同级别的树。这种调整也适用于共同的祖先树。
何时应该指定与默认值不同的内容？哪些场景最适合？
我对解决方案并不熟悉，但我使用了其他方法：
递归
递归是非快速合并的默认值。我们都很熟悉那个。
八达通
我已经用过章鱼需要合并的几棵树。您可以在大型项目中看到这一点，许多分支机构都进行了独立开发，并且已经准备好将它们合并为一个头部。
章鱼分支在一次提交中合并多个头只要它可以干净地完成。
为了说明，假设您有一个项目有一个主人，然后有三个分支要合并（称为a，b，和c）。
一系列递归合并看起来像这样（请注意，第一次合并是快进，因为我没有强制递归）：
然而，单个章鱼合并看起来像这样：
提交ae632e99ba0ccd0e9e06d09e8647659220d043b9
合并：f51262e ... c9ce629 ... aa0f25d ...
我们
Ours ==我想拉另一个头，但是扔掉头部引入的所有变化。
一个没有任何分支效果的分支的历史。
（阅读：甚至没有看到这些分支之间的变化。分支只是合并，没有任何文件。如果你想在其他分支中合并，并且每次有我们的文件版本或他们的版本的问题，你可以使用 git merge -X我们）
子树
当您想要将另一个项目合并到当前项目的子目录中时，子树很有用。当你有一个你不想作为子模块包含的库时很有用。
From the man page on git-merge, there are a number of merge strategies you can use.
resolve - This can only resolve two heads (i.e. the current branch and another branch you pulled from) using 3-way merge algorithm. It tries to carefully detect criss-cross merge ambiguities and is considered generally safe and fast.
recursive - This can only resolve two heads using 3-way merge algorithm. When there are more than one common ancestors that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mis-merges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames. This is the default merge strategy when pulling or merging one branch.
octopus - This resolves more than two-head case, but refuses to do complex merge that needs manual resolution. It is primarily meant to be used for bundling topic branch heads together. This is the default merge strategy when pulling or merging more than one branches.
ours - This resolves any number of heads, but the result of the merge is always the current branch head. It is meant to be used to supersede old development history of side branches.
subtree - This is a modified recursive strategy. When merging trees A and B, if B corresponds to a subtree of A, B is first adjusted to match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree.
When should I specify something different than the default? What scenarios are each best for?
I'm not familiar with resolve, but I've used the others:
Recursive
Recursive is the default for non-fast-forward merges. We're all familiar with that one.
Octopus
I've used octopus when I've had several trees that needed to be merged. You see this in larger projects where many branches have had independent development and it's all ready to come together into a single head.
An octopus branch merges multiple heads in one commit as long as it can do it cleanly.
For illustration, imagine you have a project that has a master, and then three branches to merge in (call them a, b, and c).
A series of recursive merges would look like this (note that the first merge was a fast-forward, as I didn't force recursion):
However, a single octopus merge would look like this:
commit ae632e99ba0ccd0e9e06d09e8647659220d043b9
Merge: f51262e... c9ce629... aa0f25d...
Ours
Ours == I want to pull in another head, but throw away all of the changes that head introduces.
This keeps the history of a branch without any of the effects of the branch.
(Read: It is not even looked at the changes between those branches. The branches are just merged and nothing is done to the files. If you want to merge in the other branch and every time there is the question "our file version or their version" you can use git merge -X ours)
Subtree
Subtree is useful when you want to merge in another project into a subdirectory of your current project. Useful when you have a library you don't want to include as a submodule.
这篇关于你什么时候会使用不同的git合并策略？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
