是否有“git merge -s ours”的“他们的”版本？

Question

当使用git merge 将主题分支“B”合并到“A”时，我遇到了一些冲突。我知道使用“B”中的版本可以解决所有冲突。

我知道git merge -s ours。但我想要的是git merge -s theirs。

为什么不存在？在与现有 git 命令发生冲突合并后，如何获得相同的结果？ （git checkout B 中每个未合并的文件）

仅丢弃分支 A 中的任何内容（合并提交点到树的 B 版本）的“解决方案”不是我想要的。

Answer 1

尚不完全清楚您想要的结果是什么，因此在答案及其 cmets 中对“正确”的执行方式存在一些混淆。我尝试给出一个概述，并查看以下三个选项：

尝试合并并使用 B 解决冲突

这不是“git merge -s ours 的他们的版本”而是“git merge -X ours 的他们的版本”（git merge -s recursive -X ours 的缩写）：

git checkout branchA
# also uses -s recursive implicitly
git merge -X theirs branchB

这就是例如Alan W. Smith's answer 会。

仅使用 B 的内容

这会为两个分支创建一个合并提交，但会丢弃来自branchA 的所有更改，只保留来自branchB 的内容。

# Get the content you want to keep.
# If you want to keep branchB at the current commit, you can add --detached,
# else it will be advanced to the merge commit in the next step.
git checkout branchB

# Do the merge an keep current (our) content from branchB we just checked out.
git merge -s ours branchA

# Set branchA to current commit and check it out.
git checkout -B branchA

请注意，现在合并提交的第一个父级来自branchB，只有第二个来自branchA。这就是例如Gandalf458's answer 会。

仅使用 B 中的内容并保持正确的父级顺序

这是真正的“他们的git merge -s ours 版本”。它的内容与之前的选项相同（即仅来自branchB），但父母的顺序是正确的，即第一个父母来自branchA，第二个来自branchB。

git checkout branchA

# Do a merge commit. The content of this commit does not matter,
# so use a strategy that never fails.
# Note: This advances branchA.
git merge -s ours branchB

# Change working tree and index to desired content.
# --detach ensures branchB will not move when doing the reset in the next step.
git checkout --detach branchB

# Move HEAD to branchA without changing contents of working tree and index.
git reset --soft branchA

# 'attach' HEAD to branchA.
# This ensures branchA will move when doing 'commit --amend'.
git checkout branchA

# Change content of merge commit to current index (i.e. content of branchB).
git commit --amend -C HEAD

这就是 Paul Pladijs's answer 所做的（不需要临时分支）。

特殊情况

如果branchB 的提交是branchA 的祖先，git merge 不起作用（它只是退出并显示“已经是最新的。”这样的消息）。 p>

在这种或其他类似/高级情况下，可以使用低级命令git commit-tree。

Answer 2

类似的替代方案是--strategy-option（短格式-X）选项，它接受theirs。例如：

git checkout branchA
git merge -X theirs branchB

但是，这更相当于 -X ours 而不是 -s ours。主要区别在于 -X 执行常规递归合并，使用所选一侧解决任何冲突，而 -s ours 将合并更改为完全忽略另一侧。

在某些情况下，使用-X theirs 而不是假设的-s theirs 的主要问题是删除文件。在这种情况下，只需使用已删除文件的名称运行 git rm：

git rm {DELETED-FILE-NAME}

之后，-X theirs 可能会按预期工作。

当然，使用git rm 命令进行实际删除将首先防止冲突发生。

Answer 3

为什么不存在？

虽然我在“git command for making one branch like another”中提到了如何模拟git merge -s theirs，但请注意 Git 2.15（2017 年第四季度）现在更加清晰：

用于合并的“-X<option>”文档具有误导性 写来暗示“-s theirs”存在，事实并非如此。

参见Junio C Hamano (gitster) 的commit c25d98b（2017 年 9 月 25 日）。
^{（由 Junio C Hamano -- gitster -- 合并于 commit 4da3e23，2017 年 9 月 28 日）}

合并策略：避免暗示“-s theirs”存在

-Xours合并选项的描述有括号 这告诉读者它与-s ours 非常不同， 这是正确的，但它后面的-Xtheirs 的描述 漫不经心地说“这与ours相反”，给了一个假 印象是还需要警告读者，这是非常 不同于-s theirs，实际上根本不存在。

-Xtheirs 是一个应用于递归策略的策略选项。这意味着递归策略仍然会合并任何它可以合并的东西，并且只会在发生冲突时回退到“theirs”逻辑。

关于 theirs 合并策略是否相关的争论最近又回到了 in this Sept. 2017 thread。
它承认older (2008) threads

简而言之，前面的讨论可以总结为“我们不想要'-s theirs'，因为它会鼓励错误的工作流程”。

它提到了别名：

mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u $1' -

Yaroslav Halchenko 试图再次倡导该策略，but Junio C. Hamano adds：

我们的和他们的之所以不对称，是因为你是你而不是他们——我们的历史和他们的历史的控制权和所有权是不对称的。

一旦您决定他们的历史是主线，您宁愿将您的开发线视为一个分支并朝该方向进行合并，即结果合并的第一个父项是对他们历史的提交第二个父母是你历史上最后一个坏人。所以你最终会使用“checkout their-history && merge -s ours your-history”来 保持第一父母的理智。

到那时，使用“-s ours”不再是缺少“-s theirs”的解决方法。
它是所需语义的适当部分，即从点从幸存的规范历史线的角度来看，您想保留它所做的，而取消另一条历史线的所作所为。

正如Mike Beaton 评论的那样，Junio 补充道：

git merge -s ours <their-ref> 有效地表示“将在其分支上直到 <their-ref> 的提交标记为永久忽略的提交”；
这很重要，因为如果您随后从其分支的后续状态合并，他们以后的更改将被引入，而忽略的更改永远不会被引入。

Answer 4

此答案由 Paul Pladijs 给出。为了方便起见，我只是接受了他的命令并做了一个 git 别名。

编辑您的 .gitconfig 并添加以下内容：

[alias]
    mergetheirs = "!git merge -s ours \"$1\" && git branch temp_THEIRS && git reset --hard \"$1\" && git reset --soft temp_THEIRS && git commit --amend && git branch -D temp_THEIRS"

然后你可以通过运行“git merge -s theirs A”：

git checkout B (optional, just making sure we're on branch B)
git mergetheirs A

Answer 5

旧版本的 git 允许您使用“他们的”合并策略：

git pull --strategy=theirs remote_branch

但这已被删除，正如Junio Hamano（Git 维护者）在此消息中所解释的那样。如链接中所述，您可以这样做：

git fetch origin
git reset --hard origin

但请注意，这与实际的合并不同。您的解决方案可能是您真正想要的选择。

Answer 6

一种简单直观（在我看来）的两步方法是

git checkout branchB .
git commit -m "Picked up the content from branchB"

紧随其后

git merge -s ours branchB

（将两个分支标记为合并）

唯一的缺点是它不会从当前分支中删除已在 branchB 中删除的文件。之后两个分支之间的简单差异将显示是否有任何此类文件。

这种方法还可以从之后的修订日志中清楚地看出做了什么 - 以及打算做什么。

Answer 7

'git merge -s theirs branchB'的等价物（保持父顺序）

合并前：

！！！确保您处于清洁状态！！！

合并：

git commit-tree -m "take theirs" -p HEAD -p branchB 'branchB^{tree}'
git reset --hard 36daf519952 # is the output of the prev command

我们做了什么？ 我们创建了一个新的提交，我们和他们的两个父母，提交的内容是 branchB - 他们的

合并后：

更准确地说：

git commit-tree -m "take theirs" -p HEAD -p 'SOURCE^{commit}' 'SOURCE^{tree}'

Answer 8

要真正正确地进行合并，仅从您正在合并的分支中获取输入，您可以这样做

git merge --strategy=ours ref-to-be-merged

git diff --binary ref-to-be-merged | git apply --reverse --index

git commit --amend

在我所知道的任何情况下都不会发生冲突，您不必进行额外的分支，并且它就像一个正常的合并提交。

然而，这对子模块并不好。

Answer 9

我最近才需要为共享共同历史的两个独立存储库执行此操作。我开始了：

• Org/repository1 master
• Org/repository2 master

我希望将来自repository2 master 的所有更改应用于repository1 master，接受repository2 将进行的所有更改。在 git 的术语中，这个 应该 是一个名为 -s theirs 但它不存在的策略。请小心，因为 -X theirs 的命名方式就像您想要的那样，但它不 相同（它甚至在手册页中这么说）。

我解决这个问题的方法是转到repository2 并创建一个新分支repo1-merge。在那个分支中，我运行了git pull git@gitlab.com:Org/repository1 -s ours，它融合得很好，没有任何问题。然后我把它推到遥控器上。

然后我回到repository1 并创建一个新分支repo2-merge。在那个分支中，我运行git pull git@gitlab.com:Org/repository2 repo1-merge，它将完成问题。

最后，您要么需要在repository1 中发出合并请求以使其成为新的主节点，要么将其保留为分支。

Answer 10

我想你真正想要的是：

git checkout -B mergeBranch branchB
git merge -s ours branchA
git checkout branchA
git merge mergeBranch
git branch -D mergeBranch

这看起来很笨拙，但应该可以。我唯一不喜欢这个解决方案的想法是 git 历史记录会令人困惑......但至少历史记录将被完全保留，您不需要为已删除的文件做一些特殊的事情。

Answer 11

当使用 git merge 合并“A”中的主题分支“B”时，我遇到了一些冲突。我>知道使用“B”中的版本可以解决所有冲突。

我知道 git merge -s ours。但我想要的是 git merge >-s their.

我假设您从 master 创建了一个分支，现在想要合并回 master，覆盖 master 中的任何旧内容。这正是我看到这篇文章时想要做的。

做你想做的事，除了先将一个分支合并到另一个分支。我刚做了这个，效果很好。

git checkout Branch
git merge master -s ours

然后，checkout master 并合并你的分支（现在可以顺利进行）：

git checkout master
git merge Branch

Answer 12

这个使用 git 管道命令读取树，但缩短了整体工作流程。

git checkout <base-branch>

git merge --no-commit -s ours <their-branch>
git read-tree -u --reset <their-branch>
git commit

# Check your work!
git diff <their-branch>

Answer 13

请参阅Junio Hamano's widely cited answer：如果您要丢弃已提交的内容，只需丢弃已提交的内容，或者无论如何将其保留在主要历史记录之外。以后为什么还要打扰每个人从没有提供任何东西的提交中阅读提交消息？

但有时存在管理要求，或者可能是其他一些原因。对于那些您确实必须记录无贡献的提交的情况，您需要：

（编辑：哇，我以前是不是弄错了。这个有效。）

git update-ref HEAD $(
        git commit-tree -m 'completely superseding with branchB content' \
                        -p HEAD -p branchB    branchB:
)
git reset --hard

Answer 14

将分支 B 合并到我们签出的分支 A 的可能且经过测试的解决方案：

# in case branchA is not our current branch
git checkout branchA

# make merge commit but without conflicts!!
# the contents of 'ours' will be discarded later
git merge -s ours branchB    

# make temporary branch to merged commit
git branch branchTEMP         

# get contents of working tree and index to the one of branchB
git reset --hard branchB

# reset to our merged commit but 
# keep contents of working tree and index
git reset --soft branchTEMP

# change the contents of the merged commit
# with the contents of branchB
git commit --amend

# get rid off our temporary branch
git branch -D branchTEMP

# verify that the merge commit contains only contents of branchB
git diff HEAD branchB

要使其自动化，您可以使用 branchA 和 branchB 作为参数将其包装到脚本中。

此解决方案保留合并提交的第一个和第二个父级，就像您对 git merge -s theirs branchB 所期望的一样。

Answer 15

这会将您的 newBranch 合并到现有的 baseBranch 中

git checkout <baseBranch> // this will checkout baseBranch
git merge -s ours <newBranch> // this will simple merge newBranch in baseBranch
git rm -rf . // this will remove all non references files from baseBranch (deleted in newBranch)
git checkout newBranch -- . //this will replace all conflicted files in baseBranch

Answer 16

从现在开始，我就使用了 Paul Pladijs 的答案。我发现，你可以做一个“正常”的合并，发生冲突，所以你这样做

git checkout --theirs <file>

通过使用来自其他分支的修订来解决冲突。如果对每个文件都执行此操作，您将获得与

所期望的相同的行为

git merge <branch> -s theirs

无论如何，努力比合并策略要多！ （这是用 git 版本 1.8.0 测试的）

Answer 17

如果你在分支 A 做：

git merge -s recursive -X theirs B

在 git 版本 1.7.8 上测试

Answer 18

我用

解决了我的问题

git checkout -m old
git checkout -b new B
git merge -s ours old