"git reset --hard"命令执行了什么操作？

Question

在本地 Git 分支上，我错过了按下 Tab 键再按回车键，结果执行了以下命令：

git reset --har

与预期的相比

git reset --hard

通常情况下，当运行一个看起来打错的命令时，git会抱怨。我查看了关于git reset的--help页面，没有找到"h"、"a"、"r"参数。

似乎它运行了硬重置，它实际上运行了什么？或者如果它运行了"--hard"，为什么会这样？

额外信息： sylvesterjakubowski$ git --version git版本1.7.12.4（Apple Git-37）＃在mountain lion上。

- sjakubowski

Answer 1

这是根据 gitcli 文档页面的描述：

许多命令允许将长选项“--option”缩写为其唯一前缀（例如，如果没有其他名称以“opt”开头的选项，则可以拼写“--opt”来调用“--option”标志），但在编写脚本时应完全拼写它们；Git的后续版本可能会引入一个新选项，其名称共享相同的前缀，例如“--optimize”，从而使曾经是唯一的短前缀不再唯一。

同样在同一页上：

支持增强选项解析器的命令接受长选项的唯一前缀，就好像它完全拼写出来一样，但使用时要小心。例如，git commit --amen 的行为就像你输入了 git commit --amend，但只有在Git的后续版本引入另一个共享相同前缀的选项，例如`git commit --amenity"选项时才是真正的。

所以，是的，它运行了git reset --hard。

- manojlds

Answer 2

它没有运行等同于“-h -a -r”的命令，因为有两个破折号而不是一个。Git可能在实现一种算法，允许您使用长标志名称的最短唯一匹配。由于没有以“--har”开头的git reset长标志，因此它可以将请求视为明确的，并继续运行git reset --hard。

- Mark Stosberg

Answer 3

根据您的使用情况，不要依赖解析选项API提供的缩写选项名称，以保护您免受在命令中曾经是唯一的选项的缩写形式变得不唯一的影响，因为添加了一个共享相同前缀的新选项。

查看提交 b02e7d5（2019年4月12日），以及提交 effc2ba，提交 c4932b0，提交 f6188dc，提交 ae0a11c，提交 7076e44，提交 f927ae6，提交 dd605e4（2019年3月25日）由Johannes Schindelin (dscho)。
^{（由Junio C Hamano -- gitster --于提交 39e4773合并，2019年4月22日）}

tests: 禁止使用缩写选项（默认情况下）

Git的命令行解析器支持唯一缩写选项，例如git init --ba会自动将--ba扩展为--bare。

对于Git用户来说，这是一项非常方便的功能，特别是在没有可用的制表符完成时。

然而，在Git的测试套件中依赖此功能并不是一个好主意，因为今天作为命令行选项的唯一缩写可能明天就不再是唯一缩写。

例如，如果未来的贡献添加了一个新模式git init --babyproofing，并且之前引入的测试用例使用了git init --ba扩展为git init --bare的事实，那么这个未来的贡献现在必须触及看似无关的测试，以使测试套件不会失败。

因此，让我们默认情况下禁止在测试套件中使用缩写选项。

测试（rebase）：拼写出--keep-empty选项

这个测试想要使用--keep-empty选项运行git rebase，但实际上只拼写了--keep并信任Git的选项解析来确定这是真正选项的唯一缩写。

然而，Denton Liu贡献了一个补丁系列，引入了一个新的git rebase选项，称为--keep-base，使得先前唯一的缩写变得不唯一。

无论这个补丁系列是否被接受，使用缩写选项在我们的测试套件中实际上是一个不好的做法，因为这些唯一的选项名称未来不能保证保持唯一。

所以在测试套件中不要使用缩写选项。

- VonC