如果我们想在不经历所有合并冲突的情况下解决工作树中的所有冲突更改，还要保留所有不冲突的更改，那么我们就在正确的地方学习如何做到这一点。

合并策略

在将工作合并到开发主线时，我们应该选择一种合并策略。

如果不选择未指定的合并策略，Git 会根据提供的分支自动选择合并策略。

-s 选项可以添加指定策略的名称。
当你拉取或者合并分支时，Git 会默认选择递归策略。
递归策略只能检测和执行涉及重命名的合并，但不能使用检测到的副本。
我们的选项强制冲突部分通过偏向“我们的”版本来自动解决。
与我们这边没有冲突的另一棵树的变化反映在合并输出中。

他们的选项有利于解决冲突的另一个合并树。

git pull 和 git merge 命令

执行 git pull 命令从远程存储库中获取和下载内容，并将更改集成到本地存储库中；因此，它被称为 git fetch 和 git merge 的混合。

git merge 的基本用途是将两个分支和多个提交合并为一个历史记录。
合并提交被认为是独一无二的，因为它们有两个父提交。
创建新的合并提交时，Git 会自动合并单独的历史记录。
两个历史记录中更改的数据不会合并。
这称为“版本控制冲突”。

自动解决合并冲突

如果我们更喜欢其他开发人员的工作而不是工作，我们可以通过优先考虑其他开发人员的工作来提及解决冲突的适当策略。

git pull -s recursive -X theirs <remoterepo or other repo>

或者，简单地说，对于默认存储库：

git pull -X theirs

如果我们已经在不使用他们的策略的情况下拉取并希望在冲突文件之一中优先考虑其他开发人员的工作，请运行以下命令：

git checkout --theirs path/to/file

如果我们已经处于冲突状态并希望在所有冲突文件中优先考虑其他开发人员的工作，请运行 git checkout 和 git add 命令：

git checkout --theirs .
git add .

如果我们偏爱自己编写的代码，那么我们应该使用 --ours ，而不是 --theirs ，如下所示：

git checkout --ours .
git add .

但是，这很严重，因此在运行之前请确保。

我们不能使用“.”并键入文件名代替要结帐的点。

我们还可以在 git merge 中使用递归 --theirs 策略选项：

git merge --strategy-option theirs