git合并递归他们的，它是如何工作的？

我遇到了一些问题。我们有我们自己的CMS，它使用git进行协作和版本控制。git合并递归他们的，它是如何工作的？

现在我有两个git仓库A和B，A是一个项目，B是CMS本身。现在，我想B插入A，但是当我这样做，我得到了很多的合并，冲突和冲突的解决总是要用的东东从B.

现在我觉得我需要的是

git merge <branch> -s recursive theirs <commit>

因为我想合并，当发生合并冲突时，它应该被迫使用B的解决方案。但我无法让它工作。它总是告诉我fatal: 'theirs' does not point to a commit。

The recursive theirs我找到了here。

有谁知道我做错了什么？

来源

2010-02-15 Daan Poron

的可能的复制[我该如何选择（？）合并策略为git rebase？]（http://stackoverflow.com/questions/2945344/how-do-i-select-a-merge-strategy-for-a-git-rebase） – Louis

您必须使用这种形式来传递合并策略选择：

git merge -s recursive -Xtheirs

另外，还要确保您的版本suppors -Xtheirs，这是一个相当最新功能

来源

2010-02-16 01:47:21 u0b34a0f6ae

这确实是错误的git版本，现在与新的它的工作..只有它不像我想的那样好，我得到所有的合并冲突，但没有一个包含任何冲突：s –

这个答案似乎错过了合并中的分支机构？ 'git merge -s递归-Xtheirs ' – robstarbuck

我认为它失败的原因是你指定“递归他们”作为策略。 “递归”是一种策略，当你在它之后放置一个空格时，“他们”被解释为git需要合并你的工作副本（例如另一个分支或refspec）。

我想你不能指定一个完全像你想要的策略。有一种叫做“我们的”的策略，与你想要的相反。

在这种情况下使用的通常模式是合并或重新绑定到“B”存储库。从“A”仓库的工作副本中，如果可能的话，您可以进行重定位（如果您已经与其他开发人员共享git仓库，这可能是不可能的）。一个rebase本质上会将A存储库放回到两个存储库中的常见提交中，应用“B”提交，然后提交“A”提交。您将一路解决任何合并冲突。

一旦通过合并或重新绑定到“B”存储库的痛苦，未来的合并将不那么痛苦。

来源

2010-02-15 19:39:57

git合并递归他们的，它是如何工作的？

回答

相关问题