Github解决冲突总是将基础分支合并到我当前的分支中

时间:2020-11-05 18:29:31

标签: github merge merge-conflict-resolution

我正在PHP Storm的本地分支机构工作。任务完成后,我提交我的分支并推送到git。

在Github页面上,我创建了一个Pull请求DEV <-我的分支。 Dev是基础分支,我将合并其分支。

到目前为止还可以。但是如果某些文件存在冲突-根据本文https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github

在我的情况下,同一文件在其他分支中已更新,并且之前已合并到DEV。现在在我的分支中是具有其他更改的相同文件。

当我解决冲突(甚至可以是一行)时,我将其标记为已解决,然后提交合并。

现在发生了,整个DEV基本分支都合并到了我自己的分支中,这不好。

因为我正在将我的分支合并到DEV,反之亦然。如何避免这种情况?

我试图重新创建相同的分支,但是一旦将开发人员合并到此处,它便始终存在。每次冲突都会发生这种情况是无稽之谈-正如上述网络的8.点所述:

解决所有合并冲突后,请单击“提交合并”。这会将整个基础分支合并到您的head分支中。

enter image description here

2 个答案:

答案 0 :(得分:1)

tl; dr

整个DEV基础分支都合并到我自己的分支中

这是Github解决冲突过程的功能。

来自Resolving a merge conflict on Github:“ 8。解决了所有合并冲突后,请单击Commit merge。这会将整个基础分支合并到您的head分支中。”但是它们不会解释原因。

这不好

这是令人惊讶的,但是很好。我将在下面解释。

如何避免这种情况?

不要回避。但是可以使过程更加顺畅。

使您的分支与dev保持最新,并解决所有冲突。然后提交PR。

要在Github上执行此操作:Submit your PR as a draft;解决Github上的冲突;将其标记为可供审核。从草稿开始,您可以避免在解决冲突之前避免人们查看您的代码。

要在命令行上执行此操作:

# Bring dev up to date
$ git checkout dev
$ git pull

# Update your branch with the latest dev
$ git checkout <your branch>
$ git rebase dev       # or git merge dev

请注意,是的,您在提交要合并到dev中的分支之前将dev合并到了分支中。这是更新分支的正常过程。

您应该习惯性地更新分支机构,以减少分支机构与开发人员之间的偏差。这将使冲突解决方案更小且更易于管理。


是的,Github吗?

与任何审阅过程一样,Github PR过程是关于检查结果合并是否有效的过程。这可能涉及automated checks,运行分支的测试和手动审核。

让我们考虑一下它是否如您所愿地工作。您的PR通过了所有检查。您单击合并按钮,并且有冲突。您解决了冲突,然后直接合并为开发人员。

如果您在解决冲突时出错了?

已解析的代码不是已审查的代码。合并冲突表示您在开发中发生了一些您没有意识到且未解释的更改。您刚刚编辑了分支来解决此问题,并且尚未检查该工作。如果立即合并到开发者手中,您的公关就不会停止为每个人破坏开发者了。

相反,Github PR需要像其他任何编辑一样对待手动解决冲突。与其他任何编辑一样,必须重新检查它。解析的代码必须位于存储库中的某个位置。因此,Github将开发与冲突解决合并到您的分支中,就像您在提交PR之前更新了分支一样。现在可以重新检查您的分支是否有错误。解析的代码通过了可以安全合并的检查。

因此,Github正在执行您应该在命令行上执行的相同操作。从dev更新分支,解决所有冲突,检查结果,然后合并。

注意:这是我的有根据的猜测。我对Github没有任何特别的见识。


最后,要素分支是短暂的。 Once merged they should be deleted。只要结果正确,确切的合并过程就不太重要。

答案 1 :(得分:0)

首先,优良作法是在功能分支中保持DEV分支的最新状态,因为无论如何您都必须合并更改。我从来没有遇到过跟DEV分支保持最新的情况,但是我可以想象一些情况。

上述解决方法之一是继续在Web上进行合并,并允许将远程DEV分支合并到您的远程功能分支中。但是,您的本地功能分支仍位于DEV合并之前的位置。

这时,您可以强制将本地更改推送到远程分支,从而将远程功能分支重置到您想要的位置。

$ git fetch
$ git checkout feature-825
$ git push --force