【git使用场景】丢弃工作区文件的修改（上篇）-CSDN博客

本文链接：https://blog.csdn.net/CSDN_RTKLIB/article/details/148824807

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

前言

提示：这里可以添加本文要记录的大概内容：

使用场景：放弃所有还没添加到暂存区的修改，让工作区的文件恢复到和最近一次提交时一样的状态

提示：以下是本篇文章正文内容，下面案例可供参考

一、git checkout

在Git中，git checkout <file> 命令用于丢弃工作区中指定文件的修改，将其恢复到最近一次提交（HEAD）或暂存区（stage）的状态。以下是其详细功能和使用场景：
核心功能：恢复工作区文件
语法：

git checkout [--] <文件路径>   # [--] 是一个可选的分隔符，下面有详细说明

作用：

用暂存区的内容覆盖工作区：如果文件已被 git add 到暂存区，则恢复到暂存区的状态。
用HEAD的内容覆盖工作区：如果文件未被 git add，则恢复到最近一次提交（HEAD）的状态。

示例：

# 修改了 file.txt 后
git checkout file.txt  # 丢弃工作区的修改，恢复到暂存区或 HEAD 的状态

1.关键细节与注意事项

在Git中，git checkout <file>（或 git checkout -- <file>）的行为取决于文件是否已被添加到暂存区（stage/index）。这个命令的核心逻辑是：用指定来源的内容覆盖工作区的文件。以下是详细解释：

(1).Git的三个工作区域

理解这个命令前，需要先明确Git的三个核心概念：
工作区（Working Directory）：你在编辑器中实际修改的文件。
暂存区（Staging Area）：准备提交到仓库的文件快照（通过 git add 添加）。
本地仓库（Local Repository）：已提交到HEAD的历史版本。

工作区 → git add → 暂存区 → git commit → 本地仓库

(2).`git checkout <file>` 的两种行为

a. 文件已被 git add 到暂存区

结果：工作区的文件会被恢复到暂存区的状态（即最后一次 git add 时的内容）。

示例：

# 初始状态：文件内容为 "version 1"，已提交到HEAD
echo "version 2" > file.txt  # 修改文件（工作区变化）
git add file.txt             # 添加到暂存区（暂存区更新为"version 2"）
echo "version 3" > file.txt  # 再次修改文件（工作区变化，但暂存区不变）
git checkout file.txt        # 恢复到暂存区的"version 2"

b. 文件未被 git add（仅工作区修改）

结果：工作区的文件会被恢复到HEAD的状态（即最近一次提交时的内容）。

示例：

# 初始状态：文件内容为 "version 1"，已提交到HEAD
echo "version 2" > file.txt  # 修改文件（工作区变化）
# 未执行git add
git checkout file.txt        # 恢复到HEAD的"version 1"

(3).用图例说明流程

a.场景1：恢复到暂存区

初始状态：
HEAD (version 1)    暂存区 (version 1)    工作区 (version 1)

1. 修改文件：
HEAD (version 1)    暂存区 (version 1)    工作区 (version 2)

2. git add：
HEAD (version 1)    暂存区 (version 2)    工作区 (version 2)

3. 再次修改：
HEAD (version 1)    暂存区 (version 2)    工作区 (version 3)

4. git checkout file.txt：
HEAD (version 1)    暂存区 (version 2)    工作区 (version 2) ← 恢复到暂存区

b.场景2：恢复到HEAD

初始状态：
HEAD (version 1)    暂存区 (version 1)    工作区 (version 1)

1. 修改文件：
HEAD (version 1)    暂存区 (version 1)    工作区 (version 2)

2. git checkout file.txt：
HEAD (version 1)    暂存区 (version 1)    工作区 (version 1) ← 恢复到HEAD

(4)关键细节

a.暂存区的“隔离”作用

git add 会将文件快照保存到暂存区，git checkout 可以基于暂存区恢复，而不依赖HEAD。
这允许你部分恢复修改：例如，先 git add 部分修改，再恢复其他修改。

b.不可逆操作

git checkout <file> 会永久丢弃工作区的修改，无法通过 git reset 或 git restore 找回。
若需保留修改，建议先使用 git stash 暂存。

(5)常见场景

a.撤销误修改

# 修改了config.js但想撤销
git checkout -- config.js  # 恢复到HEAD或暂存区的状态

b.部分提交工作流

# 修改了file1.js和file2.js
git add file1.js           # 只添加file1.js到暂存区
git checkout file2.js      # 恢复file2.js（保留file1.js的暂存）
git commit -m "提交file1.js"

c.从历史版本恢复文件

git checkout HEAD~1 -- file.txt  # 恢复到上一次提交的状态（无论暂存区状态）

git checkout <file> 的行为取决于文件是否已暂存：

已暂存（git add 过）→ 恢复到暂存区的版本。
未暂存 → 恢复到HEAD（最近一次提交）的版本。

这个命令是Git中最危险的操作之一，因为它会直接丢弃工作区的修改。使用前务必确认是否需要保留修改，或使用 git stash 暂存。

2.常见场景

(1). 丢弃未暂存的修改

# 修改了 file.txt 但未暂存
git checkout file.txt  # 恢复到 HEAD 的状态

(2). 恢复暂存区的文件

git add file.txt       # 添加到暂存区
echo "oops" > file.txt  # 意外修改
git checkout file.txt  # 恢复到暂存区的状态

(3). 恢复多个文件或目录

git checkout *.js      # 恢复所有 .js 文件
git checkout src/      # 恢复 src 目录下的所有文件
git checkout .         # 恢复所有文件

(4). 从特定提交恢复文件

git checkout HEAD~1 -- file.txt  # 恢复到上一次提交（HEAD~1）的状态
git checkout <commit-hash> -- file.txt  # 恢复到指定提交的状态

3.避免歧义的写法

在Git命令中，[--] 是一个可选的分隔符，用于明确区分分支名和文件路径。它的作用是告诉Git：“接下来的参数是文件路径，而不是分支名或标签名”。

(1)为什么需要 `--`？

Git 允许分支名、标签名和文件名使用相同的命名。例如：

你可能有一个名为 readme.md 的文件
同时创建了一个名为 readme.md 的分支

此时，如果直接执行：

git checkout readme.md

Git 会困惑：你是想切换到分支 readme.md，还是恢复文件 readme.md？

(2)`--` 的作用：消除歧义

使用 -- 明确指定后续参数为文件路径：

git checkout -- readme.md  # 强制Git将readme.md解释为文件，而非分支

示例场景：

存在同名分支和文件：

git branch readme.md     # 创建名为readme.md的分支
echo "修改内容" > readme.md  # 修改文件
git checkout -- readme.md  # 恢复文件，而非切换分支

分支名包含路径分隔符：

git branch feature/docs/readme  # 创建带路径的分支
git checkout -- docs/readme.md  # 恢复文件，而非切换分支

(3)何时需要使用 `--`？

存在同名分支或标签时：必须使用 -- 避免歧义。

文件路径包含特殊字符时（如 - 开头）：

git checkout -- -filename.txt  # 正确恢复以-开头的文件

为了代码可读性：即使不存在歧义，也建议添加 -- 明确意图。

(4)不使用 `--` 的情况

当确定没有同名分支或标签，且文件路径不包含特殊字符时，可以省略 --：

git checkout src/app.js  # 安全：src/app.js 不是分支名

(5)Git 版本兼容性建议

在早期Git版本（如 1.6.x）中，-- 是必需的。现代Git（如 2.0+）会智能判断：

若参数与现有分支名匹配，则优先切换分支。
若参数与文件路径匹配，但不存在同名分支，则恢复文件。

但为了避免混淆，建议始终使用 -- 明确指定文件路径。

git checkout [--] <文件路径> 中的 [--] 是一个可选但强烈推荐的分隔符，用于：

明确指定参数为文件路径，而非分支名。
避免因命名冲突导致的意外分支切换。
提高命令的可读性和安全性。

最佳实践：无论是否存在歧义，恢复文件时始终使用 git checkout -- <文件> 的形式。

二、git restore

git restore 是 Git 2.23 版本引入的新命令，主要用于恢复工作区文件或重置暂存区，它将之前 git checkout 的部分功能分离出来，使命令的职责更加清晰。下面详细介绍其功能和用法：

1. 恢复工作区文件（丢弃修改）

用于撤销对工作区文件的修改，将文件恢复到最后一次提交或暂存时的状态。

git restore <文件路径>

示例：
若修改了 src/main.py，但想丢弃这些修改：
```
git restore src/main.py
```
注意：
此操作不可逆，修改会被永久删除，需谨慎使用。

2. 从暂存区恢复文件到工作区

将暂存区的文件内容恢复到工作区，覆盖当前工作区的修改。

git restore --source=HEAD <文件路径>

简化写法：
--source=HEAD 可简写为 -s HEAD 或直接省略（默认从 HEAD 恢复）：

git restore -s HEAD <文件路径>
# 或
git restore <文件路径>  # 默认从 HEAD 恢复

示例：
若想将 README.md 恢复到 HEAD 版本：
```
git restore README.md
```

3. 重置暂存区（取消 `git add`）

将文件从暂存区移除，但保留工作区的修改（相当于撤销 git add）。

git restore --staged <文件路径>

示例：
若误将 config.ini 添加到暂存区，可取消暂存：
```
git restore --staged config.ini
```

4. 同时重置暂存区和工作区

彻底丢弃文件的所有修改，将暂存区和工作区都恢复到 HEAD 版本。

git restore --source=HEAD --worktree --staged <文件路径>

简化参数：
--worktree 和 --staged 可合并为 -W 和 -S，或直接使用 -SW：

git restore -s HEAD -SW <文件路径>
# 或针对所有文件
git restore -s HEAD -SW .

5. 恢复多个文件或目录

支持使用通配符或目录路径批量恢复文件。

# 恢复所有 .txt 文件
git restore '*.txt'

# 恢复 src/ 目录下的所有文件
git restore src/

6. 与 `git checkout` 的对比

git checkout：
既是“切换分支”的命令，也可用于恢复文件，功能较混乱。

git restore：
专门用于恢复文件，职责单一，避免混淆。

示例对比：

旧方式（使用 checkout）：

git checkout -- <文件路径>  # 恢复工作区
git checkout HEAD -- <文件路径>  # 恢复暂存区和工作区

新方式（使用 restore）：

git restore <文件路径>  # 恢复工作区
git restore -SW <文件路径>  # 恢复暂存区和工作区

7.常用参数总结

参数	作用
`--source` 或 `-s`	指定恢复的源（如 `HEAD`、分支名、提交哈希）
`--staged` 或 `-S`	只重置暂存区（取消 `git add`）
`--worktree` 或 `-W`	只恢复工作区（丢弃修改）
`-SW`	同时重置暂存区和工作区
`--pathspec-from-file`	从文件读取要恢复的文件路径列表