Git 配置与基本操作实战指南

1.4 配置的优先级

Git 的配置有三个层级，优先级从高到低依次为：

• 仓库级配置（当前仓库目录下的 .git/config 文件）；
• 用户级配置（用户主目录下的 .gitconfig 文件）；
• 系统级配置（Git 安装目录下的 etc/gitconfig 文件）。

当不同层级的配置冲突时，优先级高的配置会覆盖优先级低的配置。日常开发中，我们使用最多的是用户级配置（--global）和仓库级配置。

添加文件到仓库：从工作区到版本库的完整流程

Git 管理文件的核心流程是：工作区 → 暂存区 → 版本库。只有经过 git add（添加到暂存区）和 git commit（提交到版本库）两个命令，文件才算真正被 Git 管理起来。下面通过两个实际场景，带你掌握文件添加的完整操作。

2.1 场景一：新增文件并一次性提交

适用于一次性新增一个或多个文件，直接提交到版本库的场景。

操作步骤

创建本地仓库（若已创建可跳过）：首先创建一个工作目录，并初始化 Git 仓库：

# 创建工作目录
mkdir git-demo
# 进入工作目录
cd git-demo
# 初始化 Git 仓库
git init

执行 git init 后，当前目录下会生成一个隐藏的 .git 文件夹，这是 Git 的版本库，切勿手动修改其中的文件。

在工作区创建文件：创建一个 ReadMe.md 文件，并写入内容：

# 使用 vim 创建并编辑文件（Windows 下可使用 notepad 替代）
vim ReadMe.md

按 i 进入编辑模式，输入以下内容：

# Git 实战教程
这是一篇关于 Git 配置与基本操作的实战博客，适合新手学习。

按 Esc 退出编辑模式，输入 :wq 保存并退出。

将文件添加到暂存区：使用 git add 命令将工作区的文件添加到暂存区：

# 添加单个文件
git add ReadMe.md

若要添加多个文件或目录，可使用以下命令：

# 添加多个文件（用空格分隔）
git add file1.txt file2.txt
# 添加指定目录（包括子目录）
git add docs/
# 添加当前目录下所有文件和修改
git add .

将暂存区文件提交到版本库：使用 git commit 命令提交，并通过 -m 参数添加提交说明（提交说明不能为空，必须清晰描述本次提交的内容）：

git commit -m "feat: 新增 ReadMe.md 文件，添加 Git 实战教程说明"

提交成功后的输出

[master (root-commit) c614289] feat: 新增 ReadMe.md 文件，添加 Git 实战教程说明
1 file changed, 2 insertions(+)
create mode 100644 ReadMe.md

输出说明：

• master (root-commit)：表示在 master 分支进行第一次提交（root-commit）；
• c614289：本次提交的 commit id（版本号），是 SHA1 加密后的唯一标识；
• 1 file changed：1 个文件被修改；
• 2 insertions(+)：新增了 2 行内容；
• create mode 100644 ReadMe.md：创建了权限为 100644 的 ReadMe.md 文件。

批量添加多个文件

如果一次性新增了多个文件，可先添加到暂存区，再统一提交：

# 创建 3 个测试文件
touch file1.txt file2.txt file3.txt
# 分别添加到暂存区（也可直接使用 git add .）
git add file1.txt
git add file2.txt
git add file3.txt
# 一次性提交所有暂存区的文件
git commit -m "feat: 新增 3 个测试文件 file1.txt、file2.txt、file3.txt"

提交成功后输出：

[master 23807c5] feat: 新增 3 个测试文件 file1.txt、file2.txt、file3.txt
3 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file1.txt
create mode 100644 file2.txt
create mode 100644 file3.txt

2.2 场景二：新增多个文件，部分提交

适用于新增多个文件后，只想提交部分文件到版本库的场景，能帮助你理解暂存区的'筛选'作用。

操作步骤

在工作区新增两个文件：

# 新增 file4.txt 并添加到暂存区
touch file4.txt
git add file4.txt
# 新增 file5.txt，不添加到暂存区
touch file5.txt

提交暂存区的文件：

git commit -m "feat: 提交 file4.txt 文件"

提交后终端输出：

[master 3d406c0] feat: 提交 file4.txt 文件
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 file4.txt

可以看到，只有 file4.txt 被提交到了版本库，而 file5.txt 因为没有执行 git add 命令，仍停留在工作区，未被提交。

补充提交 file5.txt：若后续需要提交 file5.txt，只需补充执行 git add 和 git commit 即可：

git add file5.txt
git commit -m "feat: 补充提交 file5.txt 文件"

关键结论

• 只有通过 git add 添加到暂存区的文件，才能被 git commit 提交到版本库；
• 工作区中未执行 git add 的文件，不会被纳入本次提交，仍需后续手动处理。

2.3 查看.git 目录：揭秘 Git 的'内部存储'

在执行了上述操作后，我们可以通过查看 .git 目录的结构，来更直观地理解 Git 是如何管理文件和版本的。.git 目录是 Git 的核心，包含了版本库的所有信息。

查看.git 目录结构

使用 tree 命令查看 .git 目录（Linux 需先安装 tree：sudo yum install tree 或 sudo apt install tree；Windows 的 Git Bash 自带 tree 命令）：

tree .git/

核心目录和文件说明

执行命令后，会输出类似以下的目录结构（关键部分已标注）：

.git/
├── branches # 分支相关信息（较少使用）
├── COMMIT_EDITMSG # 最后一次提交的说明信息
├── config # 仓库的配置文件（包含用户信息、远程仓库地址等）
├── description # 仓库描述信息（主要用于 GitWeb）
├── HEAD # 指向当前所在的分支（默认指向 master）
├── hooks # 钩子脚本目录（用于提交前、提交后等触发操作）
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   └── ...（其他钩子脚本示例）
├── index # 暂存区（核心文件，记录被 add 的文件信息）
├── info # 仓库信息目录
│   └── exclude # 本地忽略文件（类似.gitignore，但仅本地生效）
├── logs # 提交日志目录
│   ├── HEAD
│   └── refs/heads/master
├── objects # 对象库（核心目录，存储文件内容、提交记录等）
│   ├── 23/
│   ├── 83/
│   └── ...（其他对象目录）
└── refs # 引用目录
    ├── heads # 分支引用（存储每个分支的最新 commit id）
    │   └── master
    └── tags # 标签引用（存储标签对应的 commit id）

关键文件详解

1. index：即暂存区，git add 后的文件信息会被记录在这里；
2. objects：存储所有文件的内容、提交记录等对象，每个对象通过 SHA1 哈希值命名，确保唯一性。

refs/heads/master：存储 master 分支的最新 commit id，通过 cat 命令可查看：

cat .git/refs/heads/master
# 输出：23807c536969cd886c4fb624b997ca575756eed6（最新的 commit id）

HEAD：指向当前分支的指针，通过 cat .git/HEAD 可查看：

cat .git/HEAD
# 输出：ref: refs/heads/master（表示当前指向 master 分支）

通过查看这些目录和文件，我们可以更深刻地理解：Git 的所有操作，本质上都是在修改这些目录和文件中的信息，从而实现对文件和版本的管理。

修改文件：跟踪每一处变更

Git 的核心优势之一是跟踪文件的修改，而不是文件本身。无论是新增一行、删除一行，还是修改字符，Git 都能精准记录这些变更。下面通过实战案例，带你掌握修改文件后的操作流程。

3.1 修改文件并查看状态

查看仓库状态：使用 git status 命令查看当前仓库的状态，了解文件的修改情况：

git status

输出结果：

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
  modified: ReadMe.md
no changes added to commit
(use "git add" and/or "git commit -a")

结果说明：ReadMe.md 文件已被修改，但尚未执行 git add 命令，修改仍停留在工作区，未添加到暂存区。

修改工作区的文件：编辑之前创建的 ReadMe.md 文件，新增一行内容：

vim ReadMe.md

修改后的内容如下：

# Git 实战教程
这是一篇关于 Git 配置与基本操作的实战博客，适合新手学习。
新增内容：掌握修改文件、版本回退、撤销修改等核心操作。

保存并退出 vim。

3.2 查看具体修改内容

git status 只能告诉我们文件被修改了，但无法查看具体修改了哪些内容。这时可以使用 git diff 命令，查看工作区与暂存区（或版本库）的文件差异。

查看工作区与暂存区的差异

git diff ReadMe.md

输出结果解析

diff --git a/ReadMe.md b/ReadMe.md
index 9c9e1f0..4a97140 100644
--- a/ReadMe.md
+++ b/ReadMe.md
@@ -1,2 +1,3 @@
 # Git 实战教程
 这是一篇关于 Git 配置与基本操作的实战博客，适合新手学习。
+新增内容：掌握修改文件、版本回退、撤销修改等核心操作。

• --- a/ReadMe.md：表示修改前的文件（暂存区中的版本）；
• +++ b/ReadMe.md：表示修改后的文件（工作区中的版本）；
• + 开头的行：表示新增的内容；
• - 开头的行：表示删除的内容（本例中无删除，故无此类行）；
• @@ -1,2 +1,3 @@：表示修改的范围（从第 1 行开始，共 2 行，修改后变为 3 行）。

查看工作区与版本库的差异

若想查看工作区与版本库中最新版本的差异，可使用：

git diff HEAD -- ReadMe.md

其中 HEAD 表示当前分支的最新版本。

3.3 提交修改后的文件

确认修改无误后，将修改提交到版本库，流程与新增文件一致：

# 将修改添加到暂存区
git add ReadMe.md
# 提交到版本库
git commit -m "docs: 新增 ReadMe.md 的核心操作说明"

提交成功后输出：

[master 94da695] docs: 新增 ReadMe.md 的核心操作说明
1 file changed, 1 insertion(+)

表示 ReadMe.md 文件被修改，新增了 1 行内容。

3.4 关键结论总结

Git 跟踪的是文件的'修改'，而非文件本身。每一次修改（新增、删除、修改字符）都需要通过 git add 和 git commit 提交到版本库；git status 用于查看文件的状态（未修改、已修改未暂存、已暂存未提交）；git diff 用于查看具体的修改内容，帮助确认修改是否符合预期。

版本回退：时光倒流，恢复历史版本

在开发过程中，难免会遇到修改错误、提交了有 Bug 的代码等情况。这时，Git 的版本回退功能就显得尤为重要，它能让你快速恢复到之前的稳定版本。

4.1 版本回退的核心命令：git reset

Git 的版本回退通过 git reset 命令实现，其核心作用是修改版本库中 HEAD 指针的指向，从而切换到不同的历史版本。命令格式如下：

git reset [--soft | --mixed | --hard] [HEAD]

关键参数说明

• --mixed：默认参数（可省略）。将暂存区的内容回退到指定版本，工作区文件保持不变；
• --soft：仅回退版本库的 HEAD 指针，暂存区和工作区的内容均不变；
• --hard：将版本库、暂存区、工作区的内容全部回退到指定版本（慎用！未提交的工作区修改会丢失，无法恢复）。

HEAD 说明

HEAD 是 Git 中指向当前版本的指针，常用写法如下：

• HEAD：当前版本；
• HEAD^：上一个版本；
• HEAD^^：上上一个版本；
• HEAD~n：前 n 个版本（如 HEAD~1 = 上一个版本，HEAD~3 = 前 3 个版本）；
• commit id：直接指定某个版本的 commit id（通过 git log 查看）。

4.2 实战：版本回退操作

为了演示版本回退，我们先创建 3 个连续的版本（基于 ReadMe.md 文件的修改）：

步骤 1：创建多个测试版本

# 第一个版本：添加 version1
echo "version1: 基础配置与文件添加" >> ReadMe.md
git add ReadMe.md
git commit -m "feat: 添加 version1 内容"
# 第二个版本：添加 version2
echo "version2: 修改文件与查看差异" >> ReadMe.md
git add ReadMe.md
git commit -m "feat: 添加 version2 内容"
# 第三个版本：添加 version3
echo "version3: 版本回退与撤销修改" >> ReadMe.md
git add ReadMe.md
git commit -m "feat: 添加 version3 内容"

步骤 2：查看版本历史

使用 git log 命令查看提交历史，获取 commit id：

# 简化输出（仅显示 commit id 和提交说明）
git log --pretty=oneline

输出结果（commit id 为示例，实际以你的为准）：

d95c13f (HEAD -> master) feat: 添加 version3 内容
14c12c3 feat: 添加 version2 内容
cff9d1e feat: 添加 version1 内容
94da695 docs: 新增 ReadMe.md 的核心操作说明
...（更早的提交）

可以看到，当前 HEAD 指向最新的版本 d95c13f（version3）。

步骤 3：回退到上一个版本（version2）

假设发现 version3 的内容有误，需要回退到上一个版本（version2），使用 --hard 参数（确保工作区也回退）：

# 回退到上一个版本（HEAD^ 或 HEAD~1）
git reset --hard HEAD^

执行成功后输出：

HEAD is now at 14c12c3 feat: 添加 version2 内容

步骤 4：验证回退结果

查看 ReadMe.md 文件的内容，确认是否回退到了 version2：

cat ReadMe.md

输出结果（version3 的内容已消失）：

# Git 实战教程
这是一篇关于 Git 配置与基本操作的实战博客，适合新手学习。
新增内容：掌握修改文件、版本回退、撤销修改等核心操作。
version1: 基础配置与文件添加
version2: 修改文件与查看差异

说明版本回退成功。

步骤 5：回退到更早的版本（version1）

若需要继续回退到 version1，可使用 HEAD~1（相对于当前版本，再回退 1 个版本）：

git reset --hard HEAD~1

验证结果：

cat ReadMe.md

输出中仅包含 version1 的内容，version2 的内容已被回退。

步骤 6：恢复到最新版本（version3）

如果回退之后后悔了，想重新恢复到 version3，需要先获取 version3 的 commit id。由于执行了 git reset 后，git log 已无法显示 version3 的记录，这时可以使用 git reflog 命令查看本地所有的 Git 操作记录：

git reflog

输出结果（关键部分）：

14c12c3 HEAD@{0}: reset: moving to HEAD~1
cff9d1e HEAD@{1}: reset: moving to HEAD^
d95c13f HEAD@{2}: commit: feat: 添加 version3 内容
14c12c3 HEAD@{3}: commit: feat: 添加 version2 内容
cff9d1e HEAD@{4}: commit: feat: 添加 version1 内容

可以看到，version3 的 commit id 是 d95c13f（部分 commit id 即可，无需完整输入）。

执行以下命令恢复到 version3：

git reset --hard d95c13f

验证结果：

cat ReadMe.md

可以观察到 version3 的内容已恢复，说明操作成功。

4.3 版本回退的注意事项

• 使用 --hard 参数前，务必确保工作区没有未提交的重要修改，否则会导致修改丢失；
• 若已将版本推送到远程仓库，回退本地版本后，切勿直接推送（会导致远程仓库版本不一致），需谨慎处理；
• git reflog 是恢复误回退版本的'救命稻草'，能记录本地所有 Git 操作，即使 git log 看不到的版本，也能通过它找到 commit id。

撤销修改：挽救误操作的'神器'

在开发过程中，难免会出现误修改文件、误添加到暂存区等情况。Git 提供了多种撤销修改的方式，可根据不同场景灵活使用。

5.1 场景一：工作区修改未 add（未暂存）

适用于：在工作区修改了文件，但还没有执行 git add 命令，想放弃修改，恢复到最近一次 git add 或 git commit 的状态。

核心命令

git checkout -- [file]

• --：至关重要，若省略，git checkout 会变成切换分支的命令，导致操作错误；
• [file]：要撤销修改的文件名称（如 ReadMe.md），若要撤销所有文件，可省略文件名（git checkout -- .）。

实战示例

在工作区修改文件（未 add）：

# 编辑 ReadMe.md，新增一行错误内容
echo "这是一行错误的修改，需要撤销" >> ReadMe.md
# 查看状态（确认未 add）
git status

输出结果：

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
  modified: ReadMe.md

撤销工作区的修改：

git checkout -- ReadMe.md

验证结果：

cat ReadMe.md

可以看到，新增的错误内容已被删除，文件恢复到了最近一次提交的状态。

5.2 场景二：修改已 add 未 commit（已暂存）

适用于：已执行 git add 将修改添加到暂存区，但还未执行 git commit，想放弃这次修改。

操作步骤

需要分两步：先将暂存区的修改撤销到工作区，再放弃工作区的修改。

撤销暂存区的修改（回退到工作区）：使用 git reset HEAD [file] 命令（--mixed 为默认参数，可省略）：

# 撤销暂存区的修改（file 为具体文件名）
git reset HEAD ReadMe.md

执行成功后输出：

Unstaged changes after reset: M ReadMe.md

此时，暂存区的修改已被撤销，修改仍保留在工作区。

放弃工作区的修改：沿用场景一的 git checkout -- [file] 命令：

git checkout -- ReadMe.md

验证结果：

git status

输出 nothing to commit, working tree clean，说明暂存区和工作区均已恢复干净。

简化操作（适用于熟练用户）

# 一步撤销暂存区和工作区的修改（慎用，确保无需保留工作区修改）
git reset --hard HEAD

5.3 场景三：修改已 add 且已 commit（已提交）

适用于：已执行 git add 和 git commit，将修改提交到了版本库，但想撤销这次提交，恢复到上一个版本。

核心命令

使用 git reset --hard HEAD^（回退到上一个版本），或指定具体的 commit id

# 回退到上一个版本（撤销最近一次提交）
git reset --hard HEAD^
# 或回退到指定版本（通过 git log 获取 commit id）
git reset --hard [commit id]

实战示例

误提交了错误内容：

# 新增错误内容并提交
echo "这是一次错误的提交，需要撤销" >> ReadMe.md
git add ReadMe.md
git commit -m "fix: 错误的提交（需要撤销）"

撤销这次提交（回退到上一个版本）：

git reset --hard HEAD^

验证结果：

cat ReadMe.md
git log --pretty=oneline

可以看到，错误提交的内容已被删除，版本库回退到了上一个版本，git log 中已看不到错误提交的记录。

注意事项

• 若已将提交推送到远程仓库，撤销本地提交后，切勿直接推送（会覆盖远程仓库的版本），需与团队沟通后处理；
• 若需要保留错误提交的代码，仅撤销提交记录，可使用 git reset --soft HEAD^，此时代码仍保留在暂存区，可后续重新修改提交。

删除文件：Git 中的'安全删除'与恢复

在 Git 中，删除文件也是一种'修改'操作，需要通过 Git 命令进行管理，否则会导致工作区与版本库不一致。Git 提供了两种删除场景：误删恢复和正常删除提交。

6.1 场景一：误删文件（工作区删除，未提交）

适用于：不小心在工作区删除了文件（如 rm file5.txt），但还未通过 Git 命令提交删除操作，想恢复文件。

实战示例

误删工作区文件：

# 查看当前文件列表
ls
# 输出：ReadMe.md file1.txt file2.txt file3.txt file4.txt file5.txt
# 误删 file5.txt
rm file5.txt
# 查看状态（Git 会提示文件被删除）
git status

输出结果：

On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
  deleted: file5.txt

恢复误删的文件：使用 git checkout -- [file] 命令，从版本库中恢复文件到工作区：

git checkout -- file5.txt

验证结果：

ls

输出中已包含 file5.txt，说明文件恢复成功。

6.2 场景二：正常删除文件（提交到版本库）

适用于：确实需要删除文件，并将删除操作提交到版本库，确保团队其他成员同步该删除操作。

操作步骤

删除工作区和暂存区的文件：使用 git rm 命令，同时删除工作区和暂存区的文件：

# 删除 file5.txt（同时从暂存区移除）
git rm file5.txt

执行成功后输出：

rm 'file5.txt'

提交删除操作到版本库：

git commit -m "del: 删除 file5.txt 文件"

验证结果：

ls
git log --pretty=oneline

输出中已无 file5.txt，git log 中能看到删除提交的记录，说明文件已从版本库中删除。

关键结论

• 直接使用 rm [file] 仅删除工作区的文件，暂存区和版本库仍保留该文件，需通过 git checkout -- [file] 恢复；
• 使用 git rm [file] 会同时删除工作区和暂存区的文件，再通过 git commit 提交后，版本库才会同步删除；
• 若已执行 git rm 但未提交，想恢复文件，可执行 git checkout -- [file]。

总结

Git 的基本操作看似多，但只要多动手实战，就能很快熟练掌握。这些操作是后续学习分支管理、远程协作、企业级分支策略的基础，务必扎实掌握。