为什么git不能通过路径进行硬/软复位？

Question

$ git reset -- <file_path> 可以通过路径重置.

但是,$ git reset (--hard|--soft) <file_path>会报告如下错误:

Cannot do hard|soft reset with paths.

Answer 1

因为没有意义(其他命令已经提供了该功能),并且它减少了意外做错事的可能性.

路径的"硬重置"刚刚完成git checkout HEAD -- <path>(检查文件的现有版本).

路径的软复位没有意义.

路径的混合重置是什么git reset -- <path>.

Answer 2

你可以完成你正在尝试使用的东西git checkout HEAD <path>.

也就是说,提供的错误消息对我来说没有任何意义(因为git reset在子目录上工作得很好),我认为没有理由不git reset --hard应该完全按照你的要求去做.

Answer 3

问题如何已经回答,我将解释为什么部分.

那么,git reset会做什么？根据指定的参数,它可以做两件事:

• 如果指定路径,它会将索引中的匹配文件替换为提交中的文件(默认情况下为HEAD).此操作根本不会影响工作树,通常用作git add的反义词.

• 如果未指定路径,则会将当前分支头移动到指定的提交,并且可以选择将索引和工作树重置为该提交的状态.此附加行为由mode参数控制: -
  soft:不要触摸索引和工作树.
  --mixed(默认值):重置索引但不重置工作树.
  --hard:重置索引和工作树.
  还有其他选项,请参阅完整列表的文档和一些用例.

  如果不指定提交,则默认为HEAD,因此git reset --soft不执行任何操作,因为它是将头移动到HEAD(到其当前状态)的命令.git reset --hard另一方面,由于其副作用而有意义,它表示将头部移至HEAD 并将索引和工作树重置为HEAD.

  我认为现在应该清楚为什么这个操作本身不适用于特定文件 - 它的目的是首先移动分支头,重置工作树,索引是辅助功能.

Answer 4

确保在原点或上游（源）和实际分支之间添加斜杠：

git reset --hard origin/branch

或者

git reset --hard upstream/branch`

Answer 5

这背后有一个非常重要的原因：和的原理checkoutreset。

在 Git 术语中，checkout 的意思是“进入当前工作树”。我们可以用来自任何git checkout区域的数据填充工作树，无论是来自存储库中的提交还是来自提交或暂存区域（甚至是默认情况）的单个文件。

反过来，git reset没有这个作用。顾名思义，它将重置当前引用，但始终将存储库作为源，与“范围”（--soft、--mixed 或--hard）无关。

回顾：

• 签出：从任何地方（索引/存储库提交）-> 工作树
• 重置：回购提交 - >覆盖HEAD（以及可选的索引和工作树）

因此，可能有点令人困惑的是 的存在git reset COMMIT -- files，因为仅使用某些文件“覆盖 HEAD”是没有意义的！

在没有官方解释的情况下，我只能推测 git 开发人员发现这reset仍然是放弃对暂存区域所做的更改的最佳命令名称，并且考虑到唯一的数据源是存储库，那么“让我们扩展功能”而不是创建新命令。

所以某种程度上git reset -- <files>已经有点特殊了：它不会覆盖 HEAD。恕我直言，所有这些变化都是例外。即使我们可以设想一个--hard版本，其他版本（例如--soft）也没有意义。