我不能确定,因为我不是那句话的作者。但我猜测作者所描述的混淆是“跟踪”和“远程跟踪”分支之间的普遍混淆。gitguys有一篇很棒的文章介绍了这个问题,你应该去读一下。他们有漂亮的图片和详细的解释。
以下是我的理解...
背景
举个例子,假设我们在github上有一个非常简单的git仓库,只有一个master
分支,并有几个提交(C1和C2,其中C2是当前提交)。当你克隆该仓库时...
git clone git@github.com:example/repo.git
当你执行 git clone
命令时,会发生以下两件事情:
- 你会将所有的提交记录(C1 和 C2)复制到你的本地电脑上。
- 你还会在本地电脑上创建一个名为
master
的新分支。这个分支是一个“跟踪分支”,它的 HEAD 指向 C2。这个分支被称为“跟踪分支”。
新的提交记录
到目前为止,一切都很正常。但是在你阅读这些说明的同时,有人提交了另一个提交记录(C3)并将其推送到远程仓库。现在想象一下,你听说了这个新的惊人提交记录,并决定自己检索它。
git fetch
这会做两件事情:
- 将所需的新提交(C3)复制到您的本地计算机。
- 以某种方式更新本地系统,让它们知道 origin 的
master
分支现在在 C3 上。
但问题是:本地系统如何知道 origin 的
master
分支在 C3 上?Git 肯定有一种方法在本地存储该信息,但存储在哪里呢?我们不能实际更改本地
master
分支,因为我们可能在该本地分支上有自己的提交或其他更改需要合并。它只是存储在其他未知的 Blob 中吗?
答案是:Git 实际上使用了第三个分支。目前,我们知道两个分支:
- 位于 GitHub 上的物理分支。
- 位于您计算机上的“跟踪分支”(您称之为
master
)。
原来还有第三个分支。你可能以前见过它:它叫做
origin/master
。它与这两个分支都不同。它被称为“远程跟踪分支”。
您可以将其视为位于本地
master
分支和 origin 的
master
分支之间的分支。它是您计算机上的一个实际 Git 分支(就像
master
一样),因此您可以像跳转到其他分支一样使用它。但是,有限制。
例如,您可以检查它...
git checkout origin/master
然而,你会收到一个看起来有点奇怪的消息...
Note: checking out 'origin/master'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at 12dbe6a... My awesome commit!
这个消息显示是因为“远程跟踪分支”是只读的。用户不能像操作
master
一样操纵它们,只有git系统本身可以对其进行更改(在获取时会这样做)。因此,从实现的角度来看,您可以将它们视为任何其他分支。但是,由于它们是只读的,通常不会像使用其他分支一样使用它们。
因此,实际上,我们混合了三个分支:
1. 物理位于github上的分支。
2. 物理位于您的计算机上的
origin/master
分支(“远程跟踪分支”)。
3. 物理位于您的计算机上的
master
分支(“跟踪分支”)。
回答问题...
因此,我认为真正的混淆可能在于“跟踪”和“远程跟踪”分支之间。有人会把
master
误认为是“远程跟踪分支”(毕竟,它确实从
origin/master
获取提交!),但实际上不是。它是一个“跟踪分支”,而它所跟踪的分支是
origin/master
。
origin/master
是“远程跟踪分支”。
当有人谈论git branch --track中的“跟踪”时,他们谈论的是您可以修改的“跟踪”分支。
当有人谈论“远程跟踪分支”时,他们谈论的是跟踪远程分支的只读分支。