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

Question

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

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

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

就我而言，相同的文件已在其他分支中更新并之前合并到 DEV 中。现在在我的分支中有相同的文件和其他更改。

当我解决冲突（甚至可以是一行）时，我将其标记为已解决并提交合并。

现在，整个 DEV 基础分支被合并到我自己的分支中，这不太好。

因为我正在将我的分支合并到 DEV，而不是相反。如何才能避免这种情况呢？

我尝试重新创建相同的分支，但是一旦开发合并到这里，它就始终存在。每次冲突都会发生这种情况，这是无稽之谈 - 正如上述网络的第 8 点所说：

解决所有合并冲突后，单击提交合并。这会将整个基础分支合并到您的头分支中。

Answer 1

太长了；博士

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

这是Github冲突解决流程的一个特点。

来自解决 Github 上的合并冲突：“ 8. 一旦解决了所有合并冲突，请单击提交合并。这会将整个基础分支合并到您的头分支中。 ”但他们没有解释原因。

这不好

这很令人惊讶，但也很好。下面我会解释一下。

如何才能避免这种情况呢？

不要回避它。但可以让这个过程更加顺利。

让您的分支与开发人员保持同步并解决任何冲突。然后提交 PR。

要在 Github 上执行此操作：以草稿形式提交您的 PR；解决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 流程的目的是检查合并结果是否有效。这可能涉及自动检查、运行分支测试和手动审核。

让我们考虑一下它是否如您所愿。您的 PR 通过了所有检查。你点击合并按钮，就会出现冲突。您解决冲突并直接合并到开发中。

如果您在解决冲突时犯了错误怎么办？

已解析的代码不是已审核的代码。合并冲突表明开发中发生了您不知道且没有考虑到的更改。您刚刚编辑了分支来修复该问题，并且该工作尚未经过检查。如果立即合并到开发中，就没有什么可以阻止你的 PR 破坏每个人的开发。

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

所以 Github 正在做你应该在命令行上做的同样的事情。从开发更新您的分支，解决所有冲突，检查结果，然后合并。

注意：这是我的一个有根据的猜测。我对Github没有什么特别的见解。

最后，功能分支是短暂的。一旦合并，它们就应该被删除。只要结果正确，具体的合并过程并不太重要。