我了解在运行$ git checkout --detach时发生的内部操作。
当我在master分支上运行$ git checkout --detach时，我的.git/HEAD不会指向ref: refs/heads/master，而是指向一个哈希值（与refs/heads/master相同）。
在什么情况下，我会真正想要这样做呢？
为什么我会使用git checkout --detach命令？
11
- jkulak
3
4个回答
8
根据引入标志的提交：
例如，当进行临时合并以测试两个主题是否配合良好时，可以使用此标志。
我想这样做的想法是有意分离允许您进行进一步的提交，知道完成后将被丢弃（并在GC运行后）。
请注意，此标志实际上并未添加任何新功能；以前可以使用
例如，当进行临时合并以测试两个主题是否配合良好时，可以使用此标志。
我想这样做的想法是有意分离允许您进行进一步的提交，知道完成后将被丢弃（并在GC运行后）。
请注意，此标志实际上并未添加任何新功能；以前可以使用
git checkout some-branch^0实现相同的结果。- Oliver Charlesworth
2
2所以我在当前分支的末端分离，尝试将某些内容合并到该分离的HEAD上，以查看它有多容易，进行一些额外的提交-用于测试目的，然后运行构建/测试（无论是什么）以查看结果，如果一切看起来都没问题，就进行“真正”的合并...对吗？ - jkulak
1@jkulak - 是的，我想那个评论就是关于这个的。不过我自己从来没有需要这样做过 ;) - Oliver Charlesworth
6
tl;dr：检出已经在另一个工作树中检出的分支是不允许的。
输入git checkout --detach master
现在更清楚地解释一下如何出现这种情况，以下是我个人如何使用git checkout --detach的真实世界示例。
我正在开发一个名为 midimap 的程序，并且还有一个稳定的长期运行的后台进程。
为此，我利用了两个工作树：~/vc/github.com/fossegrim/midimap（以下简称 DEV）用于开发和 ~/vc/github.com/fossegrim/midimap-stable(以下简称 STABLE) 用于长期运行的进程。
当我启动计算机时，我在STABLE中运行midimap程序，并在DEV中打开GNU Emacs。随着我在DEV中进行项目工作，最终会到达一个我想要将USAGE工作树更新为DEV更改内容的点。
由于检出已经在另一个工作树中检出的分支是不允许的。因此，我必须以另一种方式检出它：git checkout --detach master。
- Olav Fosse
1
3Olav，你说你使用两个工作树，DEV和STABLE，但提到了第三个，USAGE。你能解释一下第三个的作用吗？
你能详细说明一下你上一段的内容吗？很抱歉，我完全不理解。 - MCornejo
2
当您选择检出提交哈希或使用 --detach 检出分支时，任何提交都不属于特定分支。
因此，这种情况被称为“分离的头部”，在测试某些内容时非常有用。
参考文献：
因此，这种情况被称为“分离的头部”，在测试某些内容时非常有用。
参考文献：
- aleksander_si
0
当你在多人开发环境中工作时，你可能会在代码审查过程中想要尝试某些代码更改，以便更好地理解其他开发人员所做的工作，从而提供更好的反馈。
你添加的任何提交都悬挂在空中，实际上没有添加到任何分支中。
然后，其他开发人员调整代码并推送新的提交。
之后，你只需执行一次fetch和checkout--detached原始分支即可，无需显式丢弃任何内容或解决合并冲突。
你实际上也没有在本地物理上获取分支，因此在完成代码审查后，你不需要删除分支（或你添加的提交）。
简而言之
命令git checkout origin/master --detach允许你检出分支指向的提交，而不必真正获取和跟踪分支本身。任何更改和提交你创建的都将自动被丢弃（包括“分支”本身），一旦你切换到另一个分支，你就不必手动删除它们。
- Qwerty
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
--detach标志，因为您只需将修订说明符拼写为例如refs/heads/master。因此，该标志本身仅供方便之用。但Oliver Charlesworth的回答是正确的——这只是关于请求方式拼写的旁注。 :-) - torek