我知道这个问题已经有答案了，但这个问题让我困惑了很多次，所以我建立了一个小的参考网站来帮助我记住: https://nitaym.github.io/ourstheirs/

以下是基本原则:

合并:

$ git checkout master 
$ git merge feature

如果你想在master中选择版本:

$ git checkout --ours codefile.js

如果您想在功能中选择版本:

$ git checkout --theirs codefile.js

重置:

$ git checkout feature 
$ git rebase master 

如果你想在master中选择版本:

$ git checkout --ours codefile.js

如果您想在功能中选择版本:

$ git checkout --theirs codefile.js

(当然，这是针对完整的文件)

我知道这个问题已经有答案了，但这个问题让我困惑了很多次，所以我建立了一个小的参考网站来帮助我记住: https://nitaym.github.io/ourstheirs/

以下是基本原则:

合并:

$ git checkout master 
$ git merge feature

如果你想在master中选择版本:

$ git checkout --ours codefile.js

如果您想在功能中选择版本:

$ git checkout --theirs codefile.js

重置:

$ git checkout feature 
$ git rebase master 

如果你想在master中选择版本:

$ git checkout --ours codefile.js

如果您想在功能中选择版本:

$ git checkout --theirs codefile.js

(当然，这是针对完整的文件)

Git中的“our”指的是原始的工作分支，它在Git历史中具有权威/规范的部分。

“their”指的是保存工作以便重基于的版本(要在当前分支上重放的更改)。

这可能会被那些没有意识到做重基(例如git重基)实际上是在暂停你的工作(这是他们的)，以便重放到我们的规范/主历史上，因为我们将我们的更改作为第三方工作重基。

Git -checkout的文档在Git >=2.5.1中根据f303016提交得到了进一步的澄清:

--ours --theirs When checking out paths from the index, check out stage #2 ('ours') or #3 ('theirs') for unmerged paths. Note that during git rebase and git pull --rebase, 'ours' and 'theirs' may appear swapped; --ours gives the version from the branch the changes are rebased onto, while --theirs gives the version from the branch that holds your work that is being rebased. This is because rebase is used in a workflow that treats the history at the remote as the shared canonical one, and treats the work done on the branch you are rebasing as the third-party work to be integrated, and you are temporarily assuming the role of the keeper of the canonical history during the rebase. As the keeper of the canonical history, you need to view the history from the remote as ours (i.e. "our shared canonical history"), while what you did on your side branch as theirs (i.e. "one contributor's work on top of it").

对于git-merge，它的解释如下:

ours This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected to the merge result. For a binary file, the entire contents are taken from our side. This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring our history contains all that happened in it. theirs This is the opposite of ours.

此外，这里解释了如何使用它们:

合并机制(git merge和git pull命令)允许使用-s选项选择后端合并策略。一些策略也可以有自己的选项，可以通过给git merge和/或git pull提供-X<option>参数来传递。

所以有时它会让人困惑，例如:

git将-Xours是我们的本地分支，- xtheir是他们的(远程)分支 git拉origin master -r where -Xours是他们的(远程)，- xtheir是我们的

第二个例子与第一个相反，因为我们在远程分支的基础上重新建立了分支，所以我们的起点是远程分支，我们的更改被视为外部的。

git合并策略也类似(-X我们的和-X他们的)。

我将把我的备忘录贴在这里，因为我必须一次又一次地回到这里。

场景1。普通开发人员:你是不能合并到精通的开发人员，只能使用功能分支。

案例1:主人是国王。你想要刷新你的特性分支(= rebase to master)，因为master包含了新的依赖项更新，而你想要覆盖你的小改动。

git checkout master
git pull

git checkout feature
git rebase -X ours master

情况2:你是国王。你想要重新建立你的特性分支来控制变化。但是您比您的同事做得更多，并且希望优先使用您自己的更改。

git checkout master
git pull

git checkout feature
git rebase -X theirs master

重要提示:正如你所看到的，普通的开发人员应该更喜欢重新创建数据库，并像每天早上锻炼/喝咖啡一样重复它。

场景2。合并老师:你是一个团队领导，想合并其他分支，并将合并的结果直接推给一个主。Master是一个分支，你会改变。

案例1:master is a king您想要合并第三方分支，但master是优先级。Feature是你前辈做的一个分支。

git checkout feature
git pull

git checkout master
git merge -X ours feature

当你的高级开发人员发布了一个很酷的功能，你想要覆盖主分支中的旧的东西。

git checkout feature
git pull

git checkout master
git merge -X theirs feature

记住:在午夜记得该选择哪一个:主人永远是我们的。这是他们的特色。

没有精确的含义，因为这些术语的含义完全相反，这取决于你是在合并还是重基。思考两个分支的自然方式是“我的工作”和“别人的工作”。混淆这种分类的术语选择绝对是git中最糟糕的设计选择。它一定是受到了会计的“信用”和“借方”或“资产”和“负债”的启发——同样令人头疼。

澄清一下，如上所述，重基的意思是相反的，所以如果你看到

<<<<<<< HEAD
        foo = 12;
=======
        foo = 22;
>>>>>>> [your commit message]

使用'mine' -> foo = 12解决

解决使用'their ' -> foo = 22