是否可以解决 Pull Request 合并提交中的冲突？
Is it possible to resolve conflicts within a Pull Request merge commit?
合并拉取请求时可能存在需要在合并之前解决的冲突。
基本上有两种方式：
- 重新定位于解决冲突
- 拉取目标分支并解决冲突
拉取方法会导致在合并之前在分支中进行额外的合并提交（解决冲突），我不希望这样：
可以看出，该分支有一个 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 将无法自动解决冲突。
- 我可以在初始拉取请求的合并提交中解决更改吗？
- 这样的冲突能在第一时间自动解决吗？
- 为什么 git 在更改影响不同行时会出现冲突？
我想保持 git 版本之间的历史尽可能干净。对于观察者来说，哪些变化是相互依赖的，哪些不是。将独立更改直接应用于“基础”（发布提交）node A 有助于最大程度地减少主分支的突变。
你的三个问题最好分成至少两个单独的 Whosebug 问题，但让我们试试这个：
- Can I resolve changes within a merging commit for an initial pull request?
Git 本身没有“拉取请求”，在某种意义上，GitHub 或 Bitbucket 有拉取请求。 Git 只有 提交 ，拥有 Git 存储库的个人可以获得 and/or 进行新提交，包括合并提交，使用像 git fetch 和 git merge，它们组合成一个命令行命令时可以拼写为 git pull。 git request-pull 命令生成一封电子邮件，然后您可以使用任何电子邮件发送程序发送该消息，要求其他人“拉取”一些提交。
由于 Git 首先缺乏这些类型的拉取请求，简短的回答是“否”。如果我们查看 GitHub 和 Bitbucket 等网站，答案取决于托管网站。据我所知，GitHub 的当前答案仍然是“否”，尽管如果他们有一个功能，您也可以提供建议的最终合并提交，这可能会很好。1 我对 Bitbucket 的使用还不够多，以至于我什至无法推测他们的情况。
- Can such conflicts be resolved automatically in the first place?
否（但见下文）。
- Why does git see conflicts when changes affect different lines?
要合并的两个更改abut（触摸边缘）。确实存在不将这些视为 冲突 的合并算法，但经验表明结果经常被破坏。因此， 认为这些冲突的合并算法是使用的算法（这是问题 2 的答案的原因）。
当不使用像 GitHub 这样的托管站点时，这里通常的过程（根据我的经验）是直接合并到目标分支，在那里解决冲突，然后提交。生成的 tree（源快照）与从目标分支合并到您创建 PR 的分支所获得的相同，但没有额外的合并提交。
1这在技术上是可行的，但我不知道 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标签。