为什么git merge在源分支中创建提交

我正在尝试将补丁分支中的更改合并到主分支中。这是我在github中看到的信息：

kewp wants to merge 36 commits into patch/SEO_prices_pages from development

当我单击以解决冲突时，这是我看到的消息

Resolving conflicts between development and patch/SEO_prices_pages and committing changes development

---

为什么要将提交提交到

开发中

？我正在尝试用开发更改更新补丁分支…

问题中有一个基本缺陷：

为什么git merge在源分支中创建提交

没有。另一方面，GitHub

在这里定义术语非常重要，并且非常清楚地区分Git和GitHub的功能。GitHub不是Git！GitHub将为您托管一个Git存储库，然后他们添加自己的功能，让您使用他们的服务（而不是某些竞争对手的）。因此，当您使用GitHub的附加组件时，它们可能会做Git本身没有做的事情。（如果你喜欢这些东西，GitHub是成功的：记住，他们的目标是让你使用它们，并最终让你或其他人支付它们。）

设置 [GitHub告诉我]

kewp希望将36个提交合并到开发中的补丁/SEO\u价格\u页面中

[但存在合并冲突]

这里我假设

kewp

就是你，而

development

就是你从笔记本电脑/台式机/任何计算机向GitHub上的存储库发送一些提交时给GitHub的名字。然后，您使用GitHub的web界面生成GitHub Pull请求（PR），使用

开发

作为分支的合并，使用

补丁/SEO\u price\u页面

作为分支的合并，所有这些都在GitHub上的单个存储库中（因此这里不涉及额外的GitHub fork内容）

GitHub PR不是Git合并。但是，当您单击“makepr”按钮时，GitHub所做的工作涉及尝试在GitHub上存储的git存储库中进行

git合并。这种尝试可能成功，也可能失败。如果成功，则可以在GitHub上的Git中找到结果合并提交；如果不是，则不存在此类合并提交

GitHub PR分配了一个编号，该编号对于GitHub上的存储库是唯一的。（这是一个在该存储库中所有操作中都是全局的数字：issues和PRs共享数字空间，因此在没有活动的存储库中，如果在创建任何PRs之前创建了几十个问题，则第一个PR将有一个两位数字。）此数字将成为格式为
refs/pull/number
的Git命名空间。在此命名空间中，GitHub创建一个或两个名称：


refs/pull/number/head
指您请求合并的分支的提示提交；及
refs/pull/number/merge
，如果存在，则指GitHub成功进行的合并提交

此合并提交（尚未）在任何分支上。如果它存在，它就存在于GitHub的Git存储库中，并且可以在
merge
名称下找到，但是短语commit C位于Git中的分支B上通常被解释为可以从分支B的tip commit访问commit C

（有关可达性的更多信息，请参阅。）

同样，如果合并尝试失败，这里没有合并提交。由于您的案例中存在合并冲突，因此有一个
refs/pull/number/head
名称，但没有
refs/pull/number/merge
名称

合并在笔记本电脑上的工作原理
在笔记本电脑上使用Git时，可能会执行如下合并：

git checkout patch/SEO_prices_pages
git merge development

如果有冲突，您的Git将在合并的中间停止，部分完成的合并结果留在Git的索引和您的工作树中。现在，您可以使用Git在其索引和工作树中留下的内容来解决这些冲突，任何您喜欢的方式。然后告诉Git您已经解决了冲突，并使用：
git merge --continue

恢复（并完成这次）合并。结果是一个新的提交。新提交位于您签出的分支的顶端，即，
patch/SEO\u prices\u pages
。在
git merge
命令中命名的分支，即
development
，是完全不变的：该名称仍然保持在您开始所有这些操作之前保持的相同提交散列

合并解析过程发生在Git的索引中，但您的助手几乎肯定使用了工作树中的文件：您的计算机的非Git命令不能使用Git索引中的文件，因为它们是一种特殊的、压缩的、仅限Git的格式。要使用索引文件，您必须将其复制到某个地方（通常使用
git checkout
或
git checkout index
），然后在那里处理它，然后将其复制回旧的索引文件（通常使用
git add
）

最后的提交有两个父级：它的第一个父级是提交，这是刚才
patch/SEO\u prices\u pages
的提示，而它的第二个父级是提交，这仍然是
开发的提示

如何在GitHub上解决冲突
GitHub上的Git存储库没有工作树。（每一个都有一个索引，但它大部分只是残留的。）这意味着通常的工具不可用

GitHub所提供的，至少在今天，是一种诡计。他们将一些冲突信息保存在某个地方只有一个索引，可能有多个PRs“正在运行”，因此不清楚在哪里，尽管Git确实能够使用替代索引，所以每个PR可能有一个索引，虽然我猜不会，但因为没有工作树，没有地方可以只编辑一个文件，然后再次添加它

相反，当您使用GitHub的冲突解决工具时，它所做的是进行更多的提交。他们可以通过推进
ref/pull/number/head
ref来进行这些提交，我认为最终他们确实会推进，但是根据，他们添加了新的提交，它使用您的PR分支的tip提交文件作为起始点
git checkout development

<edit each file that had conflicts>
<git add each such file>
git commit
git push origin development