后悔的三种类型

许多现有的答案似乎并不能回答实际的问题。它们是关于命令做什么，而不是关于你(用户)想要什么——用例。但那正是警察问的!

在给出git reset命令时，你会后悔什么，这样的描述可能更有帮助。假设我们有这个:

A - B - C - D <- HEAD

以下是一些可能会让你后悔的事情，以及应对方法:

1. 我很遗憾B, C, D不是一个人。

git重置——软A，我现在可以立即提交，从A开始的所有更改都是一次提交。

2. 我很遗憾B、C和D不是两次提交(或十次提交，或其他)。

提交已经消失，索引回到了A，但是工作区域看起来仍然和d之后一样。所以现在我可以在一个完全不同的分组中添加并提交。

3.我很遗憾B, C, D发生在这支树枝上;我希望我在A之后有一个分支它们发生在另一个分支上。

在另一个分支上创建一个新的分支，然后git重置——硬a。当前分支现在结束于a，其他分支起源于它，包含B、C和D。

(当然，你也可以使用硬重置，因为你希望B、C和D从未发生过。)

这里有许多关于git重置的误解的答案——软。虽然在特定的条件下git会重置——soft只会改变HEAD(从分离的HEAD状态开始)，通常(对于预期的用途)，它会移动您当前签出的分支引用。当然，如果你没有签出分支，它就不能这样做(因此git重置的特定条件-soft只会改变HEAD)。

我发现这是考虑git重置的最佳方式。你不只是移动HEAD(所有事情都是这样)，你也移动了分支引用，例如master。这类似于运行git commit(当前分支与HEAD一起移动)所发生的情况，只是您没有创建(并移动到)一个新的提交，而是移动到先前的提交。

这是重置的重点，将分支更改为新提交以外的内容，而不是更改HEAD。你可以在文档示例中看到:

撤销提交，使其成为主题分支 $ git分支主题/wip (1) $ git重置-硬头~3 (2) $ git结帐主题/wip (3) 您已经提交了一些文件，但是意识到它们还不适合放在“主”分支中。你想在topic分支中继续打磨它们，所以在当前HEAD的基础上创建“topic/wip”分支。 倒回主分支以摆脱这三个提交。 切换到“topic/wip”分支并继续工作。

这一系列命令的意义是什么?你想移动一个分支，master，当你签出master时，你运行git reset。

这里投票最多的答案一般都很好，但我想我应该加上这个来纠正几个有误解的答案。

改变你的分支

Git reset——soft <ref>:重置当前检出分支的分支指针到指定引用处的提交，<ref>。工作目录和索引中的文件不会被更改。从这个阶段提交将把你带回到git reset命令之前的状态。

改变你的索引

Git重置——mixed <ref>

或者同样的

Git重置<ref>:

做什么——soft做AND还重置索引以匹配指定引用的提交。虽然git reset——soft HEAD什么都不做(因为它说将检出的分支移动到检出的分支)，但git reset——mixed HEAD，或等价于git reset HEAD，是一个常见且有用的命令，因为它将索引重置为上次提交的状态。

也要更改工作目录

git reset——hard <ref>: does what——mixed does AND也覆盖你的工作目录。这个命令类似于git checkout <ref>，除了(这是关于重置的关键点)所有形式的git重置移动ref HEAD指向的分支。

关于“某某命令移动HEAD”的注释:

说命令移动HEAD是没有用的。任何改变您在提交历史中的位置的命令都会移动HEAD。这就是HEAD，一个指向你所在位置的指针。head就是你，所以无论你做什么，它都会移动。

当您在存储库中修改一个文件时，更改最初是暂不执行的。为了提交它，你必须使用git add来执行它——也就是说，将它添加到索引中。当你提交时，提交的更改是那些已经添加到索引中的更改。

git重置更改，至少，当前分支(HEAD)指向的位置。-混合和-软之间的区别在于索引是否也被修改。如果我们在master分支上进行这一系列的提交:

- A - B - C (master)

头指向C，索引匹配C。

当我们运行git reset -soft B, master(因此HEAD)现在指向B，但索引仍然有从C的变化;Git状态将显示它们为阶段性。如果我们在这里运行git commit，我们会得到一个新的commit，和C一样。

好的，再从这里开始:

- A - B - C (master)

现在让我们进行git重置-mixed b(注意:-mixed是默认选项)。同样，master和HEAD指向B，但这一次索引也被修改以匹配B。如果我们在这一点上运行git commit，什么也不会发生，因为索引匹配HEAD。我们在工作目录中仍然有更改，但由于它们不在索引中，git状态将它们显示为未暂存。要提交它们，你需要git添加，然后像往常一样提交。

And finally, --hard is the same as --mixed (it changes your HEAD and index), except that --hard also modifies your working directory. If we're at C and run git reset --hard B, then the changes added in C, as well as any uncommitted changes you have, will be removed, and the files in your working copy will match commit B. Since you can permanently lose changes this way, you should always run git status before doing a hard reset to make sure your working directory is clean or that you're okay with losing your uncommitted changes.

最后，一个可视化图:

用最简单的话来说:

——soft:取消提交更改，更改是阶段性的(index)。 ——mixed(默认):uncommit + unstage变更，变更留在工作树中。 ——难:uncommit + unstage + delete changes，什么都不剩。

以下是对TortoiseGit用户的基本解释:

Git复位-软-混合不动你的文件。

Git重置-实际上很难改变你的文件来匹配你重置的提交。

在TortoiseGit中，索引的概念被GUI隐藏得很好。当你修改一个文件时，你不必运行git add来将更改添加到暂存区域/索引中。当简单地处理现有文件的修改而不改变文件名时，git reset -soft和-mixed是一样的!只有添加新文件或重命名文件时才会注意到不同之处。在这种情况下，如果你运行git reset——mixed，你将不得不从Not Versioned Files列表中重新添加你的文件。

——soft:告诉Git将HEAD重置为另一个提交，这样索引和工作目录将不会以任何方式改变。在原始HEAD和提交之间更改的所有文件都将被暂存。

-mixed:就像软的，这将重置HEAD到另一个提交。它还将重置索引以匹配它，而工作目录将不会被触及。所有更改都将保留在工作目录中，并显示为已修改，但不是阶段性的。

——hard:这将重置所有内容——它将HEAD重置回另一个提交，重置索引以匹配它，并重置工作目录以匹配它。

-混合和-软之间的主要区别是你的索引是否也被修改。点击这里查看更多信息。