Git 基础操作速查手册 场景模拟

Q741_1472026-02-01 8:10

文章目录

刚接触Git，记不住命令和对应场景太正常了！这篇博客整理了Git核心基础操作，包含命令速查、详细用法、常见场景举例，纯干货无废话，适合随时翻出来复习。

一、Git 基础命令速查表

1. 基础目录与状态查看

命令 作用
ls -a 查看所有文件（含隐藏的 .git 目录，确认仓库初始化成功）
ls -a .git 查看 .git 目录内部结构
git status 查看当前工作区、暂存区文件状态 核心命令，必用
git log 查看版本提交记录（含版本号、提交时间、提交说明）
git reflog 查看所有Git操作记录（版本回退后找回版本号专用）

2. 文件添加到暂存区

命令 作用
git add 文件名 添加单个/指定多个文件到暂存区
git add . 批量添加当前目录所有新增、修改文件到暂存区

3. 文件修改与提交存入版本库

命令 作用
git add 文件名/git add . 修改文件后，重新添加到暂存区
git commit -m "提交说明" 将暂存区文件提交到版本库，生成新记录

4. 版本回退

命令 工作区（是否作用） 暂存区（是否作用） 版本库（是否作用） 核心作用描述
git reset --soft 版本号 否 否 是 回退到指定版本，保留暂存区、工作区所有修改，仅更新版本库
git reset --mixed 版本号（默认） 否 是 是 回退到指定版本，清空暂存区（同步到目标版本），保留工作区修改
git reset --hard 版本号 是 是 是 回退到指定版本，清空暂存区和工作区（同步到目标版本），彻底丢弃所有后续修改

补充说明:

1.「是否作用」的判断标准：是否会改变该区域的当前状态 （即是否会用目标版本的内容替换该区域的现有内容）。

标注「否」：该区域保持当前状态不变，所有修改都被完整保留，不会被目标版本覆盖。

标注「是」：该区域的状态会被修改，会同步到目标版本的状态，当前区域的现有修改会被处理（--mixed 暂存区修改回退到工作区，--hard 直接永久丢弃）。
2.快速记忆：从 soft 到 hard，标注「是」的区域越来越多，操作风险也逐步升高。

5. 撤销修改

命令 工作区（是否作用） 暂存区（是否作用） 版本库（是否作用） 核心作用描述
git checkout -- 文件名 / git restore 文件名 是 否 否 撤销工作区修改（未git add），恢复原始状态，不影响暂存区和版本库
git reset HEAD 文件名 / git restore --staged 文件名 否 是 否 撤销暂存区修改，将修改回退到工作区（已git add未commit），不影响工作区原有内容和版本库
git reset --soft HEAD^ 否 否 是 撤销最近一次提交，保留暂存区、工作区所有修改（已commit），仅调整版本库记录

6. 文件删除与恢复

命令 作用
rm 文件名 删除工作区文件（仅本地，未同步Git）
git rm 文件名 一步删除工作区文件+同步删除操作到暂存区
git checkout -- 文件名 / git restore 文件名 恢复误删文件（未提交删除操作）
git commit -m "删除说明" 提交删除操作到版本库，永久删除文件

二、 命令详细解释

前置知识：理解 .git 目录（核心铺垫）

在开始具体操作前，先明确一个核心目录------.git，这是Git的灵魂所在，所有版本记录、仓库配置都存储在这里。

1. 命令

bash 复制代码 
# 查看所有文件（含隐藏的 .git 目录，确认仓库初始化成功）
ls -a
# 查看 .git 目录内部结构，了解Git的核心存储
ls -a .git

2. 用法讲解

  1. 执行 git init 初始化仓库后，会自动在当前目录生成隐藏目录 .git（Windows需开启「显示隐藏文件」，macOS/Linux终端默认可见）。
  2. .git 目录包含：版本记录（objects 文件夹）、分支信息（refs 文件夹）、暂存区数据（index 文件）、仓库配置（config 文件）等，绝对不要手动修改或删除 .git 目录，否则仓库会损坏，所有版本记录丢失。
  3. 普通 ls 命令无法显示隐藏文件，必须使用 ls -a（a 代表 all，所有文件）。
  4. 若想验证仓库是否初始化成功，ls -a 能看到 .git 目录即说明创建成功。

常见场景举例

场景：当我们刚执行 git init 初始化桌面的 test-git 仓库，想确认 .git 目录是否生成，仓库是否可用的时候。

操作步骤：

bash 复制代码 
# 1. 进入仓库目录（示例：桌面的 test-git 文件夹）
cd ~/Desktop/test-git
# 2. 查看所有文件（含隐藏文件）
ls -a

执行结果：终端输出中出现 .git 字样，说明仓库初始化成功，核心目录已生成；后续执行 ls -a .git 可查看 .git 内部的核心文件/文件夹。

1、基础目录与状态查看 git status、git log、git reflog命令

bash 复制代码 
# 核心：查看当前工作区、暂存区文件状态（必用）
git status
# 查看版本提交记录（含版本号、提交人、提交时间、提交说明）
git log
# 查看所有Git操作记录（版本回退后找回版本号专用）
git reflog

用法讲解

git status

  1. 作用：实时反馈「工作区」和「暂存区」的文件状态，告诉我们下一步该执行什么命令（git add 或 git commit）。
  2. 常见输出状态：
    • 「Untracked files」：未被Git跟踪的新文件（从未执行过 git add）。
    • 「Changes to be committed」：文件已进入暂存区，等待执行 git commit 提交到版本库。
    • 「Changes not staged for commit」：文件已修改，但未执行 git add 加入暂存区。
    • 「nothing to commit, working tree clean」：工作区、暂存区和版本库保持一致，无未提交修改，仓库处于干净状态。
  3. 建议：执行任何Git操作（如 add、reset、rm）前后，都先执行 git status，避免误操作。

git log（查看已提交的版本记录）

  1. 作用：查看所有已提交到「版本库」的历史记录，只显示「成功提交」的版本，不显示未提交的操作。
  2. 关键信息提取：
    • 「commit 后面的一串哈希值」：唯一版本号（如 a1b2c3d4e5f6...），版本回退时需用到（取前6-8位即可）。
    • 「Author」：提交人信息（对应Git配置的 user.name 和 user.email）。
    • 「Date」：提交时间。
    • 「下方的文字」：提交时填写的 git commit -m "xxx" 说明。
  3. 便捷操作：输入 q 可退出 git log 查看界面。

git reflog（版本回退的「救命稻草」）

  1. 作用：记录所有Git操作轨迹 （包括 commit、reset、add、rm 等），无论是否提交，都能记录，且不会丢失（除非删除仓库）。
  2. 核心场景：当我们执行 git reset --hard 回退版本后，git log 无法看到被回退的新版本，此时用 git reflog 可找到所有操作记录，提取新版本号，重新回退到最新版本。
  3. 区别于 git log：git log 只看「提交记录」，git reflog 看「所有操作记录」，记住：找不到版本号就用 git reflog。

常见场景举例

场景1：日常开发中，查看我们当前文件是否有未提交修改

当我们编辑完 README.md 后，想确认文件是否已加入暂存区，是否可以提交版本。

操作步骤：

bash 复制代码 
# 1. 进入仓库目录
cd ~/Desktop/test-git
# 2. 查看文件状态
git status

执行结果：若提示「Changes not staged for commit」，说明文件已修改但未 git add；若提示「Changes to be committed」，说明已加入暂存区，可执行 git commit。

场景2：提交版本后，查看历史提交记录，确认提交是否成功

当我们执行 git commit -m "更新项目描述" 后，想查看版本记录，确认提交信息是否正确，是否生成新的版本号。

操作步骤：

bash 复制代码 
# 1. 进入仓库目录
cd ~/Desktop/test-git
# 2. 查看版本提交记录
git log

执行结果：终端显示最新的提交记录，提交说明为「更新项目描述」，说明提交成功；输入 q 退出查看界面。

场景3：版本回退后，找回之前的新版本号

当我们执行 git reset --hard a1b2c3d 回退后，发现回退错了，想恢复到之前的新版本，用 git log 看不到新版本记录。

操作步骤：

bash 复制代码 
# 1. 进入仓库目录
cd ~/Desktop/test-git
# 2. 查看所有Git操作记录，提取新版本号
git reflog

执行结果：终端显示所有操作记录，找到回退前的新版本号（如 d7e8f90），后续可执行 git reset --hard d7e8f90 恢复到该版本。

2、文件添加到暂存区 git add 文件名、git add .

bash 复制代码 
# 单个/指定多个文件添加到暂存区
git add 文件名1 文件名2
# 批量添加当前目录所有新增、修改文件到暂存区
git add .

用法讲解

  1. 核心作用：将「工作区」的文件移动/同步到「暂存区」（暂存区是临时待提交区域，相当于「版本提交的缓冲区」）。
  2. Git文件状态流转的第一步：工作区 → 暂存区，只有进入暂存区的文件，才能通过 git commit 提交到版本库。
  3. git add 文件名：
    • 可指定单个文件（如 git add README.md），也可指定多个文件（如 git add index.html style.css），用空格分隔。
    • 需确保文件名正确（含后缀），且终端当前目录和文件所在目录一致，否则需填写相对路径（如 git add src/utils.js）。
    • 适合「仅需提交部分修改文件」的场景（如只完成了一个功能，其他文件还在调试）。
  4. git add .：
    • 这里的 . 代表「当前目录及其所有子目录」，批量处理效率更高。
    • 会自动添加所有新增文件 （Untracked）和修改文件 （Modified），但不会添加被删除的文件 （删除文件需用 git rm 同步）。
    • 适合「所有修改都已调试完成，想一次性提交」的场景。
  5. 执行后验证：可执行 git status，看到文件提示「Changes to be committed」即说明添加成功。

常见场景举例

场景1：添加单个文件到暂存区

当我们编辑了 README.md（完善项目安装步骤），其他文件未修改，想只提交这个文件到暂存区。

操作步骤：

bash 复制代码 
# 1. 进入仓库目录
cd ~/Desktop/test-git
# 2. 添加单个文件 README.md 到暂存区
git add README.md
# 3. 验证添加结果
git status

执行结果：git status 提示 README.md 处于「Changes to be committed」状态，说明添加成功，等待提交到版本库。

场景2：批量添加所有修改文件到暂存区

当我们不仅新增了 style.css，还修改了 index.html 和 README.md，所有文件都调试完毕，想一次性添加到暂存区。

操作步骤：

bash 复制代码 
# 1. 进入仓库目录
cd ~/Desktop/test-git
# 2. 批量添加所有修改文件到暂存区
git add .
# 3. 验证添加结果
git status

执行结果：git status 提示所有新增/修改的文件都处于「Changes to be committed」状态，说明批量添加成功。

3、文件修改与提交存入版本库 git add（重新添加）、git commit -m "提交说明"

bash 复制代码 
# 步骤1：修改文件后，重新添加到暂存区（单个/批量二选一）
git add 文件名
git add .

# 步骤2：将暂存区文件提交到版本库，生成新记录
git commit -m "清晰简洁的提交说明"

# 可选：查看提交记录，确认提交成功
git log

用法讲解

  1. 核心逻辑：修改后的文件，必须重新执行 git add 才能进入暂存区 （之前的 git add 记录会失效，Git只跟踪最新的文件状态）。
  2. git commit -m "提交说明"：
    • 核心作用：将「暂存区」的所有文件永久存入「版本库」 ，生成一条唯一的版本记录，后续可通过 git log 查看。
    • -m 选项：指定「提交说明」，必须填写，否则Git会打开默认编辑器要求输入，新手容易卡住。
    • 提交说明规范：清晰、简洁，描述本次修改的核心内容（如「修复index.html布局bug」、「新增登录页面样式」、「更新README安装步骤」），方便后续回溯版本时快速理解。
    • 若未执行 git add 直接执行 git commit，会提示「nothing to commit」，提交失败（无暂存区文件可提交）。
  3. 完整流程：修改文件 → git add（加入暂存区）→ git commit（存入版本库），这是Git日常开发的核心流程。

常见场景举例

我们之前已提交过 README.md 到版本库，现在修改了其中的某些部分，想将这个修改提交到版本库，生成新记录。

操作步骤：

bash 复制代码 
# 1. 进入仓库目录
cd ~/Desktop/test-git
# 2. 将修改后的 README.md 重新添加到暂存区
git add README.md
# 3. 提交到版本库，填写清晰的提交说明
git commit -m "更新README.md：补充项目运行步骤"
# 4. 验证提交结果，查看最新版本记录
git log

执行结果：git log 显示最新的提交记录，提交说明为「更新README.md：补充项目运行步骤」，说明修改已成功存入版本库。

4、版本回退 git reset --soft 版本号、git reset --mixed 版本号、git reset --hard 版本号

bash 复制代码 
# 步骤1：查看版本记录，获取目标版本号（前6-8位即可）
git log

# 步骤2：三种版本回退模式（选其一）
# 模式1：温和回退，保留暂存区、工作区所有修改
git reset --soft 版本号
# 模式2：默认回退，清空暂存区，保留工作区修改（可省略 --mixed）
git reset --mixed 版本号
git reset 版本号 （等价于 --mixed）
# 模式3：激进回退，清空暂存区、工作区，彻底丢弃后续修改（谨慎使用）
git reset --hard 版本号

# 步骤3：回退后若想恢复，查看所有操作记录，找回新版本号
git reflog

用法讲解

  1. 核心作用：将「版本库」回退到指定历史版本，同时根据不同模式，处理「暂存区」和「工作区」的修改，适合「提交了错误版本（如敏感信息、严重bug），需要回到之前正常版本」的场景。
  2. 版本号获取：git log 中「commit」后的哈希值，取前6-8位即可（如 a1b2c3d），Git会自动识别唯一版本。
  3. 三种模式核心区别（新手重点掌握「mixed」和「hard」）：
    • --soft（最温和，低风险）：
      • 仅修改「版本库」，「暂存区」和「工作区」的所有修改都保留不变。
      • 适合场景：「提交错了，想重新整理暂存区，再提交一个更规范的版本」（如提交说明写错、漏加文件）。
      • 执行后：git status 会看到文件仍处于「Changes to be committed」状态，可直接重新 git commit。
    • --mixed（默认模式，中等风险）：
      • 修改「版本库」和「暂存区」（清空暂存区，同步到目标版本），「工作区」的修改保留。
      • 适合场景：「回退版本，且想重新编辑工作区文件，再提交」（如代码有bug，需要修改后重新提交）。
      • 执行后：git status 会看到文件处于「Changes not staged for commit」状态，需要重新 git add 才能提交。
    • --hard（最激进，高风险）：
      • 修改「版本库」、「暂存区」、「工作区」，三者全部同步到目标版本，后续的所有修改都会永久丢弃 （无备份，除非用 git reflog 找回版本号）。
      • 适合场景：「确认后续修改全是错误，想彻底回到干净的目标版本」（如提交了敏感信息，必须彻底删除）。
      • 警告：非必要不要使用，执行前务必确认修改无保留价值。
  4. 记忆技巧：从 soft 到 hard，影响的区域越来越多，操作风险越来越高。

常见场景举例

场景1：--index 默认模式回退，保留工作区修改

当我们提交了一个版本（提交说明：「添加支付功能」），但发现支付功能有严重bug，想回退到上一个正常版本，保留当前工作区的修改，后续修复bug后重新提交。

操作步骤：

bash 复制代码 
# 1. 进入仓库目录
cd ~/Desktop/test-git
# 2. 查看版本记录，获取上一个正常版本的版本号（如 a1b2c3d）
git log
# 3. 执行默认模式回退（--mixed 可省略）
git reset a1b2c3d
# 4. 验证结果，确认工作区修改已保留
git status

执行结果：我们工作区的代码（包括BUG）没有改变，只是版本库和暂存区回退到了上一个正常版本，git status 提示文件处于未暂存状态，可修复bug后重新 git add . 和 git commit。

场景2：--hard 模式回退，彻底丢弃错误修改

我们提交了一个错误版本，里面包含了敏感的用户密码，想彻底丢弃这个版本，回到之前的干净版本，不再保留任何相关修改。

操作步骤：

bash 复制代码 
# 1. 进入仓库目录
cd ~/Desktop/test-git
# 2. 查看版本记录，获取目标干净版本的版本号（如 a1b2c3d）
git log
# 3. 执行 --hard 模式回退（谨慎！）
git reset --hard a1b2c3d
# 4. 验证结果，确认工作区、暂存区都已同步到目标版本
ls
git status

执行结果：彻底回到干净版本，错误版本的所有修改（包括敏感信息）都被永久丢弃，git status 提示「working tree clean」，工作区文件恢复为目标版本的状态。

场景 3：--soft 模式回退，保留暂存区 + 工作区修改，快速重新提交

我们提交了一个版本（提交说明：「添加支付功能」），提交后立刻发现提交说明写错了（比如写成了「添加支付功」，漏了一个字），或者发现少提交了一个配套的配置文件，想撤销这次提交，直接整理后重新提交，不想改动已暂存的代码。

核心场景：仅对「提交记录本身」不满意，代码和暂存状态都没问题，需要快速修正后重新提交（无需要重新 git add）。

操作步骤：

bash 复制代码 
# 1. 进入仓库目录
cd ~/Desktop/test-git
# 2. 查看版本记录，获取上一个正常版本的版本号（如 a1b2c3d，也可直接用 HEAD^ 代表上一个版本）
git log
# 3. 执行 --soft 模式回退（两种写法二选一，效果一致）
git reset --soft a1b2c3d
# 或 更便捷：直接回退到上一个版本（无需手动复制版本号）
git reset --soft HEAD^
# 4. 验证结果，确认暂存区、工作区修改都已保留
git status

执行结果：版本库回退到上一个正常版本 a1b2c3d，错误的提交记录被撤销；暂存区和工作区的支付功能代码完全保留，git status 提示文件处于「Changes to be committed」状态（已暂存待提交），无需重新执行 git add .，直接修改提交说明（或补充添加遗漏文件）后，执行 git commit -m "添加支付功能（修正提交说明）" 即可生成新的正确版本记录。

5、撤销修改 git checkout -- 文件名/git restore 文件名、git reset HEAD 文件名/git restore --staged 文件名、git reset --soft HEAD^

bash 复制代码 
# 情况1：仅工作区修改，未 git add（丢弃工作区修改）
git checkout -- 文件名
git restore 文件名 （Git 2.23+ 推荐）

# 情况2：已 git add 进入暂存区，未 git commit（先回退到工作区，再丢弃）
git reset HEAD 文件名
git restore --staged 文件名 （Git 2.23+ 推荐）
git checkout -- 文件名 / git restore 文件名

# 情况3：已 git commit，立即发现错误（撤销提交，保留修改）
git reset --soft HEAD^

用法讲解

撤销修改 vs 版本回退：撤销修改针对「未提交到版本库」的错误（仅在工作区/暂存区），版本回退针对「已提交到版本库」的错误，两者场景不同，不要混淆。

情况1：仅工作区修改，未执行 git add

  1. 场景：文件修改后，还没加入暂存区，发现修改错误，想恢复到修改前的状态。
  2. 命令作用：用「暂存区/版本库」中的文件覆盖「工作区」的修改，丢弃的修改无法恢复（未进入任何持久化区域）。
  3. 注意：git checkout -- 文件名 中的 -- 不能省略，避免和分支切换的 git checkout 分支名 混淆；git restore 文件名 是Git 2.23版本后新增命令，功能更清晰，新手优先学习。

情况2：已执行 git add 进入暂存区，未执行 git commit

  1. 场景：文件已加入暂存区，发现修改错误，想撤销暂存区的修改，恢复到原始状态。
  2. 核心逻辑：分两步，先「撤销暂存区修改，回退到工作区」，再「丢弃工作区修改」。
  3. 命令说明：
    • git reset HEAD 文件名/git restore --staged 文件名：将暂存区的修改回退到工作区，文件状态回到「仅工作区修改」，暂存区恢复原始状态。
    • 后续执行 git checkout -- 文件名/git restore 文件名：丢弃工作区的修改，彻底恢复到原始状态。

情况3：已执行 git commit，立即发现错误

  1. 场景：提交后立即发现错误（如提交说明写错、代码有小bug），想撤销本次提交，保留修改内容，后续重新提交。
  2. 命令作用：git reset --soft HEAD^ 中，HEAD^ 代表「上一个版本」，该命令仅撤销版本库的本次提交，「暂存区」和「工作区」的修改都保留，可直接重新 git commit。
  3. 补充：若想连暂存区的修改也撤销，可使用 git reset --mixed HEAD^（默认模式），后续需要重新 git add 才能提交。

常见场景举例

场景1：仅工作区修改，撤销错误修改

我们编辑了 index.html，不小心删除了核心的页面结构代码，还没有执行 git add，想恢复到修改前的状态。

操作步骤：

bash 复制代码 
# 1. 进入仓库目录
cd ~/Desktop/test-git
# 2. 撤销工作区修改（二选一即可）
git checkout -- index.html
# 或 推荐新手使用
git restore index.html

执行结果：index.html 恢复到修改前的状态，不小心删除的核心代码被找回，工作区的错误修改被丢弃。

场景2：已暂存区修改，彻底撤销

当我们修改了 style.css，并执行了 git add style.css 加入暂存区，后来发现样式修改有问题，想撤销这次修改，恢复到原始状态。

操作步骤：

bash 复制代码 
# 1. 进入仓库目录
cd ~/Desktop/test-git
# 2. 第一步：将暂存区的修改回退到工作区
git reset HEAD style.css
# 或 新增命令：git restore --staged style.css
# 3. 第二步：丢弃工作区的修改
git checkout -- style.css
# 或 新增命令：git restore style.css
# 4. 验证撤销结果
git status

执行结果：style.css 恢复到修改前的状态，git status 提示「working tree clean」，暂存区和工作区都无该文件的修改记录。

场景3：撤销刚提交的错误版本，保留修改

我们刚执行了 git commit -m "修复导航栏样式"，提交后发现导航栏的样式问题更严重了，想撤销这次提交，保留修改内容，后续重新调整样式。

操作步骤：

bash 复制代码 
# 1. 进入仓库目录
cd ~/Desktop/test-git
# 2. 撤销本次提交，保留暂存区和工作区修改
git reset --soft HEAD^
# 3. 验证结果
git status
git log

执行结果：本次错误提交被撤销，git log 中看不到该提交记录，git status 提示文件处于暂存状态，可修改样式后重新 git commit。

6、文件删除与恢复 rm 文件名、git rm 文件名、git checkout -- 文件名/git restore 文件名、git commit -m "删除说明"

bash 复制代码 
# 情况1：正常删除（分步）
rm 文件名 （删除工作区文件）
git add 文件名 （同步删除操作到暂存区）
git commit -m "删除XXX文件" （提交到版本库，永久删除）

# 情况2：正常删除（简化，一步同步暂存区）
git rm 文件名
git commit -m "删除XXX文件"

# 情况3：误删恢复（未提交删除操作）
git checkout -- 文件名
git restore 文件名 （Git 2.23+ 推荐）

用法讲解

  1. 核心逻辑：Git不会自动跟踪文件的删除操作，删除工作区文件后，必须同步删除操作到暂存区，再提交到版本库，才算完成永久删除。
  2. 正常删除（分步 vs 简化）：
    • 分步删除（rm 文件名 + git add 文件名）：先删除工作区文件，再将「删除操作」加入暂存区（注意：这里 git add 文件名 不是添加文件，而是同步删除操作）。
    • 简化删除（git rm 文件名）：一步完成「删除工作区文件」和「同步删除操作到暂存区」，效率更高，新手优先推荐。
    • 无论哪种方式，最终都需要执行 git commit 提交到版本库，否则删除操作仅停留在暂存区，未永久生效。
  3. 误删恢复：
    • 场景：仅用 rm 文件名 删除了工作区文件，还没有执行 git add 和 git commit，想恢复被删除的文件。
    • 原理：版本库中还保留着该文件的最新记录，git checkout -- 文件名/git restore 文件名 会从版本库中恢复文件到工作区。
    • 注意：如果已经执行 git commit 提交了删除操作，无法用该命令恢复，需要通过「版本回退」回到删除前的版本。
  4. 验证：删除后执行 git status，会提示「deleted: 文件名」，说明删除操作已被跟踪；恢复后执行 ls，可看到文件已重新出现在工作区。

常见场景举例

场景1：简化删除，永久删除测试文件

仓库中有一个 test.txt 测试文件，测试完成后，想永久删除该文件，并在版本库中记录删除操作。

操作步骤：

bash 复制代码 
# 1. 进入仓库目录
cd ~/Desktop/test-git
# 2. 一步删除文件并同步到暂存区
git rm test.txt
# 3. 提交删除操作到版本库
git commit -m "删除测试文件 test.txt"
# 4. 验证结果
ls
git log

执行结果：test.txt 被永久删除，ls 看不到该文件，git log 中可看到删除提交记录，说明删除操作已同步到版本库。

场景2：误删核心文件，未提交删除操作，恢复文件

我们不小心用 rm index.html 删除了核心的首页文件，还没有执行 git add 和 git commit，想恢复这个文件。

操作步骤：

bash 复制代码 
# 1. 进入仓库目录
cd ~/Desktop/test-git
# 2. 恢复被误删的 index.html 文件（二选一即可）
git checkout -- index.html
# 或
git restore index.html
# 3. 验证结果
ls

执行结果：index.html 从版本库中恢复到工作区，和删除前的最新版本一致，ls 可看到该文件已恢复。

三、结尾

我把自己学习过程中最常用、最容易混淆的命令都整理好了，纯干货无废话，希望能帮到同样在学 Git 的你。如果这篇文章对你有用，别忘了点赞 + 收藏，你的支持是我持续输出的动力，后续还会更新 Git 分支、远程仓库等进阶内容，敬请关注～

封面图在这里自取：

相关推荐
AI视觉网奇5 小时前
ue metahuman 视频生成表情动画
笔记·学习·ue5
小苏兮5 小时前
【把Linux“聊”明白】命令行参数与环境变量
linux·运维·服务器·学习
im_AMBER5 小时前
Leetcode 110 奇偶链表
数据结构·学习·算法·leetcode
大雷神7 小时前
HarmonyOS智慧农业管理应用开发教程--高高种地-- 第24篇：学习中心 - 课程体系设计
大数据·学习·harmonyos
玉梅小洋11 小时前
Git 使用技巧——查看 Commit 修改文件的概要
git·github
小白郭莫搞科技14 小时前
鸿蒙跨端框架Flutter学习：CustomTween自定义Tween详解
学习·flutter·harmonyos
阳光九叶草LXGZXJ15 小时前
达梦数据库-学习-47-DmDrs控制台命令（LSN、启停、装载）
linux·运维·数据库·sql·学习
A9better16 小时前
嵌入式开发学习日志53——互斥量
stm32·嵌入式硬件·学习
进阶小白猿17 小时前
Java技术八股学习Day30
java·开发语言·学习
热门推荐
01GitHub 镜像站点02Clawdbot 中文汉化版 接入微信、飞书03OpenCode 入门教程：介绍 · 安装 · 配置第三方 API (如 Claude)042026美赛A题智能手机电池续航时间预测的连续时间数学模型052025 年大语言模型发展回顾：关键突破、意外转折与 2026 年展望06【Milvus】向量数据库pymilvus使用教程072026数学建模美赛题目特点与选题建议，常用四大模型汇总08Claude Code Skills 实用使用手册09一种新的LCA算法10UV安装并设置国内源