我认为这里的答案是你混淆了 GitHub 和 Git。 GitHub 是一个托管 Git 存储库的站点，您可以使用托管存储库做各种事情，包括基本 Git 不提供的许多附加服务。 Git 本身就是这样的软件：
- 进行版本控制（在某种程度上）
- 通过提供存储文件的提交对象的分布式+复制数据库。
因此，您可以在自己的计算机（例如笔记本电脑）上安装 Git，然后在那里创建和操作一个或多个 Git 存储库。这些存储库包含提交，您所做的大部分事情最终都会导致添加新的提交。
您添加到笔记本电脑上您的 存储库的新提交仅在笔记本电脑上的存储库中。要将这些新提交提交给其他 Git（其他一些存储库管理软件，通常在其他机器上），您将 发送提交给他们，git push。如果另一个 Git 驻留在 GitHub 的一台计算机上，那很好：现在他们有了你的新提交（加上任何旧提交：当一个 Git 与另一个 Git 交谈时，他们通常会发送所有可能的提交，所有，虽然这里的细节很复杂）。
当您在笔记本电脑上使用git clone 时，您会让您的 Git（您笔记本电脑上的软件）创建一个新的空存储库，然后为其他 Git 保存一个 URL，例如 GitHub 上的一个。然后，您将 Git 连接到他们的 Git 并将他们的所有提交复制到您的存储库中。该复制步骤发生在git fetch 上，这与git push 正好相反——或者与Git 最接近的地方一样。你会认为git pull 是相反的，但事实并非如此。
那么，出了什么问题？好吧，您在笔记本电脑上做了一些提交，将它们发送到 GitHub，并使用 GitHub clicky Web 界面进行 GitHub 所谓的 pull request，这是 GitHub 的概念。 （基本 Git 没有拉取请求。）到目前为止，我们都很好。但是随后您使用 GitHub clicky Web 界面添加新提交到您在 GitHub 上的存储库。该提交在 GitHub 上的 Git 存储库中，但它不是在您的笔记本电脑上。
所以，然后您转到您的笔记本电脑 Git 并告诉它恢复提交，并为其提供提交的哈希 ID，仅存在于 GitHub 上的存储库中。你的 Git 说：什么？你到底在说什么？我没有738bd6a。那是因为......它没有那个提交。
要让您的 Git拥有该提交，您必须使用 git fetch 将您的 Git（您在笔记本电脑存储库中运行的软件）连接到他们的 Git（他们在您的 GitHub 存储库中运行的软件）或git pull。 git fetch 步骤是最关键的一步：你的 Git 会调用他们的 Git，他们会列出他们的分支名称和哈希 ID，你的 Git 会看到 738bd6a3bccab7d96e9e7f93871285eea72943cf 并自己思考：哦，嘿，我没有那个承诺！我最好请求它！你的 Git 会要求他们的 Git 发送它，他们会的，现在你将拥有738bd6a3bccab7d96e9e7f93871285eea72943cf。
虽然只有git fetch 将得到这个提交，但这还不够。您笔记本电脑上的存储库有提交，您的 Git 和他们的 Git 将相互共享。他们的存储库有提交，您的 Git 和他们的 Git 将相互共享。但是您和他们的存储库也都有分支名称，并且这些名称不共享：不完全是。
相反，当您的 Git 与他们的 Git 交谈并从他们那里获取提交时，您的 Git 会看到他们的分支名称，但 会更改这些名称。代替main 或master，您的Git 添加您的远程名称，origin，在前面加上一个斜线，因此名称现在是origin/main 或origin/master。这不是分支名称，而是远程跟踪名称。您的 Git 将新提交填充到您自己的存储库中，并根据需要创建或更新任何远程跟踪名称，以便能够找到这些提交。1
但是：你在你的 分支机构名称上工作。因此，一旦您从其他人那里获得了一些新的提交，您可能想要更新自己的分支。为此，您通常需要运行 git merge、git rebase 或其他一些其他 Git 命令。确切地使用哪个命令、何时以及为什么会涉及到相当多的内容，并且包括您特定工作场所的文化细节，因此很难说您应该首先使用哪个命令。但是，对于这种特殊情况，合并可能是正确的答案。
Git 的 git pull 命令为您运行 git fetch，然后（假设 fetch 步骤有效2）运行第二个 Git 命令，通常是 git merge 或 git rebase。3 因此，如果您知道 fetch 步骤将起作用并执行某些特定操作，则可以使用 git pull 作为快捷方式，而不是运行两个单独的命令。我建议新手无论如何都要使用这两个单独的命令，因为它有多种帮助：
- 它明确区分了
git fetch（始终安全，几乎始终有效）和第二条命令（有时不安全，通常无效）。
- 它允许您查看
git fetch 在您选择哪个要运行的第二个命令之前获取了什么。
- 当第二个命令失败时，您知道自己运行的是哪个命令，因此，在获得帮助时接下来的步骤是什么（合并与变基不同）。
Git 是 分布式的事实，因此每个 Git 克隆都可以拥有整个存储库的完整副本（直到它被克隆或最后一次使用 fetch 重新更新），对于许多 Git 新手来说，这很棘手。再加上其他各种 Git 命令的复杂性，Git 成为许多程序员的天坑。我鼓励你：
查看一个传入的提交如何更新origin/<somebranch>。注意新的提交是如何添加到分支的末端（正如你的远程跟踪名称所记住的那样），“向前移动分支”。您的 Git 现在反映了您使用 GitHub 的 Git 所做的事情。您现在可以更新您自己的分支，在这种情况下，它只会将您的分支名称向前移动，使用git merge 或git merge --ff-only。然后您可以恢复提交，将另一个提交添加到您自己的（本地）分支的末尾。沿途再次运行git log --graph 以观察这些更新。
最后，您可以git push 将新的提交提交到 GitHub 的 Git。这会将提交添加到链中，并向您展示另一个特点：当您使用 git fetch 时，您 get 提交 来自 它们，然后您的 Git 更新您的 远程跟踪名称。在您的存储库中，它们的每个 branch 名称都有一个远程跟踪名称，因此这是一件安全的事情。但是：当您运行git push 时，您会向他们发送一个新的提交，然后要求他们 更新一个他们的分支名称。他们在这里没有等效的远程跟踪名称。您只需让他们更新他们的分支名称。
由于我们（和 Git）喜欢使用分支名称查找提交，这最终会导致您（最终）遇到的问题，他们的 Git 说“我不会接受这个名称更新请求，因为它是一个非快进”。参见，例如，Git push rejected "non-fast-forward"。有时你想强迫他们接受这个更新：是的，扔掉一些提交，这些是他们新的和改进的替代品。有时你不会。
1您可能想知道为什么我们需要名称来查找提交。从技术上讲，我们不会：您可以一直使用738bd6a3bccab7d96e9e7f93871285eea72943cf。但是你明天会记得738bd6a3bccab7d96e9e7f93871285eea72943cf吗？如果它有一个简单易记的好名字作为别名，比如foobranch 或origin/foobranch，现在那个你可以记住了。
此外，分支名称会在您添加新提交时自动更新。远程跟踪名称会在您运行 git fetch 时自动更新，这会添加您从他们那里获得的任何新提交，这有点相同，只是不同。 branch 名称和 remote-tracking 名称之间的巨大区别，除了您的 Git 从 他们的 创建和更新您的远程跟踪名称这一事实之外em> branch 名称，是 git switch origin/<em>branch</em> 拒绝运行，git checkout origin/<em>branch</em> 将您置于“分离 HEAD”模式，这不是日常工作的好方法。
简而言之：branch 名称 = 你在哪里做你的事。 远程跟踪 名称 = 您的 Git 对其 Git 分支的记忆。使用git fetch 更新您的远程跟踪名称。