如果“$file”有未限制的更改，“git checkout$hash$file”是否会出错？

我目前正在工作中领导从CVS到git的迁移，我希望尽可能避免同事无意中犯错误

如果运行

git-rebase

，并且有未提交的更改，则会出现以下错误：

error: cannot rebase: You have unstaged changes.
error: Please commit or stash them.

这非常好，因为它可以防止意外修改未提交的更改

---

运行

git checkout$commit$file

时，如果

$file

有未提交的修改，是否可能出现类似错误？理想情况下，我希望在

~/.gitconfig

中添加这样的标志以使其永久化。如果我真的想删除未提交的修改，我希望必须键入

--force

或类似的标志。

不幸的是，这里没有简单的方法可以获得您想要的内容。这种形式的

git checkout

和新颖的

git restore

命令都假定，当您要求git从

$hash

中找到的版本覆盖工作树中的

$file

时，即使

$file

已经存在于您的工作树中，并且与索引和/或

头中的副本不同，您也真的这么想

您可以做的是编写自己的Git命令。选择一个尚不存在的命令名。（我不知道该如何调用此命令，因此我将选择
xyzy
，这是其中两个神奇的单词之一。）用您喜欢的任何语言创建一个可执行程序；我通常在这里使用名为
git xyzy
的shell脚本，并将其放在
$PATH
中。然后，当您运行
git xyzy
时，git将运行您的命令

您的命令应：


获取一个
$hash
和一些
$file
参数集（您可以选择如何执行此操作）
检查给定的
$file
参数是否不存在于工作树中，或者是否已安全提交；及
根据需要运行
git restore
或
git checkout

这通常是一个相当短的脚本，主要使用哈希ID上的
git rev parse
和
git diff
或
git hash object
来检查文件是否安全提交。
我不这么认为，不。这是将更改还原到文件的主要方法之一，即使它有未提交的更改相信你的开发者。当然他们会犯这样的错误，但只会犯一两次。我不喜欢git checkout$commit$file

的原因是它有两个目的：还原本地更改（在这种情况下，您希望删除未提交的更改），以及从另一个分支导入更改（在这种情况下，您不希望无意中删除未提交的更改）。这就是为什么新版git将

git switch

（更改分支并创建新分支）和

git restore

（从暂存区移除内容并将文件恢复到以前的状态）中的功能人员分开的原因。是的，我意识到自从我在~2015年学习git以来，添加了新命令。我目前正在阅读github.com上的“git亮点”帖子，以了解更多我错过的内容。但我不认为“撤消所有更改”（当

$commit

==

HEAD

您希望覆盖更改时）和“从另一个分支复制该文件”（在这种情况下，您不希望意外覆盖未提交的更改）之间存在区别。您在这两种情况下都使用了

git restore

，不是吗？如果不是“从提交中复制该文件”，那么什么是“撤消所有更改”？（注意，我说过提交不是分支，因为分支只是指向提交的指针，头部也是如此）