通常，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^2HEADHEAD^^2HEADHEAD^^^HEAD~3
请记住，git您有：
HEAD指针，它告诉您正在处理的提交请详细说明：
--hard,--soft和--merge;
按危险性递增的顺序：
--soft移动HEAD但不接触暂存区或工作树。--mixed移动HEAD和更新暂存区，但不移动和更新工作树。--mergemove ，重置暂存区域，并尝试将工作树中的所有更改移动HEAD到新的工作树中。--hard将您的暂存区和工作树移动HEAD 并调整为新的HEAD，扔掉所有东西。具体的用例和工作流程；
--soft当您想要移动到另一个提交并修补内容而不会“失去您的位置”时使用。你需要这个是非常罕见的。--
# git reset --soft example
touch foo // Add a file, make some changes.
git add foo //
git commit -m "bad commit message" // Commit... D'oh, that was a mistake!
git reset --soft HEAD^ // Go back one commit and fix things.
git commit -m "good commit" // There, now it's right.
--
--mixed当您想查看另一次提交时的情况，但又不想丢失已有的任何更改时，请使用（这是默认设置）。
--merge当您想移动到新位置但将您已有的更改合并到该工作树中时使用。
用于--hard清除所有内容并在新提交时重新开始。
博客Pro Git中的Reset Demystified帖子对和.git resetgit checkout
在该帖子顶部的所有有用讨论之后，作者将规则简化为以下简单的三个步骤：
基本上就是这样。该
reset命令以特定顺序覆盖这三个树，当您告诉它时停止。
- 移动 HEAD 指向的任何分支（如果 则停止
--soft）- 然后，使索引看起来像那样（除非是
--hard）- 然后，使工作目录看起来像这样
还有一些选项
--merge，--keep但我宁愿暂时让事情变得更简单——这将是另一篇文章。
当您向 git 提交某些内容时，您首先必须暂存（添加到索引）您的更改。这意味着在 git 将它们视为提交的一部分之前，您必须 git add 所有要包含在此提交中的文件。让我们先看一下 git repo 的图像：
所以，现在很简单。我们必须在工作目录中工作，创建文件、目录等等。这些更改是未跟踪的更改。为了使它们被跟踪，我们需要使用git add命令将它们添加到 git index 中。一旦它们被添加到 git 索引中。如果我们想将其推送到 git 存储库，我们现在可以提交这些更改。
但是突然我们在提交时才知道，我们在索引中添加的一个额外文件不需要推送到 git 存储库中。这意味着我们不希望该文件在索引中。现在的问题是如何从 git index 中删除该文件，因为我们使用git add将它们放入索引中，所以使用git rm是否合乎逻辑？错误的！git rm将简单地删除文件并将删除添加到索引中。那么现在该怎么办：
采用：-
git 重置
它清除您的索引，使您的工作目录保持不变。（简单地取消所有内容）。
它可以与许多选项一起使用。git reset可以使用三个主要选项：--hard、--soft 和--mixed。这些会影响重置时除了 HEAD 指针之外的重置内容。
首先，--hard重置所有内容。如果您一直关注该分支，您的当前目录将完全一样。工作目录和索引更改为该提交。这是我最常使用的版本。git reset --hard类似于svn revert。
接下来，完全相反的—soft不会重置工作树或索引。它只移动 HEAD 指针。这会使您的当前状态具有与您在目录中切换到的提交不同的任何更改，并“暂存”以进行提交。如果您在本地进行提交但尚未将提交推送到 git 服务器，您可以重置为之前的提交，并使用良好的提交消息重新提交。
最后，--mixed重置索引，但不重置工作树。因此，所有更改都仍然存在，但“未分级”并且需要 git add'ed 或git commit -a。如果我们使用 git commit -a 提交的内容超出预期，我们有时会使用它，我们可以使用 git reset --mixed 退出提交，添加我们想要提交的内容并提交这些内容。
git revert 和 git reset 之间的区别：-
简单来说，git reset是“修复未提交的错误”的命令，而git revert是“修复已提交的错误”的命令。
这意味着如果我们在某些更改中犯了一些错误并提交并将其推送到 git repo，那么git revert就是解决方案。如果我们在推送/提交之前发现了同样的错误，我们可以使用git reset来解决这个问题。
我希望它能帮助你摆脱你的困惑。
TL;博士
git reset将 Staging 重置为最后一次提交。用于--hard还将工作目录中的文件重置为最后一次提交。
更长的版本
但这显然很简单，因此有许多相当冗长的答案。git reset在撤消更改的背景下阅读对我来说更有意义。例如看到这个：
如果 git revert 是撤消更改的“安全”方法，您可以将 git reset 视为危险方法。当您使用 git reset 撤消（并且提交不再被任何 ref 或 reflog 引用）时，无法检索原始副本 - 这是永久撤消。使用此工具时必须小心，因为它是仅有的有可能丢失您的工作的 Git 命令之一。
来自https://www.atlassian.com/git/tutorials/undoing-changes/git-reset
还有这个
在提交级别，重置是一种将分支尖端移动到不同提交的方法。这可用于从当前分支中删除提交。
来自https://www.atlassian.com/git/tutorials/resetting-checking-out-and-reverting/commit-level-operations
请注意，这是一个简化的解释，旨在作为寻求理解这一复杂功能的第一步。
对于希望在以下每个命令之后可视化其项目状态的视觉学习者可能会有所帮助：
对于那些使用终端打开颜色的人（git config --global color.ui auto）：
git reset --soft A你会看到 B 和 C 的东西是绿色的（分阶段准备提交）
git reset --mixed A（或git reset A），您将看到 B 和 C 的东西以红色显示（未暂存并准备好暂存（绿色）然后提交）
git reset --hard A并且您将不再在任何地方看到 B 和 C 的更改（就好像它们从未存在过一样）
或者对于那些使用“Tower”或“SourceTree”等 GUI 程序的人
git reset --soft A你会在“暂存文件”区域看到 B 和 C 的东西准备提交
git reset --mixed A（或git reset A），您将在“未暂存文件”区域中看到 B 和 C 的内容，准备好移动到暂存文件然后提交
git reset --hard A并且您将不再在任何地方看到 B 和 C 的更改（就好像它们从未存在过一样）
Checkout 将头部指向特定的提交。
重置将分支指向特定提交。（分支是指向提交的指针。）
顺便说一句，如果你的头没有指向一个分支也指向的提交，那么你就有了一个分离的头。 （原来是错的。见评论......）