git合并问题-强制合并

我在git有两个分支

分支开发和我的功能分支1300

Branch 1300是对Branch dev的一个完整重构。现在我已经完成了1300，希望将其合并到dev分支中

如何将force1300合并到dev中

当我在intellij中进行正常合并并接受它们的文件时（theris是1300），我在1300年删除的文件仍然在dev中

有强制合并的提示吗

---

提前感谢

Git中没有“强制合并”这样的东西。幸运的是，这不是你想要的。您需要的是git merge-s-theres。不幸的是，这并不存在。幸运的是，有办法伪造它。请看，我可以把它作为一个副本关闭，但我要写一个长格式的答案

Git提交，包括合并提交 单词merge有两个或两个以上的含义，这取决于您是将其用作动词、to merge还是形容词或名词：merge commit（形容词）或merge（形容词变成名词，如所示）。名词版本，一个merge，作为commit存在于您的存储库中，就像任何其他commit一样，只是它有两个，而不是通常的单亲。1

记住，在Git中，提交由两部分组成：快照（保存的一组文件）和一些元数据：关于提交的信息，例如谁做的、何时做的以及为什么做的。在元数据中，Git存储一些早期提交的哈希ID。这些是问题的父母。大多数普通提交都有一个单亲散列ID；使提交成为合并提交的原因是它有两个父级，而不是通常的父级。但它只有一个快照。该快照是合并结果

我发现这里的图片非常有用。首先，让我们画一幅简单的提交字符串的图片——一个“分支”，如果您愿意使用Git：

... <-F <-G <-H

这里，分支名称

功能

指向提交

J

，它指向提交

I

，它指向提交

H

，它指向提交

G

，依此类推。还有另一个名称，

main

，指向

H

，这一事实并不能阻止我刚才列出的所有提交都出现在两个分支上。然而，

main

指向

H

的事实确实阻止了提交

I

和

J

位于该分支上。通过并包括

H

的提交在两个分支上，而最后两个分支仅在

功能上

我们可以在任何时候添加和删除我们喜欢的任何名称。这里只有一些限制。例如，名称必须满足某些测试：
main
和
feature
都可以，但是
hello..world
不是因为禁止使用双点。名称还需要指向实际提交。2我不会涵盖所有内容，但您应该了解：我们可以在某些（合理）限制内创建和销毁任何名称。因此，我们可以在上图中添加一个名称
dev
，如下所示：

...--F--G--H   <-- dev, main
            \
             I--J   <-- feature

             I--J   <-- feature
            /
...--F--G--H
            \
             K--L   <-- dev (HEAD)

             I--J   <-- feature
            /    \
...--F--G--H      M   <-- dev (HEAD)
            \    /
             K--L

此图显示我们有两个提交（
I-J
）仅在
功能上，两个提交仅在
dev
上。
（HEAD）
表示法表明，我们目前使用的名称是
dev
，因此使用的是commit
L
，这是仅在
dev
上使用的名称之一


1从技术上讲，任何具有两个或多个父级的提交都是合并提交，但两个就足够了，典型的情况是具有两个

2这并没有技术上的原因，Git正在获得一个特性，在该特性中，对某些名称的约束将被放松，但目前所有名称都需要它，分支名称仍然需要它


合并为动词的机制
当您选择进行合并提交时，通常通过运行
git merge
-选择要绑定在一起的两个（或根据脚注1，更多）提交。其中一个是当前提交，在运行
git merge
之前选择它，通常使用
git checkout branch
或
git switch branch
。另一个是在命令行上命名的提交。因此，我们可以运行：

git checkout dev
git merge feature

例如.3Git随后将自行启动并找到第三个提交。第三个提交是合并基，合并基提供了合并操作的起点：to merge进程，或merge as verb

您的问题是，如果您的图片如下所示：

...--F--G--H   <-- dev, main
            \
             I--J   <-- feature

             I--J   <-- feature
            /
...--F--G--H
            \
             K--L   <-- dev (HEAD)

             I--J   <-- feature
            /    \
...--F--G--H      M   <-- dev (HEAD)
            \    /
             K--L

注意分支名称
dev
现在如何指向新提交，
M
，这是执行此合并过程的结果


3您可以添加
git merge--no ff
，以防止git进行快进而不是合并。我想人们可以将此视为强制合并，但这仍然不是您想要的。：-）


我们有一个
策略
策略就是Git如何实际实现合并为动词的过程。当您运行
git merge
时，这将执行一系列初步测试并处理各种命令行选项。允许的选项之一是
-s
，并且
-s
接受策略参数

Git的现成策略包括：


-s recursive
：这是通常的默认值。它实现了我们上面讨论的组合
-s resolve
：这是
-s recursive
的一个变体；它也是这样做的。我们不需要在这里讨论它们之间的技术差异，因为您的问题是希望避免合并
-s octopus
：这是一种用于合并两个以上提交的专用算法。这不是你想要的答案
-s ours
：这是另一个特殊用途的算法。这几乎就是你想要的

我们的
ours
策略所做的很简单：为了创建新快照，它完全