Question

给出一个包含两个分支master和feature的git仓库。使用rebase master在master上重新定位功能分支时，可以说文件a.txt包含需要在rebase继续之前解决的冲突。

我知道我可以分三步解决冲突：

在我的编辑器中打开a.txt手动解决冲突
致电git add a.txt告诉git我已手动解决冲突
致电git rebase --continue移动rebase前进

有没有办法通过告诉git我想要来自master分支的文件版本或者我想要来自feature分支的文件版本而不必执行上面的步骤1和2来避免第1步。

Answer 1

是。事实上，实现目标的方法不止一种。

rebase和merge（以及cherry-pick，就此而言）命令都使用相同的strategy和-X标志传递给底层的git merge机制。对于recursive策略，-Xours和-Xtheirs在合并两个分支中修改文件的情况下选择文件的一个或另一个“边”。

或者 - 这是完全不同的 - 在合并因冲突而停止的情况下，您可以将git checkout与--ours或--theirs标记一起使用，从一侧或另一侧挑选版本。（您可以使用其他命令执行此操作;在这里，我将坚持使用--ours和--theirs，因为它们与使用合并机制的命令的参数匹配。）

这当然是不同的，因为您可以切换选择：

$ git checkout main
Switched to branch 'main'
$ git merge branch
... conflicts in files A and B ...
$ git checkout --ours -- A    # takes main:A
$ git checkout --theirs -- B  # takes branch:B

请注意，这与“我们的策略”完全不同（上面显示了带有recursive选项的“ours策略”）。使用“我们的策略”，会发生完全不同的事情。让我们从没有它开始，再次进行相同的合并：

$ git checkout main && git merge branch
... conflicts ...
$ git checkout --ours -- A B  # take main:A and main:B

假设有第三个文件C，git可以自行合并。当您执行上述操作时，git会合并C，您可以main:A和main:B。但是，如果您使用git merge --strategy=ours branch，则git将使用main:A，main:B和main:C。它会丢弃branch:C更改而不是自动合并它们。

我上面使用git merge因为它使“我们的”和“他们的”东西“正常”。我不喜欢git命名这些的方式，因为当你做一个rebase时，我们/他们的版本会被换掉，因为rebase通过改变到“other”分支并做一系列的挑选来工作。那就是：

$ git checkout mine; git rebase theirs

通过做（非常）粗略的等效于：

来在下面工作

$ git checkout theirs; git cherry-pick theirs..mine

然后，将分支标签移动，使分支theirs实际上不移动。（内部并没有那么糟糕:-)但是它确实使--ours意味着“他们的”和--theirs意味着“我们的”，这是非常糟糕的外部。）

Answer 2

您可以使用：

git checkout --ours -- path/to/file

或者：

git checkout --theirs -- path/to/file

...在合并或重组期间选择特定版本的冲突文件;因为变基是a little strange，--theirs在这种情况下是feature的版本，--ours将是master。

Answer 3

我相信你正在寻找的，将摆脱所有这三个步骤，

git rebase master -X theirs

将自动解决有利于feature（当前已检出的分支）或

的冲突

git rebase master -X ours

ours和theirs的意义与反叛的论点相反，如http://git-scm.com/docs/git-rebase选项说明中所述

在git rebase中解决冲突时如何从一个分支中选择文件？

3 个答案: