git merge recursive theirs，它是如何工作的？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2268172/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
git merge recursive theirs, how does it work?
提问by Daan Poron
I'm having a bit of a problem. We have our own CMS which is using git for collaboration and versioning and stuff.
我有点问题。我们有自己的 CMS，它使用 git 进行协作和版本控制等。
Now I have two git repositories A and B, A which is a project and B which is the CMS itself. Now i want to get B into A, but when i do this i get alot of merge-conflicts and the solution for the conflicts is always to use the stuff from B.
现在我有两个 git 存储库 A 和 B，A 是一个项目，B 是 CMS 本身。现在我想让 B 进入 A，但是当我这样做时，我遇到了很多合并冲突，冲突的解决方案总是使用 B 中的东西。
Now what I think i need is
现在我认为我需要的是
git merge <branch> -s recursive theirs <commit>
because I want to merge and when there is a merge conflict it should be forced to use the solution from B. But i can't get it to work. It always keeps telling me fatal: 'theirs' does not point to a commit.
因为我想合并，当出现合并冲突时，应该强制使用 B 的解决方案。但我无法让它工作。它总是告诉我fatal: 'theirs' does not point to a commit。
The recursive theirsI found here.
在recursive theirs我发现在这里。
Does anyone know what I do wrong?
有谁知道我做错了什么？
回答by u0b34a0f6ae
You must use this form to pass merge strategy options:
您必须使用此表单来传递合并策略选项：
git merge -s recursive -Xtheirs # short options
git merge --strategy recursive --strategy-option theirs # long options
Also make sure your version supports -Xtheirs, that's a quite recent feature(?)
还要确保您的版本支持-Xtheirs，这是一个相当新的功能（？）
回答by Jess Bowers
I think the reason it's failing is that you are specifying "recursive theirs" as the strategy. "recursive" is a strategy, and when you put a space after it, "theirs" is interpreted as something git needs to merge your working copy with (eg. another branch or refspec).
我认为它失败的原因是您将“递归他们的”指定为策略。“递归”是一种策略，当你在它后面放一个空格时，“他们的”被解释为 git 需要将你的工作副本与之合并的东西（例如另一个分支或 refspec）。
I think you will not be able to specify a strategy exactly like what you want. There is a strategy called "ours" which is the opposite of what you are wanting.
我认为您将无法完全按照您想要的方式指定策略。有一种称为“我们的”的策略，它与您想要的相反。
The usual pattern used in this situation is to either merge or rebase to the "B" repository. From within the "A" repository's working copy, you would do a rebase, if possible (it might not be possible, if you are already sharing the git repo with other developers). A rebase would essentially roll the A repository back to a common commit within both repositories, apply "B" commits, then "A" commits on top. You'd resolve any merge conflicts along the way.
在这种情况下，通常使用的模式是合并或变基到“B”存储库。如果可能，您将在“A”存储库的工作副本中进行变基（如果您已经与其他开发人员共享了 git 存储库，则这可能是不可能的）。变基本质上会将 A 存储库回滚到两个存储库中的公共提交，应用“B”提交，然后“A”提交在顶部。您将在此过程中解决任何合并冲突。
Once you go thru the pain of either merging or rebasing to the "B" repository, the future merges will be less painful.
一旦您经历了合并或重新定位到“B”存储库的痛苦，未来的合并将不那么痛苦。
