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

Question

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

9

我正在使用PHP Storm在本地分支上工作。完成任务后，我会提交我的分支并将其推送到git。

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

到此为止还好。但是，如果某些文件存在冲突-根据这篇文章https://docs.github.com/cn/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github

在我的情况下，该文件已经在其他的分支中进行了更新并合并到了DEV分支中。现在，在我的分支中有相同的文件和其他更改。

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

现在发生的是，整个DEV基础分支被合并到了我的分支中，这不太好。

因为我在将我的分支合并到DEV中，而不是反过来。如何避免这种情况发生呢？

我尝试重新创建同一个分支，但一旦DEV被合并到这里，它就一直存在。这对于每个冲突都发生这种情况是无意义的-如上述网页的第8点所述：

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

- Darksymphony

“整个DEV基础分支都合并到我的分支”这是不应该发生的。你确定你是将你的分支合并到dev，而不是将dev合并到你的分支吗？你能展示一下导致这种情况的命令吗？还有git log --graph --decorate --oneline --all，它会显示合并后的dev和你的分支。 - Schwern

1

我是在Github网页上进行操作，而不是在控制台中。就像我写的那样，DEV <- mybranch。在Pull request中，它说将mybranch合并到DEV中。在Pull request中只有我的分支，但是在我解决冲突并提交后，Pull request中出现了一个新行，上面写着Merge branch 'dev' to mybranch。这类似于我问题中提供的链接中的步骤（3-8）。在冲突解决页面中，我只需删除<<<<<<<，=======，>>>>>>>字符，然后保留必要的代码即可。 - Darksymphony

正如您在我的截图中看到的那样，它说想将2个提交从825合并到DEV。然而，只有在我解决了冲突文件后，第二个提交才出现在那里。由于某种原因，它将dev合并到了我的分支中。每当我在那里解决冲突时，都会发生这种情况。正如我在提供的链接中提到的那句话，他们说：一旦您解决了所有合并冲突，请单击“提交合并”。这将整个基本分支合并到您的头分支中。 - Darksymphony

这是正常的，但我无法解决Git上的冲突。在这里也有一个答案：https://github.community/t/why-does-github-merge-base-into-feature-branch-after-conflict/1027 - Darksymphony

好的，我现在明白Github在做什么了。 - Schwern

2个回答

0

首先，及时跟进DEV分支的功能分支是一个好习惯，因为在某些时候你必须合并这些变更。我从未遇到过及时跟进DEV分支会带来负面影响的情况，但我可以想象出一些场景。

针对上述情况的一个解决方法是继续在Web上进行合并，并允许远程DEV分支合并到你的远程功能分支中。然而，你的本地功能分支仍然停留在DEV合并之前的位置。

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

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

- Shell Code

每个分支应该只包含人们的工作，这些分支合并到dev。将dev合并到每个分支中是奇怪的。然后，如果我在本地获取远程分支，它也会将所有文件从dev拉入我的分支中，而我的分支中应该只有我的文件。然后我们还创建了一个发布分支，其中应该只包含准备好生产的分支（没有合并的dev），因为我们只应该发布那些分支，而不是整个dev，因为可能还有未准备好发布的分支。Git的官方答案是在本地解决冲突-请参见我上一篇帖子中的链接。 - Darksymphony

1

@Darksymphony git fetch 只从服务器获取状态和文件，它不会将更改拉入当前分支。我认为我正在使用我的 dev 分支，就像你使用 release 分支一样，因为通常准备用于生产的东西驻留在 QA 服务器上。是的，那是个好主意！在本地解决冲突。我可能错过了最后一个链接。 - Shell Code

我一定会尝试学习如何通过命令行或本地解决冲突，但我知道只有在git上创建拉取请求后才会出现冲突。如果我看不到文件中的差异，不确定如何通过命令行解决它。 - Darksymphony

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Schwern · Accepted Answer

简短概述

整个DEV基础分支已合并到我的分支中

这是Github冲突解决过程的一个特性。

从在Github上解决合并冲突中了解：" 8. 一旦您解决了所有合并冲突，单击提交合并。这将整个基础分支合并到您的主分支中。" 但他们没有解释为什么。

这不好

这很出乎意料，但这是好的。我将在下面解释。

如何避免这种情况？

不要避免它。但可以使这个过程更加顺畅。

将您的分支更新到dev并解决任何冲突。然后提交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合并到您的分支中。这是将分支更新的正常流程。

您应该经常将您的分支更新以减少分支与dev之间的偏离量。这将使冲突解决更小且更易管理。

为什么这样做，Github？

Github的PR流程和任何审查流程一样，都是为了检查合并后是否能正常工作。这可能涉及自动化检查、运行分支测试和手动审查。

让我们考虑一下如果它按照您的意愿工作。您的PR通过了所有检查。您点击合并按钮，但出现了冲突。您解决了冲突并直接合并到dev中。

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

解决的代码不是被审查的代码。合并冲突表示dev中发生了您不知道并且没有考虑到的更改。您只是编辑了您的分支来修复它，并且那项工作还没有被检查。如果立即合并到dev中，没有任何阻止您的PR对每个人都破坏dev的东西。

相反，Github PR 需要像其他编辑一样处理手动冲突解决。与其他编辑一样，它必须被重新检查。已解决的代码必须存储在仓库中。所以Github将 dev 与您的分支合并以及冲突解决，就像您在提交PR之前更新了您的分支一样。现在可以重新检查您的分支是否有错误。如果已解决的代码通过了检查，则可以安全地进行合并。

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

注意：这是我猜测的教育猜测。我没有任何对Github的特殊洞察。

最终，特性分支是短暂的。一旦合并，它们应该被删除。确切的合并过程并不太重要，只要结果正确即可。