是否可以解决拉取请求合并提交中的冲突？

Question

合并拉取请求时，可能存在需要在合并之前解决的冲突。
基本上有两种方式：

• rebase on top 解决冲突
• 拉取目标分支并解决冲突

拉取方法会在合并之前在分支中导致额外的合并提交（解决冲突），我不希望这样：

可以看出，该分支有一个node B，其中包含与node A 相关的更改。我希望分支的历史记录仅包含相关更改。

如果我做一个变基，分支的历史确实只会包含相关的变化。虽然如果node B 的更改依赖于node C 引入的更改将是模棱两可的。

node B 和 node C 中的更改在逻辑上是相互独立的。他们直接修改node A。

这是node A的文件：

first line: text node A
second line to be removed later
third line: text node A

node C只修改第一行和第三行：

first line: node C text
second line to be removed later
third line: node C text

node B 只是删除了第二行：

first line: text node A
third line: text node A

虽然逻辑上我在这里看不到任何冲突（来自两个节点的更改修改了不同的行），但是 git 将无法自动解决冲突。

1. 我能否解决初始拉取请求的合并提交中的更改？
2. 能否首先自动解决此类冲突？
3. 当更改影响不同的行时，为什么 git 会看到冲突？

---

我想在版本之间保持尽可能干净的 git 历史记录。观察者应该清楚哪些变化是相互依赖的，哪些不是。将独立更改直接应用到“基础”（发布提交）node A 有助于最大程度地减少主分支的突变。

Answer 1

你的三个问题最好分成至少两个独立的 StackOverflow 问题，但让我们试试这个：

1. 我能否解决初始拉取请求的合并提交中的更改？

Git 本身没有“拉取请求”，就像 GitHub 或 Bitbucket 有拉取请求一样。 Git 只有提交，拥有 Git 存储库的个人可以使用 git fetch 和 git merge 等命令获取和/或进行新提交，包括合并提交，当组合成一个命令时-line command——可以拼写为git pull。 git request-pull 命令会生成一封电子邮件，然后您可以使用任何电子邮件发送程序发送该电子邮件，要求其他人“拉”一些提交。

由于 Git 一开始就缺乏这些类型的拉取请求，因此简短的回答是“不”。如果我们查看 GitHub 和 Bitbucket 等网站，答案取决于托管网站。据我所知，GitHub 的当前答案仍然是“否”，尽管如果他们有一个功能，您也可以提供建议的最终合并提交，那可能会很好。¹ 我没有使用 Bitbucket 足以达到我什至可以推测他们的情况的地步。

1. 能否首先自动解决此类冲突？

否（但见下文）。

1. 当更改影响不同的行时，为什么 git 会看到冲突？

要合并的两个更改abut（触摸边缘）。确实存在不将这些视为冲突的合并算法，但经验表明结果经常被破坏。所以确实认为这些是冲突的合并算法是使用的（这是问题2答案的原因）。

当不使用像 GitHub 这样的托管站点时，这里的通常过程（根据我的经验）是直接合并到目标分支，在那里解决冲突，然后提交。生成的树（源快照）与您从目标分支合并到您进行 PR 的分支中得到的相同，但没有额外的合并提交。

---

¹这在技术上是可行的，但我不知道 GitHub 将如何将其作为用户可访问的界面。当您生成 GitHub PR 时，GitHub 将在内部：

• 运行 git merge 以查看自动合并是否有效。
• 如果是，则生成两个标签，refs/pull/<em>n</em>/head 和 refs/pull/<em>n</em>/merge，分别指向要合并的提交和测试合并的结果。
• 如果没有，则生成一个标签，refs/pull/<em>n</em>/head，指向待合并的提交。测试合并结果似乎已被丢弃。

添加第三个标签以提供建议的合并解决方案，并由制作 PR 的人提供提交，这可能是合理的。完整的细节取决于托管站点，但没有明显的外部原因甚至不能只使用refs/pull/<em>n</em>/merge 标签。