Github 解决冲突总是将基本分支合并到我当前的分支
Github resolving conflicts always merges base branch to my current branch
我在 PHP Storm 的本地分支机构工作。任务完成后，我提交我的分支并推送到 git.
在 Github 页面上，我创建了一个 Pull request DEV <- my branch。 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 点所说：
解决所有合并冲突后，单击提交合并。这会将整个基础分支合并到您的头分支中。
首先，最好及时了解功能分支中的 DEV 分支，因为无论如何您都必须在某个时候合并更改。我从来没有遇到过与 DEV 分支保持同步是不好的情况，但我可以想象一些场景。
上述问题的解决方法是继续在 Web 上进行合并，并允许将远程 DEV 分支合并到您的远程功能分支中。但是，您的本地功能分支仍在 DEV 合并之前的位置。
此时您可以强制将本地更改推送到远程分支，从而将远程功能分支重置到您想要的位置。
$ git fetch
$ git checkout feature-825
$ git push --force
tl;博士
the whole DEV base branch is merged to my own branch
这是 Github 冲突解决过程的一个特点。
来自 Resolving a merge conflict on Github：“8。解决所有合并冲突后，单击提交合并。这会将整个基本分支合并到您的头分支中。 " 但他们没有解释原因。
and this is not good
令人惊讶，但很好。我会在下面解释。
How is it possible to avoid this?
不要回避。但是可以让这个过程更顺利。
使您的分支与开发人员保持同步并解决任何冲突。然后提交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 通过了所有检查。您单击合并按钮并且存在冲突。您解决冲突并直接合并到开发中。
如果解决冲突时出错怎么办？
已解决的代码不是经过审查的代码。合并冲突表示 dev 中发生了一些您不知道且未考虑的更改。您刚刚编辑了您的分支以修复该问题，但尚未检查该工作。如果立即合并到开发中，没有什么可以阻止您的 PR 破坏每个人的开发。
相反，Github PR 需要像对待任何其他编辑一样处理手动冲突解决。与任何其他编辑一样，必须重新检查。已解析的代码必须位于存储库中的某个位置。因此 Github 将 dev 与冲突解决方案合并到您的分支中，就像您在提交 PR 之前更新了您的分支一样。现在可以重新检查您的分支是否有错误。已解析的代码通过检查，可以安全地合并。
所以 Github 正在做你应该在命令行上做的同样的事情。从 dev 更新你的分支，解决任何冲突，检查结果，然后合并。
注意：这是我有根据的猜测。我对Github.
没有什么特别的见解
最后，特征分支是短暂的。 。只要结果正确，具体的合并过程并不太重要。
我在 PHP Storm 的本地分支机构工作。任务完成后，我提交我的分支并推送到 git.
在 Github 页面上，我创建了一个 Pull request DEV <- my branch。 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 点所说：
解决所有合并冲突后，单击提交合并。这会将整个基础分支合并到您的头分支中。
首先，最好及时了解功能分支中的 DEV 分支，因为无论如何您都必须在某个时候合并更改。我从来没有遇到过与 DEV 分支保持同步是不好的情况，但我可以想象一些场景。
上述问题的解决方法是继续在 Web 上进行合并，并允许将远程 DEV 分支合并到您的远程功能分支中。但是，您的本地功能分支仍在 DEV 合并之前的位置。
此时您可以强制将本地更改推送到远程分支，从而将远程功能分支重置到您想要的位置。
$ git fetch
$ git checkout feature-825
$ git push --force
tl;博士
the whole DEV base branch is merged to my own branch
这是 Github 冲突解决过程的一个特点。
来自 Resolving a merge conflict on Github：“8。解决所有合并冲突后，单击提交合并。这会将整个基本分支合并到您的头分支中。 " 但他们没有解释原因。
and this is not good
令人惊讶，但很好。我会在下面解释。
How is it possible to avoid this?
不要回避。但是可以让这个过程更顺利。
使您的分支与开发人员保持同步并解决任何冲突。然后提交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 通过了所有检查。您单击合并按钮并且存在冲突。您解决冲突并直接合并到开发中。
如果解决冲突时出错怎么办？
已解决的代码不是经过审查的代码。合并冲突表示 dev 中发生了一些您不知道且未考虑的更改。您刚刚编辑了您的分支以修复该问题，但尚未检查该工作。如果立即合并到开发中，没有什么可以阻止您的 PR 破坏每个人的开发。
相反，Github PR 需要像对待任何其他编辑一样处理手动冲突解决。与任何其他编辑一样，必须重新检查。已解析的代码必须位于存储库中的某个位置。因此 Github 将 dev 与冲突解决方案合并到您的分支中，就像您在提交 PR 之前更新了您的分支一样。现在可以重新检查您的分支是否有错误。已解析的代码通过检查，可以安全地合并。
所以 Github 正在做你应该在命令行上做的同样的事情。从 dev 更新你的分支，解决任何冲突，检查结果，然后合并。
注意：这是我有根据的猜测。我对Github.
没有什么特别的见解最后，特征分支是短暂的。