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

#1 楼

将-X选项添加到theirs。例如：

git checkout branchA
git merge -X theirs branchB

一切都会以所需的方式合并。

我所见的唯一引起问题的是是否删除了文件来自branchB。如果除git之外的其他操作删除，它们将显示为冲突。

修复很容易。只需使用已删除的任何文件的名称运行git rm：

git rm {DELETED-FILE-NAME}

之后，-X theirs应该可以正常工作。

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


注意：还存在一个较长格式的选项。

要使用它，请替换：

-X theirs

替换为：

--strategy-option=theirs

#2 楼

将branchB合并到我们已签出的branchA中的可能且经过测试的解决方案：

 # 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的期望一样。

#3 楼

较早版本的git允许您使用“其”合并策略：

git pull --strategy=theirs remote_branch

但是，此内容已被删除，如Junio Hamano（Git维护者）。如链接中所述，您可以执行以下操作：

git fetch origin
git reset --hard origin

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

#4 楼

目前尚不清楚您期望的结果是什么，因此在答案及其评论中对“正确”的实现方式有些困惑。我尝试给出一个概述，并查看以下三个选项：

尝试合并并使用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）的答案确实如此。

仅使用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的答案是肯定的。

仅使用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的回答（不需要临时分支）。

#5 楼

从现在开始，我一直使用Paul Pladijs的答案。我发现，您可以执行“常规”合并，发生冲突，因此您可以使用其他分支的修订来解决冲突。

git checkout --theirs <file>

通过使用另一个分支的修订来解决冲突。如果对每个文件执行此操作，则将具有与

git merge <branch> -s theirs

相同的行为，无论如何，与合并策略相比，所做的工作要多！ （这已在git版本1.8.0中进行了测试）

#6 楼

我使用

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

解决了我的问题

#7 楼

当使用git merge在“ A”中合并主题分支“ B”时，出现一些冲突。我>知道所有冲突都可以使用“ B”中的版本解决。
我知道git merge -s ours。但是我想要的是像git merge> -s它们的东西。

我假设您创建了master的分支，现在想合并回master，覆盖其中的所有旧内容主。这正是我遇到这篇文章时想要做的。
完全按照您想要做的去做，除了首先将一个分支合并到另一个分支中。我只是这样做了，所以效果很好。

git checkout Branch
git merge master -s ours

然后，结帐母版并将您的分支合并到其中（现在它将顺利进行）：

git checkout master
git merge Branch

#8 楼

如果您在分支A上，请执行以下操作：

git merge -s recursive -X theirs B

在git版本1.7.8上进行了测试

#9 楼

要真正正确地进行合并，只合并您要合并的分支中的输入，就可以执行

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

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

git commit --amend

在我所知的任何情况下都不会发生冲突，您不必创建其他分支，并且它的行为就像正常的合并提交。

但是，子模块。

#10 楼

为什么不存在？


我在“使一个分支像另一个分支的git命令”中提到如何模拟git merge -s theirs，请注意，Git 2.15（2017年第四季度）现在更加清晰：


用于合并的“ -X<option>”文档被误导了
，以表明“ -s theirs”存在，事实并非如此。


请参阅Junio C Hamano（gitster）提交的c25d98b（2017年9月25日）（由Junio C Hamano合并-gitster-在commit 4da3e23中提交，2017年9月28日）


merge-strategies：避免暗示“ -s theirs”存在。

-Xours merge选项的描述带有圆括号
，告诉读者它与-s ours非常不同，
是正确的，但是后面的-Xtheirs的描述
粗心地说“这与ours相反”，给人一种错误的
印象，也需要警告读者，这是非常错误的
与q4312079不同q，实际上甚至不存在。


-s theirs是应用于递归策略的策略选项。这意味着递归策略仍将合并所有内容，并且只有在发生冲突的情况下才退回到“ -Xtheirs”逻辑。

有关theirs合并策略是否相关的争论被带回了
它承认较旧的（2008）线程。



总之，前面的讨论可以总结为“我们不想'theirs'因为它会导致错误的工作流程”。


它提到了别名：

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

雅罗斯拉夫·哈尔琴科（Yaroslav Halchenko）尝试再次倡导该策略，但Junio C. Hamano补充：


我们和他们之间不对称的原因是因为你是你而不是他们---我们历史及其历史的控制和所有权不是对称的。

一旦确定他们的历史记录是主线，您就希望将自己的开发线视为分支，并在该方向上进行合并，即，结果合并的第一个父项是对他们的历史的提交，第二个父母是您历史上的最后一个坏人。因此，您最终将使用“ -s theirs”来
使初生父母保持明智。

此时，使用“ checkout their-history && merge -s ours your-history”不再是缺少“ -s ours”的解决方法这是所需语义的适当部分，即，从尚存的规范历史行的角度来看，您想要保留其所做的事情，从而使其他历史行所做的事情无效。


Juno补充说，正如Mike Beaton所评论的那样：


-s theirs有效地表示“在其分支上由git merge -s ours <their-ref>组成的标记提交被视为永久忽略的提交”；这很重要，因为，如果您随后从其分支的较新状态进行合并，则将引入其较晚的更改，而不会引入被忽略的更改。

#11 楼

请参见Junio Hamano广为引用的答案：如果要丢弃已提交的内容，则只丢弃这些提交，或者无论如何都应将其排除在主要历史记录之外。为什么以后要打扰每个人都从没有提供内容的提交中读取提交消息？

但是有时存在管理要求，或者也许还有其他原因。对于那些确实必须记录不做任何贡献的提交的情况，您想要：

（编辑：哇，我以前设法弄错了吗。这个可行。）

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

#12 楼

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

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>

#13 楼

等价（保留父顺序）与'git merge -s他们的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}'

#14 楼

保罗·普拉迪斯（Paul Pladijs）给出了这个答案。为了方便起见，我只是接受了他的命令并为其添加了git别名。

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

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

那么您可以通过运行以下命令“ git merge -s thems A”：

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

#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

#16 楼

我认为您真正想要的是：

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

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

#17 楼

我最近刚刚需要对两个共享相同历史记录的独立存储库执行此操作。我从以下内容开始：


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中发出合并请求以使其成为新的主服务器，或者只是将其保留为分支。 br />

#18 楼

一种简单而直观的方法（在我看来）是以下两个步骤：

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

接着是

git merge -s ours branchB

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

唯一的缺点是它不会从当前分支中删除在branchB中已删除的文件。之后，将在两个分支之间进行简单的比较，以显示是否存在任何此类文件。

此方法还可以从修订日志中清楚地知道执行了哪些操作以及打算执行的操作。