Question

我有一个拉请求，Github说它无法自动合并。这个改变主要是一些提交，但没有冲突。

手动合并我没有任何冲突，我得到了这个输出：

(on master)
$git merge otherbranch
[vim pops up for commit message, :wq]
Auto-merging <file>
Merge made by the 'recursive' strategy.
<file> | 1 +
1 file changed, 1 insertion(+)

这就是为什么Github无法自动合并的原因？它无论如何都会从命令行自动合并。这对Github来说不够自动吗？

Answer 1

原因是git merge默认使用称为“递归”合并的策略。它能够执行3向合并：从一侧获取补丁，并将该补丁应用到另一侧，以生成新文件。它也是递归地执行此操作，在更复杂的情况下，已经发生了大量分支和合并，并且有两个提交合并的多个合并基础。

我最近遇到了同样的情况：

$ git merge-base --all 90d64557 05b3dd8f
711d1ad9772e42d64e5ecd592bee95fd63590b86
f303c59666877696feef62844cfbb7960d464fc1
$

有2个合并基础，无法进行3向合并。因此，“递归”策略通过首先递归到这两个提交的合并来解决这个问题：

$ git merge-base 711d1ad9 f303c596
3f5db59435ffa4a453e5e82348f478547440e7eb
$

好的，只有一个合并基础，因此可以开始3向合并。什么是两边的变化？

$ git diff --stat 3f5db594 711d1ad9
 normalize/coll.py      | 116 ++++++++++++++++++++++++++++++++++++++-----------
 normalize/visitor.py   |  49 ++++++++++-----------
 tests/test_property.py |  10 +++--
 3 files changed, 120 insertions(+), 55 deletions(-)
$ git diff --stat 3f5db594 f303c596
 normalize/identity.py  | 38 +++++++++++++++++++++++++++++++-------
 tests/test_property.py |  2 ++
 2 files changed, 33 insertions(+), 7 deletions(-)
$

这两个差异都对同一个文件进行了更改，因此无法使用从每一侧获取每个文件的较新版本的简单策略（索引合并）来解析它们。相反，git从一侧获取新文件，并尝试从另一端应用补丁。结果是组合提交，可以这样模拟：

$ git checkout -b tmp
Switched to a new branch 'tmp'
$ git reset --hard f303c59666877696feef62844cfbb7960d464fc1
HEAD is now at f303c59 record_id: throw a more helpful error if record identity is not hashable
$ git merge 711d1ad9772e42d64e5ecd592bee95fd63590b86
Auto-merging tests/test_property.py
Merge made by the 'recursive' strategy.
 normalize/coll.py      | 116 ++++++++++++++++++++++++++++++++++++++-----------
 normalize/visitor.py   |  49 ++++++++++-----------
 tests/test_property.py |  10 +++--
 3 files changed, 120 insertions(+), 55 deletions(-)
$ git diff --stat 3f5db594 HEAD tests/test_property.py
 tests/test_property.py | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)
$

然后使用此合并结果作为起点返回到原始的3向合并;这也涉及对同一文件的更改：

$ git diff --stat HEAD 90d64557| grep selector
 normalize/selector.py          |  17 +--
 tests/test_selector.py         |  19 ++--
$ git diff --stat HEAD 05b3dd8f| grep selector
 normalize/selector.py  | 29 +++++++++++++++++------------
 tests/test_selector.py |  9 +++++++++
$

然而，对文件的不同部分进行了更改，因此将diff应用到另一侧是成功的。

所以，C git能够通过首先在两个起始点的两个合并基础上进行3向合并，然后在合并的两个原始提交上进行另一个3向合并来解析此合并第一次合并的结果。

Github的自动解决方案不会这样做。它不一定是无能为力的，而且我不确定它实现了多少递归策略，但它在谨慎方面犯了错误，这正是你所期望的那样的大绿色按钮： - ）。< / p>

Answer 2

不，这不是merging. It is about rebasing。

您应该尝试在otherbranch之上的本地仓库（克隆为 your fork ），master进行变更。

首先，确保master是原始上游回购中的最新版本：

fork

cd /your/local/repo
git remote add upstream /url/original/repo
git fetch upstream

# Make sure you don't have any local commmit on your master
git branch -f master upstream/master # reset your master branch 
                                     # to the one from upstream repo
git checkout otherbranch
git rebase master

该rebase会产生您应该解决的冲突，git add，然后是git rebase --continue。

最后，只需push --force您的分支到您的分支：将自动更新您的请求（无其他事情可做）。

git push -u -f otherbranch origin

（如果它已被推过一次，仅git push就足够了）

请参阅more tips about pull-requests here。

Answer 3

默认情况下，Git在确认合并提交的提交消息之前，不知道它是否可以自动合并您的分支。

如果您知道自己没有任何冲突，可以通过将Get authentication token from LinkedIn If successful, get id, email, firstname, lastname from LinkedIn. Try find a user in our user table with email or linkedin id. If no user create, storing linkedin id, email, firstname, lastname Login to our site.更改为非交互式工具来自动执行此递归自动合并过程，例如添加GIT_EDITOR或{ {1}}：

cat

^{true的情况相同。您还可以指定合并策略，例如GIT_EDITOR=true git merge otherbranch
或pull。}

或其他方法是重新绑定（将-X theirs添加到-X ours命令中）。

Github无法合并分支，没有冲突，手动自动合并

3 个答案: