Git:如果我一直在分离的头状态下进行多次提交,那么我会因为退出而失去任何东西吗?

发布于 2025-01-11 17:19:37 字数 170 浏览 0 评论 0原文

不久前,我检查了以前的提交,然后再次检查了我最近的提交。我当时并没有意识到这一点,但这让我处于一种超然的头脑状态。从那时起我已经完成了多次提交,并且仍然处于分离的头部状态。我知道我可以通过执行 git checkout来摆脱这种状态,但是如果我这样做,我会失去任何东西吗?

A while ago I checked out a previous commit, then checked out my most recent commit again. I didn't realize this at the time, but that left me in a detached head state. I've done multiple commits since then, and am still in the detached head state. I know I can get out of this state by doing git checkout <branch name>, but if I do this will I lose anything?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

萌︼了一个春 2025-01-18 17:19:37

我可以通过执行 git checkout 来摆脱这种状态,但如果我这样做,我会失去任何东西吗?

是的,您将丢失在分离头模式下所做的所有提交,因为没有分支名称会指向它们。 (您不会立即完全丢失它们,但它们将被销毁,并且访问它们将变得更加困难。)

因此,只需先创建一个分支,以保留它们并为您提供引用它们的方法。

git switch -c temp

现在可以安全地签出branchname

但实际上,在您的情况下,由于您的 HEAD 实际上位于您希望分支所在的位置,因此您可以将分支名称移动到您现在所在的位置。根本不需要temp

git switch -C branchname 

I can get out of this state by doing git checkout <branch name>, but if I do this will I lose anything?

Yes, you will lose all the commits you've made in detached head mode, because no branch name will be pointing to them. (You won't totally lose them immediately, but they will be slated for destruction, and accessing them will become more difficult.)

So simply create a branch first, to retain them and give you a way to refer to them.

git switch -c temp

Now it's safe to checkout branchname.

Actually in your case, though, since your HEAD is in fact where you wish your branch was, you can just move your branch name to where you are now instead. No need for temp at all.

git switch -C branchname 
汹涌人海 2025-01-18 17:19:37

我当时没有意识到这一点,但这让我处于一种超然的头脑状态

这就是为什么我提到最近的(Git 2.23 ,2019 年第 3 季度) git切换命令。

您无法使用 git switch并且没有意识到您最终会处于分离的 HEAD 状态,因为这样的命令实际上会失败,错误消息:

fatal: a branch is expected, got <commitID>
If you want to detach HEAD at the commit, try again with the `--detach` option

请参阅“为什么我的 Git 存储库进入分离 HEAD 状态?”。
使用 --detach 选项的提示来自 Git 2.36(2022 年第 2 季度)


使用 Git 2.45(2024 年第 2 季度),第 18 批git checkout/switch --detach foo(man),之后切换到分离的 HEAD 状态,提供了“foo”分支的跟踪信息,这是毫无意义的。

请参阅 提交 b9f2e1a(2024 年 3 月 30 日),作者:Junio C Hamano (gitster)
(由 Junio C Hamano -- gitster -- 合并于 提交 847af43,2024 年 4 月 12 日)

结帐:省略“跟踪”信息一个独立的头部

报告人:mirth hickford

根据定义,分离的 HEAD 状态是暂时的,并且没有配置它始终想要与之集成的“上游”。
但是,如果您从上游后面的分支分离,例如,

$ git checkout -t -b main origin/main
$ git checkout 主要
$ git reset --hard HEAD^
$ git checkout --分离主要

您会看到“您位于上游源/主干后面”。
当您将上述最后一步替换为其中任何一个时,不会发生这种情况

$ git checkout HEAD^0
$ git checkout --分离 HEAD
$ git checkout --分离origin/main

3266967之前(checkout:引入--分离“git checkout”的同义词foo^{commit}", 2011-02-08, Git v1.7.5-rc0 -- 合并)(签出:介绍--detach 同义词 git checkout"(man)) 引入了“--detach " 选项,决定是否显示跟踪信息的规则曾经是:

<块引用>

如果未给出--quiet,并且给定的分支名称是真实的
本地分支(即我们可以计算出文件路径的分支)
.git/,如“refs/heads/master”或“HEAD”,代表
“当前分支的名称”,然后给出跟踪信息。

排除诸如“git checkout master^0”(这是在提交之前在提交时分离 HEAD 的官方方法)和“git checkout origin/master^0<”之类的内容/code>”不再显示跟踪信息,但仍然显示“git checkout HEAD”当前分支的跟踪信息。
显式选项“--detach”的引入巧妙地打破了这一点。
新规则应该是


<块引用>

  • 如果给出了 --quiet,则不必理会跟踪信息。
  • 如果给出了 --detach,则不必理会跟踪信息。

否则,如果我们知道给出的分支名称是真正的本地分支名称
分支,或者如果我们得到“HEAD”并且“HEAD”没有分离,
然后尝试显示跟踪信息。

但它允许“git checkout --分离主机"(man) 也错误地显示了跟踪信息。
让我们收紧规则来解决这个问题。

I didn't realize this at the time, but that left me in a detached head state

That is why I mention the more recent (Git 2.23, Q3 2019) git switch command.

You cannot use git switch <commit> and not realize you end up in a detached HEAD state because such a command would actually fail, with the error message:

fatal: a branch is expected, got <commitID>
If you want to detach HEAD at the commit, try again with the `--detach` option

See more at "Why did my Git repo enter a detached HEAD state?".
The hint to use the --detach option comes from Git 2.36 (Q2 2022).


With Git 2.45 (Q2 2024), batch 18, git checkout/switch --detach foo(man), after switching to the detached HEAD state, gave the tracking information for the 'foo' branch, which was pointless.

See commit b9f2e1a (30 Mar 2024) by Junio C Hamano (gitster).
(Merged by Junio C Hamano -- gitster -- in commit 847af43, 12 Apr 2024)

checkout: omit "tracking" information on a detached HEAD

Reported-by: mirth hickford

By definition, a detached HEAD state is tentative and there is no configured "upstream" that it always wants to integrate with.
But if you detach from a branch that is behind its upstream, e.g.,

$ git checkout -t -b main origin/main
$ git checkout main
$ git reset --hard HEAD^
$ git checkout --detach main

you'd see "you are behind your upstream origin/main".
This does not happen when you replace the last step in the above with any of these

$ git checkout HEAD^0
$ git checkout --detach HEAD
$ git checkout --detach origin/main

Before 3266967 (checkout: introduce --detach synonym for "git checkout foo^{commit}", 2011-02-08, Git v1.7.5-rc0 -- merge) (checkout: introduce --detach synonym forgit checkout"(man)) introduced the "--detach" option, the rule to decide if we show the tracking information used to be:

If --quiet is not given, and if the given branch name is a real
local branch (i.e. the one we can compute the file path under
.git/, like 'refs/heads/master' or "HEAD" which stand for the
"name of the current branch", then give the tracking information.

to exclude things like "git checkout master^0" (which was the official way to detach HEAD at the commit before that commit) and "git checkout origin/master^0" from showing tracking information, but still do show the tracking information for the current branch for "git checkout HEAD".
The introduction of an explicit option "--detach" broke this subtley.
The new rule should have been

  • If --quiet is given, do not bother with tracking info.
  • If --detach is given, do not bother with tracking info.

Otherwise, if we know that the branch name given is a real local
branch, or if we were given "HEAD" and "HEAD" is not detached,
then attempt to show the tracking info.

but it allowed "git checkout --detach master"(man) to also show the tracking info by mistake.
Let's tighten the rule to fix this.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文