从上图可以看出，两个分支上分别新增的文件，在合并时被判定为冲突！！！
因为默认的合并策略会检测重命名的行为，大致思路为：内容相近的文件可能被判断为同一个文件。
我采用的解决方案是修改合并策略，使用resolve：
git merge -s resolve features/my_branch
合并策略文档翻译：
合并策略
合并机制（git merge 和 git pull 命令）允许通过 -s 选项选择后端合并策略。有些策略也可以使用它们自己的选项，可以通过给 git merge 和/或 git pull 传递 -X
ort
这是在拉取或合并一个分支时的 默认合并策略。该策略只能使用 3-way 合并算法解决两个头。当有多个可用于 3-way 合并的共同祖先时，它会创建共同祖先的合并树，并将其用作 3-way 合并的参考树。根据来自 Linux 2.6 内核开发历史的实际合并提交的测试结果，据报告称它导致了更少的合并冲突，而不会导致合并错误。此外，该策略可以检测和处理涉及重命名的合并。它不使用检测到的复制。这种算法的名称是一个首字母缩写（“Ostensibly Recursive’s Twin”），因为它是作为以前的默认算法 recursive 的替代品而编写的。
ort 策略可以接受以下选项：
- ours
此选项强制将有冲突的片段通过偏爱我们的版本进行自动解决。来自另一个树的在与我们的一侧不冲突的更改将反映在合并结果中。对于二进制文件，整个内容都来自我们的一侧。
这个选项不应与 ours 合并策略混淆，后者根本不看其他树包含的内容。它丢弃了其他树所做的一切，声明我们的历史包含了其中发生的一切。- theirs
这是 ours 的相反；请注意，与 ours 不同，没有 theirs 合并策略来混淆此合并选项。- ignore-space-change
- ignore-all-space
- ignore-space-at-eol
- ignore-cr-at-eol
出于进行三路合并的考虑，将具有指定类型的空格更改的行视为未更改。与行的其他更改混合的空格更改不会被忽略。另请参阅 git-diff(1) 的 -b、-w、--ignore-space-at-eol 和 --ignore-cr-at-eol。
- 如果他们的版本只对某一行进行了空格更改，则使用我们的版本；
- 如果我们的版本引入了空格更改，但他们的版本包含了实质性更改，则使用他们的版本；
- 否则，合并将以通常的方式进行。
- renormalize
在解决三路合并时，它对文件的所有三个阶段运行虚拟签出和签入。这个选项意在用于合并具有不同清理过滤器或行尾规范化规则的分支。有关详细信息，请参见 gitattributes(5) 中的“合并具有不同签入/签出属性的分支”。- no-renormalize
禁用 renormalize 选项。此覆盖了 merge.renormalize 配置变量。- find-renames[=<n>]
打开重命名检测，可选设置相似性阈值。这是默认设置。这将覆盖 merge.renames 配置变量。另请参见 git-diff(1) 的 --find-renames。- rename-threshold=[=<n>]
find-renames= 的不推荐使用的同义词。- subtreesubtree[=<path>]
此选项是子树策略的更高级形式，该策略在合并时猜测两个树必须如何移位以与彼此匹配。相反，指定的路径前缀（或去掉开始的路径）以使两个树的形状匹配。recursive
这只能使用 3-way 合并算法解决两个头。当有多个可用于 3-way 合并的共同祖先时，它会创建共同祖先的合并树，并将其用作 3-way 合并的参考树。根据来自 Linux 2.6 内核开发历史的实际合并提交的测试结果，据报告称它导致了更少的合并冲突，而不会导致合并错误。此外，它可以检测和处理涉及重命名的合并。它不使用检测到的复制。这是从 Git v0.99.9k 到 v2.33.0 解决两个头的默认策略。
递归策略和 ort 具有相同的选项。但是，递归策略有三个 ort 忽略的额外选项（上面未记录），这些选项可能在递归策略中有用：
- patience
diff-algorithm=patience 的不赞成使用的同义词。- diff-algorithm=[patience|minimal|histogram|myers]
在合并时使用不同的 diff 算法，这可以帮助避免由于相似但不重要的匹配行（例如来自不同函数的大括号）而出现的错误合并。另请参阅 git-diff(1) 的 --diff-algorithm。请注意，ort 特别使用 diff-algorithm=histogram，而递归默认使用 diff.algorithm 配置设置。- no-renames
关闭重命名检测。这会覆盖 merge.renames 配置变量。另请参阅 git-diff(1) 的 --no-renames。resolve
这只能使用 3-way 合并算法解决两个头（即当前分支和另一个分支，从中拉取）。它会小心地检测交叉合并的模糊性。它不处理重命名。
octopus
这会解决多于两个头的情况，但拒绝进行需要手动解决的复杂合并。它主要用于将主题分支头捆绑在一起。这是在拉取或合并多个分支时的默认合并策略。
ours
这可以解决任意数量的头，但合并的结果树始终是当前分支头的树，实际上忽略了所有其他分支的所有更改。它旨在用来取代旧的侧分支开发历史。请注意，这与递归合并策略的 -Xours 选项不同。
subtree
这是修改后的 ort 策略。在合并树 A 和 B 时，如果 B 对应于 A 的子树，则首先调整 B 以匹配 A 的树结构，而不是在相同级别阅读树。这也适用于公共祖先树的调整。
对于使用 3-way 合并的策略（包括默认的 ort 策略），如果在两个分支上进行了更改，但后来在其中一个分支上撤消了更改，那么该更改将出现在合并结果中；有些人认为这种行为令人困惑。这是因为在进行合并时只考虑头和合并基，而不考虑单独的提交。因此，合并算法认为撤消的更改根本没有变化，然后替换了修改的版本。
