Egit 理解 FETCH_HEAD 行为

Question

1. 在 Github 上创建了一个 repo（使用自述文件初始化）。
2. 用 Egit 克隆它。
3. 看到 FETCH_HEAD 和 HEAD 已签出。
4. 转到 Github 并更改了自述文件。
5. 已提取更改。
6. 看到 HEAD 已检出，但 FETCH_HEAD 没有。但 FETCH_HEAD 确实有自述文件更新。 origin/master 的跟踪分支也有更新。
7. 将 origin/master 的跟踪分支合并到我的本地 master 中。
8. 看到 FETCH_HEAD 和 HEAD 都再次签出。

据此贴：What does FETCH_HEAD in Git mean?

FETCH_HEAD 是一个短暂的 ref，用于跟踪刚刚发生的事情 从远程存储库中获取。

为什么 FETCH_HEAD 没有在提取后立即检出？为什么我将 origin 的跟踪分支合并到本地 master 后它才被签出？

Answer 1

为什么FETCH_HEAD 没有在提取后立即签出？为什么我将 origin 的跟踪分支合并到本地 master 后才被签出？

FETCH_HEAD 本身不引用任何分支：它只记住最后获取的 SHA1。
因为它没有引用分支，所以它并没有真正被检出（也不应该被检出），或者你最终会得到一个 detached head。

但是，将跟踪分支合并到 master 分支将更新 HEAD（指向更新的主分支）：该分支已签出。
如果合并是"fast-forward" one，则签出分支HEAD 和FETCH-HEAD 将引用相同的SHA1，给人的印象是FETCH_HEAD 已“签出”（它不是真的）

---

也就是说，在下图中：

FETCH_HEAD 有“签出”标记只是因为它引用了与当前签出分支 HEAD 相同的 SHA1（此处为 master）。

这意味着，如果您进行新的提交：

• FETCH_HEAD 将不再有签出刻度（它仍会引用最后获取的 SHA1）。这就是为什么我说它不是“真正”签出（在“它不会在新提交后保持签出的意义上，因为它是一个固定 引用特定的 SHA1)
• HEAD 和 master 分支将引用新的 SHA1，并保持已签出的勾选。

但是，如果您要直接签出 FETCH_HEAD SHA1（在将其合并到 master 之前：the Egit User Guide 提到如果引用尚未签出，您可以这样做），那么：

• FETCH_HEAD 仍将被“签出”
• HEAD 相同
• 但master（或任何其他分支）将不再签出：这是DETACHED HEAD situation

如果您要在签出的 FETCH_HEAD 之上进行 new 提交：

• FETCH_HEAD 将不再被签出（因为它仍然固定在最后获取的 SHA1 上）
• HEAD 将指向签出的新提交。
• 不会“签出”任何分支：分离的 HEAD。

您需要打开在 FETCH_HEAD 之上完成的签出提交，并从那里创建一个分支：

（来自文章“Git Lesson: Be mindful of a detached head”）

---

总结：

每次您在 FETCH_HEAD 引用上看到“已签出标记”时，这是因为 它引用的 SHA1 与当前签出的引用相同（提交或分支)。
不是，因为FETCH_HEAD 本身已被签出：如果您在其上执行新的提交，它将不再被签出。