你什么时候会使用不同的 git 合并策略? [英] When would you use the different git merge strategies?

问题描述

在 git-merge 的手册页中，您可以使用多种合并策略.

From the man page on git-merge, there are a number of merge strategies you can use.

• 解决 -这只能使用 3 路合并算法解析两个头(即当前分支和您从中拉出的另一个分支).它会尝试仔细检测交叉合并的歧义，并且通常被认为是安全且快速的.

• 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.

递归 -这只能使用 3 路合并算法解决两个头.当有多个共同祖先可用于 3 路合并时，它会创建一个共同祖先的合并树，并将其用作 3 路合并的参考树.据报道，通过对取自 Linux 2.6 内核开发历史的实际合并提交进行的测试，这会导致更少的合并冲突，而不会导致错误合并.此外，这可以检测和处理涉及重命名的合并.这是拉取或合并一个分支时的默认合并策略.

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.

子树 -这是一种修改后的递归策略.合并树 A 和 B 时，如果 B 对应于 A 的子树，则首先调整 B 以匹配 A 的树结构，而不是读取同一级别的树.对共同祖先树也进行了这种调整.

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?

推荐答案

我不熟悉resolve，但我用过其他的:

I'm not familiar with resolve, but I've used the others:

递归是非快进合并的默认值.我们都很熟悉那个.

Recursive is the default for non-fast-forward merges. We're all familiar with that one.

当我有几棵树需要合并时，我使用了章鱼.您可以在大型项目中看到这一点，在这些项目中，许多分支都进行了独立开发，并且已经准备好整合到一个头中.

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.

举例来说，假设您有一个项目，它有一个 master，然后有三个要合并的分支(称为 a、b 和 c).

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 == 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.

(阅读:它甚至没有查看这些分支之间的变化.分支只是合并，对文件没有做任何事情.如果你想在另一个分支中合并，每次都有问题我们的文件版本或他们的版本"，你可以使用 git merge -X ours)

(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 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屋！