通常，git reset的功能是获取当前分支并将其重置为指向其他地方，并可能将索引和工作树一起带上。更具体地说，如果您的主分支（当前已签出）是这样的：

- A - B - C (HEAD, master)

并且您意识到您希望 master 指向 B，而不是 C，您将使用git reset B它来将其移动到那里：

- A - B (HEAD, master)      # - C is still here, but there's no branch pointing to it anymore

题外话：这与结帐不同。如果你运行git checkout B，你会得到这个：

- A - B (HEAD) - C (master)

您最终处于分离的 HEAD
状态。HEAD，工作树，索引都匹配B，但主分支被留在了C。如果此时你进行新的提交D，你会得到这个，这可能不是你想要的：

- A - B - C (master)
       \
        D (HEAD)

请记住，reset 不会进行提交，它只是更新一个分支（它是指向提交的指针）以指向不同的提交。其余的只是您的索引和工作树发生的事情的详细信息。

用例

git reset我在下一节对各种选项的描述中涵盖了许多主要用例。它真的可以用于各种各样的事情；共同点是所有这些都涉及重置分支、索引和/或工作树以指向/匹配给定的提交。

需要注意的事项

• --hard会导致你真的失去工作。它会修改您的工作树。

• git reset [options] commit可能会导致您（某种程度上）丢失提交。在上面的玩具示例中，我们丢失了 commit C。它仍在 repo 中，您可以通过查看git reflog show HEADor找到它git reflog show master，但实际上不再可以从任何分支访问它。

• Git 会在 30 天后永久删除此类提交，但在此之前，您可以通过再次将分支指向它来恢复 C ( git checkout C; git branch <new branch name>)。

论据

解释手册页，最常见的用法是表单git reset [<commit>] [paths...]，它将给定路径从给定提交重置为其状态。如果未提供路径，则重置整个树，如果未提供提交，则将其视为 HEAD（当前提交）。这是跨 git
命令的常见模式（例如 checkout、diff、log，尽管确切的语义有所不同），所以它不应该太令人惊讶。

例如，git reset other-branch path/to/foo将 path/to/foo 中的所有内容重置为其在 other-branch
中的状态，git reset -- .将当前目录重置为其在 HEAD 中的状态，以及简单git reset地将所有内容重置为其在 HEAD
中的状态。

主要工作树和索引选项

有四个主要选项可以控制在重置期间您的工作树和索引会发生什么。

git add请记住，索引是 git 的“暂存区”——当你说准备提交时，它就是事情的去向。

• --hard使所有内容都与您重置​​的提交相匹配。这可能是最容易理解的。您的所有本地更改都会被破坏。一个主要用途是消除您的工作但不切换提交：git reset --hard意味着git reset --hard HEAD，即不更改分支但摆脱所有本地更改。另一种是将分支从一个地方移动到另一个地方，并保持索引/工作树同步。 这是真正让你失去工作的一个，因为它会修改你的工作树。 在运行任何reset --hard.

• --mixed是默认值，即git reset表示git reset --mixed. 它会重置索引，但不会重置工作树。这意味着您的所有文件都是完整的，但是原始提交和您重置的文件之间的任何差异都将显示为带有 git 状态的本地修改（或未跟踪的文件）。当你意识到你做了一些错误的提交时使用这个，但你想保留你所做的所有工作，以便你可以修复它并重新提交。为了提交，您必须再次将文件添加到索引中 ( git add ...)。

• --soft不触及索引 或 工作树。您的所有文件都与 git status 一样完整--mixed，但所有更改都显示为changes to be committedgit status （即签入以准备提交）。当你意识到你做了一些错误的提交时使用它，但工作都很好——你需要做的就是以不同的方式重新提交它。索引未受影响，因此您可以根据需要立即提交 - 生成的提交将具有与重置之前相同的内容。

• --merge最近添加的，旨在帮助您中止失败的合并。这是必要的，因为git merge实际上将允许您尝试与脏工作树（具有本地修改的工作树）合并，只要这些修改位于不受合并影响的文件中。git reset --merge重置索引（就像--mixed- 所有更改都显示为本地修改），并重置受合并影响的文件，但不理会其他文件。这有望将所有内容恢复到错误合并之前的状态。您通常会将其用作git reset --merge（含义git reset --merge HEAD），因为您只想重置合并，而不是实际移动分支。（HEAD尚未更新，因为合并失败）

更具体地说，假设您修改了文件 A 和 B，并尝试在修改了文件 C 和 D 的分支中合并。由于某种原因合并失败，您决定中止它。你用git reset --merge. 它使 C 和 D 恢复到它们的状态HEAD，但将您的修改单独留在 A 和 B 中，因为它们不是尝试合并的一部分。

想知道更多？

我确实认为man git reset这确实非常好——也许你确实需要对 git
的工作方式有所了解，但他们才能真正融入其中。特别是，如果您花时间仔细阅读它们，那些详细说明所有各种选项和案例的索引和工作树中文件状态的表格非常有帮助。（但是，是的，它们非常密集——它们以非常简洁的形式传达了上述大量信息。）

奇怪的符号

您提到的“奇怪符号”（HEAD^和HEAD~1）只是指定提交的简写，而不必使用像3ebe3f6. 它在 git-rev-parse
手册页的“指定修订”部分中有完整的记录，其中包含大量示例和相关语法。插入符号和波浪号实际上意味着不同的东西：

• HEAD~是提交的第一个父级的缩写HEAD~1，表示提交的第一个父级。HEAD~2表示提交的第一个父级的第一个父级。可以认为HEAD~n是“HEAD 之前的 n 次提交”或“HEAD 的第 n 代祖先”。
• HEAD^（或HEAD^1）也表示提交的第一个父级。HEAD^2表示提交的 第二个 父级。请记住，正常的合并提交有两个父级 - 第一个父级是合并到的提交，第二个父级是合并的提交。一般来说，合并实际上可以有任意多个父级（章鱼合并）。
• 和运算符可以串在一起，如^,的第三代祖先的第二个父代,的第一个父代的第二个父代, 甚至, 相当于.~``HEAD~3^2``HEAD``HEAD^^2``HEAD``HEAD^^^``HEAD~3