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

Question

我正在尝试将补丁分支中的更改合并到主分支中。这是我在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

为什么要提交该提交development？我正在尝试使用开发更改来更新补丁分支......

Answer 1

这个问题有一个基本缺陷：

\n\n

\n

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

\n

\n\n

事实并非如此。另一方面，Git Hub ...

\n\n

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

\n\n

设置

\n\n

\n

[GitHub 告诉我] kewp wants to merge 36 commits into patch/SEO_prices_pages from development[但是存在合并冲突]

\n

\n\n

我假设这kewp就是您，development当您从笔记本电脑/台式机/任何计算机向 GitHub 上的存储库发送一些提交时，您为 GitHub 指定的名称。然后，您使用 GitHub 的 Web 界面生成 GitHub Pull Request (PR)，使用您的development作为合并源分支和patch/SEO_price_pages合并到分支，所有这些都在 GitHub 上的单个存储库中（这样就不需要额外的 GitHub 分支）这里涉及到一些东西）。

\n\n

GitHub PR 不是 Git 合并。然而，当您单击“make PR”按钮时，GitHub 所做的操作涉及尝试在 GitHub 上存储的 Git 存储库中进行操作。git merge这一尝试可能成功，也可能失败。如果成功，则可以在 GitHub 上的 Git 中找到生成的合并提交；如果不是，则没有这样的合并提交。

\n\n

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

\n\n

\n
• refs/pull/number/head指的是您要求合并的分支的提示提交；和
\n
• refs/pull/number/merge，如果存在，则指GitHub 成功进行的合并提交。
\n

\n\n

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

\n\n

（有关可达性的更多信息，请参阅Think Like (a) Git。）

\n\n

同样，如果合并尝试失败，则此处没有合并提交。由于您的情况存在合并冲突，因此有一个名称，但没有名称。refs/pull/number/headrefs/pull/number/merge

\n\n

合并在笔记本电脑上的工作原理

\n\n

当您在笔记本电脑上使用 Git 时，您可能会执行如下合并：

\n\n

git checkout patch/SEO_prices_pages\ngit merge development\n

\n\n

如果存在冲突，您的 Git 将在合并过程中停止，部分完成的合并结果将保留在 Git 的索引和工作树中。现在，您可以按照您喜欢的任何方式使用 Git 留在其索引和工作树中的内容来解决这些冲突。然后你告诉 Git 你已经解决了冲突，并使用：

\n\n

git merge --continue\n

\n\n

恢复（并完成这次）合并。结果是一个新的提交。新的提交位于 \xe2\x80\x94 上，并且在 \xe2\x80\x94 的顶端，您已签出的分支，即patch/SEO_prices_pages. 您在命令中命名的分支git merge（即 ）development完全未更改：该名称仍然保留与您开始所有这一切之前保留的相同提交哈希值。

\n\n

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

\n\n

最终提交有两个父项：其第一个父项是刚才的提示的提交，其第二个父项是仍然是的提示的提交。patch/SEO_prices_pagesdevelopment

\n\n

GitHub 上的冲突解决方式如何运作

\n\n

GitHub 上的 Git 存储库没有工作树。（每个都有一个索引，但它大多只是残留的。）这意味着常用的工具不可用。

\n\n

至少在今天，GitHub 提供的只是一种技巧。他们将一些冲突信息保存在某处\xe2\x80\x94那里只有一个索引，并且可能有多个PR“正在飞行”，所以根本不清楚在哪里，尽管Git确实有能力使用一个替代索引，所以也许每个 PR 都有一个索引，尽管我猜不是 \xe2\x80\x94，但由于没有工作树，所以没有地方可以编辑文件然后git add再次编辑。

\n\n

相反，当您使用 GitHub 的冲突解决工具时，GitHub 所做的就是进行更多提交。他们可以通过推进引用来进行这些提交，我认为最终他们确实会推进它，但根据他们自己的信息页面，他们添加了新的提交\xe2\x80\x94，它使用你的 PR 分支的提示提交\'s文件作为起点，但进行的更改将导致与您的分支不存在冲突\xe2\x80\x94 。refs/pull/number/headgit merge

\n\n

在这种情况下，这意味着他们：

\n\n

\n
• 从 on-GitHub-repo 顶部的提交中提取文件development；
\n
• 允许您对每个有冲突的文件进行更改，这样，如果这是作为 的新提交development，这些文件将不再与 ; 的提示提交中的文件发生合并冲突patch/SEO_prices_pages。
\n
• 允许您将此提交添加到您的 on-GitHub-repo。
\n

\n\n

这相当于您在笔记本电脑上执行以下操作：

\n\n

git checkout development\n

\n\n

（注意：这假设您的developmentGitHub 匹配development！）然后：

\n\n

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

\n\n

当然，如果直接使用 GitHub 存储库执行此操作，您还无法在笔记本电脑上获得提交。

\n\n

现在您的 GitHub 存储库development已包含此新提交，GitHub 可以再次尝试git merge。这次合并将会成功，他们将能够创建.refs/pull/number/merge

\n\n

有关 GitHub 怪异的更多注释

\n\n

当您实际上被允许在 GitHub 上合并时，您会看到绿色的“合并”按钮有一个下拉箭头。使用下拉菜单，您会看到有三个选项：

\n\n

\n
• 合并
\n
• 变基和合并
\n
• 挤压并合并
\n

\n\n

第一个就按照它说的做。它使用正常的日常合并\xe2\x80\x94（GitHub 已经制作的一个可以很好地执行\xe2\x80\x94），并像往常一样将其添加到目标分支。

\n\n

第二个将每个要合并的提交复制到扩展目标分支的新提交。即使要合并的提交已经处于正确的位置（从图表角度来看）以进行快进，GitHub 也会执行此操作。（我自己也觉得这很令人讨厌：他们应该快进。）

\n\n

最后一个相当于运行git checkout <target>; git merge --squash ...。它可能通过在 GitHub 上运行来使用现有合并中的树git commit-tree，但效果是相同的。

\n