如果发现从分支 A 到分支 B 的拉取请求有冲突，解决后，合并总是以双向方式发生。为什么会这样？

Question

当我们将分支 A 的拉取请求合并到分支 B 时，我们希望只有分支 A 中的更改进入分支 B。如果拉取请求中没有发现冲突，则合并的行为就像我们预期的那样。但是，如果有冲突，我们解决之后，然后执行合并操作，分支 B 的所有更改也会进入分支 A。为什么 GitHub 会这样合并？

以下步骤概述了针对 2 个场景重现此现象的过程。

1. 发现有冲突的拉取请求：

   1. 主分支有一个名为a.txt的文件，里面只有一行文字。

   2. 从主分支创建一个feature1分支，在feature1分支修改a.txt中的一行文字

   3. 然后，在主分支中，修改a.txt中的同一行文本，并添加一个名为b.txt的新文件。

   4. 此时从feature1分支向主分支提交pull request

   5. pull request显示有冲突，解决冲突合并后发现主分支的b.txt也合并到feature1分支了

2. 发现没有冲突的拉取请求：

   1. a.txt中的一行文字在feature1分支再次修改

   2. 主分支没有修改a.txt，而是新增了一个名为c.txt的文件。

   3. 拉取请求从 feature1 分支提交到主分支。

   4. pull request显示没有冲突，合并后发现主分支的c.txt没有合并到feature1分支。

结论：解决拉取请求中的冲突并合并时，两个分支的更改将被双向合并，导致主分支和 feature1 分支具有相同的内容。但是，当 pull request 中没有冲突时，只有来自 feature1 分支的更改会被单向合并到主分支中，而主分支中的任何更改都不会合并到 feature1 分支中。

问题：我不明白双向合并行为与拉取请求中发现的冲突。这不是我所期望的。我只想在我的拉取请求中将更改从 feature1 分支带到主分支，而不是在合并后将更改从主分支带回 feature1 分支。谁能告诉我原因吗？

我已经在问题内容中提供了所有细节。

Answer 1

这不是我所期望的。我只想在我的拉取请求中将更改从 feature1 分支带到主分支，而不是在合并后将更改从主分支带回 feature1 分支。

为此，您需要在目标分支（主要）之上重新设置您的功能分支。

假设你从 main（旧提交）做了分支：

git switch feature_branch
git fetch
git rebase origin/main
# resolve any conflict locally
git push --force

您的 PR 将被更新，并且符合合并条件的更改将只有

feature_branch

.