https://git-scm.com/docs/git-reset说：
git-reset - 将当前 HEAD 重置为指定状态
HEAD指向（最近的提交，即尖端）当前分支。可以将其更改为指向不同的分支，而无需修改任何分支git checkout。
在 的联机帮助页中git reset，在“将当前 HEAD 重置为指定状态”中的使用HEAD在我看来git reset切换到另一个分支作为当前分支，类似于git checkout.
git reset实际上改变了哪个提交是当前分支上的最新提交。如果是这样的话，那么git reset避免提及的联机帮助页是否会更清楚HEAD？例如，联机帮助页是否应该git reset说“将当前分支的尖端移动到同一分支上的上一个提交，缩短当前分支”而不是“将当前 HEAD 重置为指定状态”？哪个是正确的，我对手册页中措辞的字面理解，还是我听到的？
\n\n\n...“将当前分支的尖端移动到同一分支上的上一个提交，缩短当前分支”...
\n
这是git reset可以使用的方法之一。然而，它也可以延长当前分支，或者将其完全移动到其他地方，或者两者都不做。如果HEAD附加了（通常情况），则名称作为指针的效果更像是“转到”：
F <-- a\n /\n D--E <-- b (HEAD)\n /\n...--C--G--H <-- master\n \\\n I--J <-- develop\n由于HEAD附加到 name b，git reset某个任意提交（例如H或I）将移动 b，以便它指向该提交。如果您选择C或D，则可以将其视为“缩短当前分支”（在这种情况下，剩余的提交现在仅在分支上a）。然而，如果您选择F，使得b和a都指向F，则可以将其视为“延长当前分支”。如果您选择 commit J，那么b和develop都指向J，则很难将其称为缩短或延长。
该git reset命令非常复杂，因为\xe2\x80\x94像许多其他Git命令\xe2\x80\x94一样，它执行一些彼此不一定相关的操作。例如，充当 的逆操作，事实上，这两个操作（使用 -p 添加和重置）都是由用 Perl 编写的不同内部Git 命令实现的，而不是由名为和的 C 编码程序实现。1git reset -p filegit add -p filegit-resetgit-add
然而，存在三种“主模式”重置，所有这些重置都共享一组共同的操作。这些是您使用git reset --soft、git reset --mixed和获得的git reset --hard，它们都不允许路径名说明符，但所有这些都允许提交说明符：
git reset --soft a234567\ngit reset --mixed cafedad\ngit reset --hard HEAD~3\n例如。
\n\n这些的作用是：
\n\n将提交说明符解析为提交哈希 ID，a la git rev-parse。类似a234567或 的短散列cafedad会在散列 ID 数据库中查找并转换为完整的散列 ID。master类似或 的名称v2.3会在名称到哈希 ID 数据库中查找，然后在必要时转换为提交哈希。像这样的相对名称HEAD~3指示 Git 解析第一部分，然后应用关系运算符，因此HEAD~3首先查找 的哈希 ID HEAD，然后在提交图中倒数三个第一个父级。
此步骤可能会失败，因为哈希 ID 无效，或者因为它无法解析为提交（是树或 blob 的哈希 ID）。在这种情况下，git reset会停止并显示错误消息。
您可以省略提交说明符，在这种情况下，将从 的当前值读取提交说明符HEAD。也就是说，如果HEAD附加到某个分支名称 \xe2\x80\x94 如果您在master或 上develop，例如 \xe2\x80\x94Git 将从该分支名称中读取哈希 ID。如果HEAD是分离的，则它已经包含原始哈希ID，因此Git将从.hash中读取哈希ID HEAD。
现在git reset有了哈希 ID，它将将该哈希 ID 写入或通过HEAD。2 也就是说，如果HEAD附加到分支名称，Git 会将新的哈希 ID 存储到该分支名称中。如果HEAD分离，Git 会将新选择的哈希 ID 写入HEAD.
请注意，如果您在步骤 1 中指定HEAD，或者在步骤 1 中未指定任何内容，则会将从后面 HEAD读取的当前值写入到-or-through 中HEAD，这意味着不会发生任何更改。但是，如果您确实指定了其他提交，那么此时要么HEAD自身发生更改（分离头情况），要么HEAD更改目标（附加头情况）。
如果您使用过--soft，git reset现在已经完成。
否则，\xe2\x80\x94for--mixed或--hard\xe2\x80\x94git reset现在会重置索引，使其内容与 标识的提交匹配HEAD。
如果您使用过--mixed，git reset现在已经完成。
否则\xe2\x80\x94即，git reset --hard仅\xe2\x80\x94git reset现在重置工作树，使其内容与刚刚在步骤3中重置的索引匹配。
（步骤 3 和/或 4 也可能失败。如果步骤 3 失败，Git 可以将HEAD其恢复并索引到启动之前的状态git reset，因为 Git 通过创建新实体然后使用原子操作交换这两个实体来更新这两个实体。更新到底层文件系统。但是，如果步骤 4 失败，您可能会陷入混乱。）
1当您运行时git xyz，Git 将内部git-core目录推送到$PATH. （此处的描述稍微以 sh / bash 为中心，但即使在 Windows 上，算法也是相同的。）运行git --exec-path以查看此git-core目录在您的安装中的位置。查看该目录，您将找到名为git-add、git-commit、git-rebase、git-reset等的程序。因此，工作方式git xyz是 Git 设置一些上下文，在 的前面插入这个“核心”目录$PATH，然后调用git-xyz. 如果该文件存在于 中git-core，则该文件就是现在运行的文件。如果没有，则将运行您中任何位置的任何其他名为的文件。所以你可以编写自己的程序，将其构建为名为 的可执行文件，并使用 运行它，只要这个 git-core 目录中没有。git-xyz$PATHgit-xyzgit xyzgit-xyz
2这个名字HEAD在Git中很特别。它实际上是硬编码在各种源文件中的，早在 Git 的远古时代，它就被存储为符号链接。此方法在 Windows 上不起作用，因此在某些时候，该名称变得不那么特别了：现在任何引用都可以成为 Git 所说的符号引用。符号引用是通过阅读其他引用来解析的引用。该命令git symbolic-ref是读取和写入此类引用的外部接口。
虽然现在任何引用都可以成为象征性的，HEAD但对 Git 来说仍然很珍贵：如果文件丢失，Git 将声明存储库不再是存储库。由于这是存储库中最活跃的文件之一，因此如果您的系统在执行某些 Git 命令时崩溃，有时该文件会丢失。在这种情况下，您通常只需手动创建丢失的HEAD文件即可恢复所有内容。
| 归档时间： |
|
| 查看次数： |
889 次 |
| 最近记录： |