在“远程”本地分支上重新设置 master 是如何工作的？

Question

我是 git 新手，我一直在关注这个 tutorial。

我想我理解了大部分内容，直到我进入远程存储库。我理解的关于远程存储库的唯一概念是 git fetch 和 git remote。根据该教程， git fetch 通过 git remote 的 add 选项从指定的 url 获取远程存储库。它将存储库下载到“远程”分支中。如果我理解正确的话，它不是远程存储库中的分支，而是我从远程存储库下载的分支。它还不是我本地存储库的一部分，它仍然可以合并/重新定位到它（我的本地存储库）中。也许我错了，我在这里遗漏了一些东西，请随时纠正我。

现在，我觉得我完全不明白的是 git 如何设法将“远程”存储库重新定位到我的本地存储库。

我了解，当我对一个分支进行 rebase 时，它​​会将那个分支中的提交基于它最初分支的不同提交。我仍然必须将分支合并到我的主分支中。当我这样做时，实际上会发生什么？

git checkout master 
git fetch origin
git rebase origin/master

这不会将我的本地 master 分支重新设置为远程 master 分支吗？我一直在想这个picture。

我将拥有本地 master 分支而不是功能，而不是 Master，我将拥有远程 origin/master 分支。除了 Master 并没有真正分支出 origin/master。

这不会删除我的本地分支 master 吗？这不会将我所有的工作都转移到“远程”存储库中吗？另外，在推送到真正的远程存储库之前，我不需要合并回来？

Answer 1

这里的关键是，rebase 与 git 中大多数¹ 其他与分支相关的项目一样，确实是根据 提交图 而不是分支名称。分支名称用于一两个目的：

• 在提交图中定位提交，并且
• 仅在适用的情况下：移动分支以使其指向正确的提交

所以如果你运行：

git checkout master
git fetch origin
git rebase origin/master

第一步让您“进入分支主控”：它只是将master 写入HEAD²（当然还会更新您的工作树）。

第二步从origin 获取您还没有的任何提交。这些进入您的存储库，扩充提交 graph，并更新 origin/master 以指向那里的最新提交。例如，您可能在fetch 之前有过这个：

            * - *   <-- HEAD=master
          /
..- o - o           <-- origin/master

一旦fetch 完成，并且你的 git-borg 已经添加了 origin 的生物和技术独特性，你现在拥有：

            * - *   <-- HEAD=master
          /
..- o - o - o       <-- origin/master

此时，您可以将您的两次提交（*s 中的）git rebase 放到新的origin/master 的尖端。这实际上是通过制作提交的副本来工作的：你会得到两个新的，它们与旧的相同，但有不同的父 ID：它们链接 origin/master 的新提示而不是旧的 (pre-fetch) 提示。制作副本后，git rebase 调整您的分支 master 以指向新的最尖端提交。

（并且，为了与 Borg 主题保持一致，您的原始提交仍在您的存储库中。一旦 reflog 条目过期，它们最终会被丢弃，默认情况下是 30 天。）

---

¹这里的例外是只做分支名称的事情。例如，您可以使一个分支成为对另一个分支的间接引用。通常，这仅适用于HEAD。或者，您可以重命名一个分支，这与它指向的位置没有任何关系。

²更准确地说，它将ref: refs/heads/master 写入.git/HEAD。这就是“在一个分支上”所需要的：分支的全名放在那个文件中，加上“ref:(space)”前缀。