Git 在分离的 HEAD 状态下重置答案

【问题标题】：Git reset in detached HEAD stateGit 在分离的 HEAD 状态下重置
【发布时间】：2016-07-19 11:09:13
【问题描述】：

我了解git reset 命令在历史记录中向后移动了一个分支 (*)，并且它移动的分支是 HEAD 所指向的分支。

所以我很好奇，我尝试在detached HEAD state 中调用它，看看会发生什么。我期待错误，但 git 做了一些事情，我只是无法弄清楚它做了什么。

在我签出并进入 detached HEAD state 之前，Git 是否表现得像 HEAD 仍然指向它的位置？

[ 编辑 1 ] 我确实想通了。它的作用与一个人不处于分离头部状态时完全相同，只是它不会向后移动任何分支。这只是

[ Edit 2(*) ] git reset 实际上只在指定较旧的提交时在历史记录中向后移动一个分支。在执行git reset HEAD 时，它会将分支留在原来的位置（参见下面的 cmets）。

【问题讨论】：

你应该用你运行的确切命令来更新你的问题...... git reset 有三种形式......每种都有参数......最常见的用途是执行 git add 的相反操作。 ..
我不确定这是否重要。由于每个版本的 git reset 至少做一件事：它将当前分支移动到不同的位置。而且由于在分离的头脑中没有真正的当前分支，我想知道会发生什么

【解决方案1】：

强调一下：

我知道 git reset 命令总是在历史中向后移动一个分支，

这是不正确的，您可能需要编辑您的问题以避免混淆 git 新手。例如，git reset --hard 不这样做，它只是清除工作目录和索引而不移动 HEAD 或分支。

事实上，在git reset [<commit>] 中省略可选<commit> 的所有变体都不会移动头部或分支。 git reset 的其他选项做其他事情，并不是所有这些都移动 HEAD。所以移动 HEAD 只是git reset可以做的几个动作之一。

【讨论】：

从概念上讲，git reset 确实总是移动 HEAD，只是如果你从现在的位置移动到现在的位置，那移动是如此之小，如此之快:-) 没有人可以看到你移动，他们拒绝相信你移动了。 :-) 但是，它不必向后移动绝对是正确的：它可以移动到现在的位置（不动的“移动”），或者向前移动，或者向侧面移动（“跳跃轨道”到一个不相关的提交）。

【解决方案2】：

git reset 使当前分支和 HEAD 移动到特定提交。如果它是一个分离的 HEAD，它只会让 HEAD 移动。

【讨论】：

确实，我刚刚检查过，只有 HEAD 移动。但随后 git 告诉我我有未暂存的文件，这就是我想知道的。那些是什么文件？它们是我从头分离的顶部提交中的那些，还是我刚刚签出的那些（在我执行此提交时上演的那些）
@Radioreve git reset 有一些选项，例如 --soft、--mixed、--hard。 --mixed 是默认值。假设提交历史是A-B-C。如果git reset B 等于git reset B --mixed，则 HEAD 移动到 B，但从 B 到 C 的更改保持为未暂存状态。如果git reset B --soft，更改将保持为未提交。如果git reset B --hard，则丢弃更改。在git reset 之后，运行git status 进行检查。

【解决方案3】：

如果您只运行过：git reset

它执行与git add相反的操作，即unstage changes...

git reset 命令有三种形式，每一种都有相关的选项并执行不同的操作。如果您想更深入，请查看 git reset 文档。

【讨论】：