Git 合并策略

当工作完成并准备合并到开发的主线时，我们应该选择我们的合并策略。

Git 将两个提交指针合并到它们之间的一个公共基础提交中。
Git 以不同的方式找到共同的基础称为“合并策略”。
选择一个合并策略后，Git 会结合指定的合并提交的变化创建一个新的合并提交。
如果不指定，git merge 命令会自动选择一个合并策略基于在提供的分支上。

-s 选项可以添加指定策略的名称。
以下是合并策略列表：

recursive

git merge -s recursive branch1 branch2

Git 在拉取或者合并分支时会选择递归作为默认策略。
递归策略可以检测和管理涉及重命名的合并，但它不能使用检测到的副本。

Octopus

git merge -s resolve branch1 branch2

解析策略使用 3 路合并来解析分支，并且使用 3 路合并算法只能解析两个 HEAD。
它安全快速，可以详细检测纵横交错的合并歧义。

章鱼

git merge -s octopus branch1 branch2 branch3 branchN

当通过两个或者更多分支时，默认情况下采用章鱼策略。
如果合并有需要手动解决的冲突，八达通会拒绝。
Octopus 的基本用途是捆绑具有相似性的特征分支 HEAD。

ours

git merge -s ours branch1 branch2 branchN

我们的策略解析多个分支，但结果始终是当前分支 HEAD 的结果。
它非常有效地忽略了所有其他分支的所有更改。
它旨在用于替换侧枝的旧历史。

Subtree

git merge -s subtree branchA branchB

子树策略是递归策略的修改版本。
例如，我们合并 A 树和 B 树。
当对应于A的子树时，首先修改B以反映A的树结构。
修改可以对A和B的共享祖先树进行。

git合并策略的类型

git显式合并

显式合并被视为默认合并类型。
之所以称为显式，是因为它会创建一个新的合并提交，更改历史记录并显示调用合并的位置。
合并提交内容也被认为是显式的，因为它显示了合并提交的父提交。

通过变基或者快进合并进行隐式合并

隐式合并不会创建合并提交。
他们只是从指定的分支 HEAD 中获取一些提交并将它们放在目标分支的顶部。
它们由变基事件或者快进合并触发。

在没有显式合并的情况下挤压合并

Squash 是另一种类型的隐式合并。
压缩合并从目标分支获取提交并将它们压缩成一个提交，然后将其应用于合并基础分支的 HEAD。
Squash 可以在交互式 rebase 期间执行。
当压缩和合并时，目标分支的提交历史成为压缩的分支提交。

git 递归合并策略选项