Git 学习笔记
引言
本片博客将会系统介绍 git 仓库的创建、工作区、暂存区、本地仓库（版本库）与远端仓库的操作，以及版本回退等常用命令（下述 bash 代码块中信息均为更改后的测试数据，例如有效，hash 值格式等均与实际数据不符）。
git 仓库创建
创建 git 仓库的两种方式：
- 在当前目录下执行
git init命令，会在当前目录下创建一个.git文件夹，里面存放着 git 仓库的所有信息，也可以使用git init <dir>创建一个指定目录的仓库，并在此目录下创建.git文件夹。 - 使用
git clone <url>命令，将远程仓库 clone 到本地，并创建一个同名的目录，并在此目录下创建.git文件夹。
工作区、暂存区、本地仓库与远端仓库操作
工作区（实际编辑文件的区域）通过 git add 命令将文件变更添加到暂存区（由 .git/index 维护），再通过 git commit 命令将暂存区中的内容提交到本地仓库（主要数据保存在 .git/ 目录中），最后使用 git push 命令将本地提交推送到远端仓库。
注：暂存区中的索引不会因为 commit 而清空，commit 操作实际上是将当前暂存区的快照保存到本地仓库中。若后续对文件进行修改并再次执行 git add，则会更新暂存区中对应的文件记录。再次执行 git commit 后，Git 会根据更新后的暂存区创建一个新的提交，原有提交仍然保留在提交历史中（此时查看本地仓库的信息就是最新的 commit 版本快照了）。
1. git add
git add：将工作区中的文件变更添加到暂存区，包括新增、修改和删除等变更。
git add .：将当前目录及其子目录中符合条件的文件变更添加到暂存区。git add -A：将整个工作区（即整个 git 仓库除 .git/）中符合条件的文件变更添加到暂存区，包括新增、修改和删除。git add test*.txt：将当前目录下匹配指定通配符的文件添加到暂存区。git add src/test*.txt：通过指定相对路径，将src/目录下匹配指定通配符的文件添加到暂存区。git add /path/to/test.txt：通过指定绝对路径，将指定文件添加到暂存区（路径必须位于当前 Git 工作区内）。
注意：
- 路径通常相对于当前工作目录，也可以使用绝对路径，但文件必须属于当前 Git 工作区。
- 通配符可能由 Shell 预先展开；如果希望将通配符作为路径模式交给 Git 处理，可以使用引号，例如
git add 'src/test*.txt'。 - 被
.gitignore忽略的未跟踪文件通常不会被普通的git add添加。
2. git commit
将暂存区中的文件变更提交到本地仓库，常使用 git commit -m "commit message" 命令，若不添加 -m 选项，则会默认打开一个文本编辑器，需要写入提交信息后退出编辑器。
3. git push
git push 命令，用于将本地分支的提交推送到远程仓库。
git push origin master：将本地 master 分支的提交推送到远程仓库 origin 的对应分支（通常为远程 master 分支）。
注： origin 是远程仓库名，master 是本地分支名。对于已配置上游分支的本地分支，直接执行 git push 通常可以推送到对应的远程分支。
4. git pull
git pull 命令，用于获取远程仓库的更新，并将其整合到当前所在的本地分支。
git pull origin master：获取远程仓库 origin 的 master 分支的更新，并将其整合到当前所在的本地分支。
注： origin 是远程仓库名，master 是远程分支名。直接执行 git pull 时，通常会根据当前分支配置的上游分支确定拉取来源。
状态查询
-
git status命令，查看当前工作区与暂存区的状态（add 但未 commit 的内容以及工作区更新的状态）。bashuser@host$ git status 位于分支 master 尚无提交 要提交的变更： （使用 "git rm --cached <文件>..." 以取消暂存） 新文件： test.txt 未跟踪的文件: （使用 "git add <文件>..." 以包含要提交的内容） test2.txt -
git log命令，查看提交（commit）记录。bashuser@host$ git log commit f238c35f63b8766dase49de7fs4d6 (HEAD -> master) （本次提交记录的 hash 值） Author: user <user@example.com> （本提交的作者和邮箱） Date: Wed Oct 14 03:46:22 2026 -0400 （本次提交的时间） 这是第二次提交 commit edads5dfdsa8c05eebd70217f8c0ee Author: user <user@example.com> Date: Wed Oct 14 03:46:05 2026 -0400 这是第一次提交注：
git log --oneline命令，可查看提交记录的简略信息。 -
git ls-files命令，查询的是 Git 暂存区索引（Index）中记录的文件路径（由于 commit 后，索引仍会留存在暂存区，所以也会查询到执行过 commit 命令的文件）。bashuser@host$ git ls-files test.txt test2.txt
注：
git ls-files --stage命令，可查看文件的暂存区详细信息，包括文件模式、对象哈希值和 stage 编号。git ls-files --others命令，可查看未被 Git 跟踪的文件（默认不显示被忽略的文件）。
版本回退
git reset
git reset 命令，用于回退版本，会根据指定选项调整暂存区和工作区的状态，具备以下三个选项：
git reset --soft <commit>：将当前分支回退到指定提交，保留暂存区和工作区的内容不变。git reset --mixed <commit>：将当前分支回退到指定提交，并重置暂存区，但保留工作区的内容（注：--mixed为缺省选项）。git reset --hard <commit>：将当前分支回退到指定提交，并重置暂存区和工作区，使其与指定提交保持一致。注意：工作区中未提交的修改可能会被覆盖或丢弃。
注：其中 <commit> 为指定回退的提交，可以是提交哈希值、分支名、标签名或其他任何可识别的提交对象，保存暂存区即保存 add 状态，文件索引，保存工作区即保存文件内容。
常用示例：
git reset --soft HEAD^：将当前分支回退到上一个提交，保留暂存区和工作区的内容。git reset --mixed HEAD^：将当前分支回退到上一个提交，重置暂存区，但保留工作区的文件内容。git reset --hard HEAD^：将当前分支回退到上一个提交，并使暂存区和工作区恢复到该提交的状态。
注：
HEAD表示当前分支最新提交；HEAD^/HEAD~表示当前分支最新提交的上一个提交；HEAD~2表示当前分支最新提交的上两个提交，以此类推也有HEAD~3等。hard选项要慎重使用，因为hard选项会丢弃工作区中的未提交的修改，回退版本时，一般都会使用缺省mixed或soft选项，避免工作区内容被丢弃。
git reflog
可使用 reflog 命令查看本地 HEAD 等引用的更新记录，其中通常包含 commit、reset、rebase、切换分支等操作引起的引用变化。
bash
git reflog
eda8f22 HEAD@{0}: reset: moving to eda8f22
316e98f HEAD@{1}: commit: 第二次提交
eda8f22 HEAD@{2}: reset: moving to HEAD^
f238c35 HEAD@{3}: commit: 这是第二次提交
eda8f22 HEAD@{4}: commit (initial): 这是第一次提交后可通过 git reset --hard <ref> 命令回退到指定历史执行后的状态。
差异查询
git diff 命令，用于查询工作区、暂存区和本地仓库中的提交之间的差异。
git diff：默认查询工作区与暂存区之间的差异，即尚未添加到暂存区的修改。git diff HEAD：查询工作区与本地仓库（当前HEAD提交快照）之间的差异，包含暂存区和工作区中的修改。git diff --staged/git diff --cached：查询暂存区与本地仓库（当前HEAD提交快照）之间的差异，即已经添加到暂存区、但尚未提交的修改。git diff <hash1> <hash2>：查询两个指定提交之间的差异，显示从<hash1>到<hash2>的文件内容变化。git diff <hash> <file>：查询指定文件在工作区中的内容与指定提交之间的差异。git diff --staged <file>：查询指定文件在暂存区与当前HEAD提交之间的差异。
文件删除
有两个方案：
- 使用 Linux 命令 rm 删除工作区文件 + git add 删除该文件在暂存区的索引，
最终 git commit 提交至版本库（本地仓库）。 - 直接使用 git rm 命令删除文件，git rm 命令会删除工作区文件、暂存区索引，
之后再执行 git commit 将该快照提交至版本库（本地仓库）即可。
注：如果只想将文件从暂存区中删除，但保留本地文件（工作区文件），可以使用 git rm --cached <file>。
文件忽略
- 在工作区根目录或子目录中创建
.gitignore文件，用于指定 Git 忽略的文件和目录。.gitignore中的规则通常作用于该文件所在目录及其子目录。 - 需要注意，对于已经被 Git 跟踪的文件，即使后续在
.gitignore中设置忽略规则，Git 仍会继续跟踪该文件的变更。 - 若需要停止跟踪已被 Git 管理的文件，可以使用
git rm --cached <file>等命令将其从暂存区移除，之后该文件便不会再被跟踪，但一般为确保版本统一，还需要进行git commit提交，将不再追踪该文件的信息确确实实提交至版本库（本地仓库）。 - 注意，
Git 默认不会追踪空文件夹，若需要 Git 忽略非空文件夹及其子文件，则仅需在 .gitignore 文件中添加该文件夹名称 + '/'。
注：.gitignore 的书写规则可参考官方文档：https://git-scm.com/docs/gitignore。
简单来说：
远程仓库
即 Gitee / GitHub 等代码管理平台，若想让远程仓库与本地仓库关联，则需要执行如下命令（遵循 Gitee / GitHub 创建、关联仓库的提示也可以），第一步为关联远程仓库，第二步为将当前本地仓库的 commit 内容提交至远程仓库。
这里额外说一下 git remote -v 命令：
bash
user@host:~/workspace/test_git$ git remote -v
origin git@gitee.com:example-user/test_git.git (fetch)
origin git@gitee.com:example-user/test_git.git (push)Git 是允许 fetch 和 push 操作不同远端仓库的，这里的两个输出就表示两个命令执行时会操作的远程仓库，可以看到，名称均为 origin，后面的 git@......是仓库地址。
分支分叉冲突与冲突处理
分叉冲突：当本地仓库与远端仓库分别产生新的提交时，双方的提交历史可能出现 分叉，此时，如果直接执行 git pull，Git 可能要求指定整合策略；如果执行 git push，也可能因为远端包含本地没有的提交而被拒绝。
下面 bash 演示了一个简单的分叉冲突场景：
bash
user@host:~/workspace/test_git$ git pull
提示：您有偏离的分支，需要指定如何调和它们。您可以在执行下一次
提示：pull 操作之前执行下面一条命令来抑制本消息：
提示：
提示： git config pull.rebase false # 合并（缺省策略）
提示： git config pull.rebase true # 变基
提示： git config pull.ff only # 仅快进
提示：
提示：您可以将 "git config" 替换为 "git config --global" 以便为所有仓库设置
提示：缺省的配置项。您也可以在每次执行 pull 命令时添加 --rebase、--no-rebase，
提示：或者 --ff-only 参数覆盖缺省设置。
fatal: 需要指定如何调和偏离的分支。
user@host:~/workspace/test_git$ git push
To gitee.com:example-user/test_git.git
! [rejected] master -> master (non-fast-forward)
error: 无法推送一些引用到 'gitee.com:example-user/test_git.git'
提示：更新被拒绝，因为您当前分支的最新提交落后于其对应的远程分支。
提示：再次推送前，先与远程变更合并（如 'git pull ...'）。详见
提示：'git push --help' 中的 'Note about fast-forwards' 小节。
user@host:~/workspace/test_git$ git status
位于分支 master
您的分支和 'origin/master' 出现了偏离，
并且分别有 1 和 2 处不同的提交。
（使用 "git pull" 来合并远程分支）
无文件要提交，干净的工作区
user@host:~/workspace/test_git$ git log --oneline --graph --decorate --all
* 5144ba7 (origin/master) update test.txt.
* 1a03cc9 这是第二次提交
| * 316e98f (HEAD -> master) 第二次提交
|/
* eda8f22 这是第一次提交能够发现，当提交历史发生分叉时，git push 以及 git pull 命令都可能提示失败，此时需要检查并整合提交历史：
- 使用
git status查看分支状态，发现远端有 2 个本地没有的 commit，本地有 1 个远端没有的 commit，即双方各自持有对方没有的 commit，出现了提交历史分叉。 - 使用
git log --oneline --graph --decorate --all查看提交历史，可以观察到本地与远端的分叉结构，发现双方从eda8f22开始分叉。 - 使用
git fetch origin（远程仓库名称，可选，若配置了上游分支名称则可不指定远程仓库名称）获取远端更新，但不会自动合并远端提交。git pull本质上就是先自动执行git fetch（远程仓库名称），再执行git merge/git rebase。 - 使用
git merge origin/master（表示远端的 master 分支）将远端跟踪分支的提交合并到当前本地分支。如果双方的修改可以自动合并，Git 就会自动完成合并，并生成一个新的 commit；如果发生真正的合并冲突，则需要手动解决，解决后需要手动进行 git add + git commit 将修改后的文件提交。 git pull本身就是 3、4 步的简写版本，所以使用git pull同样可以解决分叉冲突问题。
merge、rebase 与 pull
上文中也提到了 rebase，下面也来介绍下相关命令，后续分支章节中会详细介绍。
1. git merge
git merge <branch-name>：以当前所在分支为基准，将<branch-name>分支合并至当前所在分支，然后生成一个新 commit（注：若其中一个分支没有分支点后的 commit，则不会生成新的 commit）。git merge --abort：执行git merge后，若合并过程中发生冲突，导致有些文件合并成功，有些需要手动处理，则可以使用git merge --abort将本次合并操作取消，回到git merge前的状态。
2. git rebase
git rebase origin/master：将当前分支独有的提交重新应用到origin/master之后，使提交历史更加线性。git rebase --abort：执行git rebase后，若变基过程中发生冲突，则使用git rebase --abort将本次变基操作取消，回到git rebase前的状态。git rebase --continue：解决当前冲突后，继续执行变基。
3. git pull
git pull：获取远端更新，并根据配置的策略整合提交历史。git pull --no-rebase：使用merge策略整合提交历史。git pull --rebase：使用rebase策略整合提交历史。git pull --ff-only：远端具备新 commit 但本地没有新 commit 时使用，即没有发生分支冲突时的 pull，如果本地分支与远端分支已经分叉，则会失败，不会自动创建合并提交，也不会进行变基。
合并冲突与冲突处理
合并冲突：指定整合策略后，Git 会尝试对文件内容进行整合，如果双方修改了不同的文件，或者对同一文件的修改可以自动合并，Git 通常能够自动完成合并；如果双方对同一文件的同一部分进行了不兼容的修改，则可能产生合并冲突，此时需要手动解决，下面 bash 为简单的合并冲突示例：
bash
user@host:~/workspace/test_git$ cat test2.txt
ldskjfal;kjdflk;s
user@host:~/workspace/test_git$ git merge origin/master
自动合并 test2.txt
冲突（添加/添加）：合并冲突于 test2.txt
自动合并失败，修正冲突然后提交修正的结果。
user@host:~/workspace/test_git$ cat test2.txt
<<<<<<< HEAD
ldskjfal;kjdflk;s
=======
idlkafl
dlksjaf
dakldja
>>>>>>> origin/master可以发现，出现合并冲突时，Git 会自动将冲突的代码块用 <<<<<<< HEAD ======= >>>>>>> origin/master 三个标记包裹起来，并生成一个冲突文件，此时需要编辑该文件的内容，保存后需要使用 add + commit 提交该手动合并即可解决：
bash
user@host:~/workspace/test_git$ vim test2.txt
user@host:~/workspace/test_git$ git add -A
user@host:~/workspace/test_git$ git commit -m "docs(test): 实操 merge 手动解决合并冲突"
[master 3f9a97a] docs(test): 实操 merge 手动解决合并冲突
user@host:~/workspace/test_git$ git push当然，该步骤也可通过变基解决（注意 rebase 与 merge 遇到需要手动处理的冲突后的操作不同，rebase 应修改文件内容后使用 git add; rebase --continue，无需 commit，直接 push 即可）下面分支章节中会详细介绍 merge 与 rebase 的差异与行为。
分支与 rebase 使用
在项目开发过程中，常需要多人进行协作处理，共同进行开发的同时还需要保持至少一个分支的稳定，此时，就需要从主分支中创建出新分支，将新分支交给不同人员处理，关于分支的创建/合并/删除，可参考以下命令。
git branch命令可查看当前本地仓库的所有分支。git branch <branch_name>命令，可创建一个新的分支，但默认不会直接切换到该分支。git switch <branch_name>命令，可切换到指定分支。git merge <branch_name>命令，可合并指定分支到当前分支。git branch -d <branch_name>命令，可删除指定分支，注意，该命令需要确保<branch_name>分支已经合并到当前分支，否则会报错，若需要强制删除分支，可以使用git branch -D <branch_name>命令。
小实验：验证分支共享工作区，区分的主要是 commit 提交记录。
bash
user@host:~/workspace/test_git$ git branch dev
user@host:~/workspace/test_git$ git branch
dev
* master
user@host:~/workspace/test_git$ vim test2.txt
user@host:~/workspace/test_git$ git switch dev
M test2.txt
切换到分支 'dev'
user@host:~/workspace/test_git$ cat test2.txt
本地仓库多分支冲突处理实验 --master
user@host:~/workspace/test_git$ touch dev.txt
user@host:~/workspace/test_git$ ll
总计 20
drwxrwxr-x 3 user user 4096 Oct 15 10:06 ./
drwxrwxr-x 6 user user 4096 Oct 14 02:47 ../
-rw-rw-r-- 1 user user 0 Oct 15 10:06 dev.txt
drwxrwxr-x 8 user user 4096 Oct 15 10:01 .git/
-rw-rw-r-- 1 user user 49 Oct 15 09:59 test2.txt
-rw-rw-r-- 1 user user 23 Oct 15 09:18 test.txt
user@host:~/workspace/test_git$ git switch master
M test2.txt
切换到分支 'master'
您的分支与上游分支 'origin/master' 一致。
user@host:~/workspace/test_git$ ll
总计 20
drwxrwxr-x 3 user user 4096 Oct 15 10:06 ./
drwxrwxr-x 6 user user 4096 Oct 14 02:47 ../
-rw-rw-r-- 1 user user 0 Oct 15 10:06 dev.txt
drwxrwxr-x 8 user user 4096 Oct 15 10:07 .git/
-rw-rw-r-- 1 user user 49 Oct 15 09:59 test2.txt
-rw-rw-r-- 1 user user 23 Oct 15 09:18 test.txt可以观察到，先创建分支 dev，然后在 master 分支下修改 test2.txt，则切换到 dev 分支时，dev 分支中 test2.txt 的内容为 master 修改后的内容，且在 dev 创建新文件 dev.txt 后，master 分支中也存在 dev.txt 文件，即，所有分支共享工作区。
既然如此，那分支的作用是什么呢？不是说要隔离工作区吗？
值得一提的是，上面提到的分支分叉冲突等内容，虽然本地只有一个分支，但由于存在远程仓库，所以实际上是存在两个分支的（本地仓库和远程仓库），即上述出现的冲突问题本质是多分支问题，也就是说，对于本地仓库的多分支，也会出现这些问题，而解决方案就和上述提到的本地与远程仓库的冲突处理一样，即使用 git pull 或 git merge 或 git rebase 解决，下面尝试使用本地仓库多分支 + git rebase 解决冲突：
bash
user@host:~/workspace/test_git$ touch dev.txt
user@host:~/workspace/test_git$ git add -A
user@host:~/workspace/test_git$ git commit -m "多分支下 dev 创建新文件 dev.txt 并修改 test2.txt"
[dev b4e7cde] 多分支下 dev 创建新文件 dev.txt 并修改 test2.txt
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 dev.txt
user@host:~/workspace/test_git$ git rebase master
自动合并 test2.txt
冲突（添加/添加）：合并冲突于 test2.txt
error: 不能应用 316e98f... 第二次提交
提示：Resolve all conflicts manually, mark them as resolved with
提示："git add/rm <conflicted_files>", then run "git rebase --continue".
提示：You can instead skip this commit: run "git rebase --skip".
提示：To abort and get back to the state before "git rebase", run "git rebase --abort".
不能应用 316e98f... 第二次提交
user@host:~/workspace/test_git$ cat test2.txt
<<<<<<< HEAD
本地仓库多分支冲突处理实验 --master
=======
ldskjfal;kjdflk;s
>>>>>>> 316e98f (第二次提交)
user@host:~/workspace/test_git$ vim test2.txt
user@host:~/workspace/test_git$ git add -A
user@host:~/workspace/test_git$ git rebase --continue
[分离头指针 c82f6f8] rebase 手动处理合并冲突
1 file changed, 1 insertion(+), 1 deletion(-)
成功变基并更新 refs/heads/dev。
user@host:~/workspace/test_git$ git log --oneline --graph --decorate --all
* b18e7e0 (HEAD -> dev) 多分支下 dev 创建新文件 dev.txt 并修改 test2.txt
* c82f6f8 rebase 手动处理合并冲突
* 83064a7 (master) test(Git): 多分支下 master 更改 test2.txt 文件内容
| * 3f9a97a (origin/master) docs(test): 实操 merge 手动解决合并冲突
| |\
| |/
|/|
* | 5144ba7 update test.txt.
* | 1a03cc9 这是第二次提交
| * 316e98f 第二次提交
|/
* eda8f22 这是第一次提交实验流程以及现象分析：上述实验首先在本地仓库创建了 dev 分支，然后 master 分支修改了 test2.txt 文件，并提交，然后 dev 分支创建了 dev.txt 文件，并提交，最后 dev 分支使用 git rebase master 命令，将 dev 分支的修改合并到 master 分支中，但发现产生了 test2.txt 文件合并冲突，很奇怪，明明 dev 没有更改 test2.txt 文件（注意，上面 dev 的 commit 写错了，实际本次操作没有在 dev 分支下修改 test2.txt 文件），为什么会冲突呢？原因是 dev 分支是在 master 分支修改 test2.txt 文件之前创建的，且多分支本质还会共享工作区，也就是说，尝试合并时，相当于出现了 master 分支和 dev 分支的 commit 对比分支开始的 commit 都对 test2.txt 进行了修改，所以产生了冲突，需要手动解决。
关于变基操作，若在 dev 分支下执行 git rebase master，则 git 会以 master 为基，将 dev 分支的修改合并到 master 分支中，反之，若在 master 分支下执行 git rebase dev，则 git 会以 dev 为基，将 master 分支的修改合并到 dev 分支中。
而对于 merge 的合并，本质如下图：
即，将 main:3 后的两分支后续不同 commit 合并为同一个 commit 到本地仓库（每个分支都有属于自己的提交 -》 多个分支虽共享同一工作区，但本地仓库（快照）是独立的，而合并操作其实就是合并本地仓库（快照））。
git merge 和 git rebase 对比
两者均用于合并分支，但实现机制不同，也就导致出现以下特点：
git merge- 优点：不会破坏原分支的提交历史，方便回溯和查看。
- 缺点：会产生额外的提交节点，分支图比较复杂。
git rebase- 优点：不会产生额外的提交节点，形成线性历史，比较直观和干净。
- 缺点：会改变提交历史，改变了当前分支 branch out 的节点，应避免在共享分支下使用。
分支规范与模型
工作中，需要规范使用分支，下面介绍下常用的简单分支模型：GitHub Flow。
理解起来很简单，Master 分支为主分支，用于发布，需要开发时，需要创建其他分支（如图中的 Feature 分支），完成开发后，开发人员没有权限直接合并分支，需要向 Master 分支提交合并请求（Pull Request），经团队成员讨论后决定是否合并分支。
分支规范：
其他
配置相关
git config --global user.name <user-name>：配置全局用户名（写到磁盘文件，就算重启机器仍然生效）。git config --global user.email <user-email>：配置全局邮箱（写到磁盘文件，就算重启机器仍然生效）。git config --global credential.helper <credential-helper>：配置全局凭证管理（写到磁盘文件，就算重启机器仍然生效）。git config --global --list：查看全局配置。
git checkout 与 git restore
git checkout：是一个老版本多功能命令，可用于切换分支，回复文件等，但多功能性也是缺点，会导致使用不符合预期等，因此目前推荐使用git switch命令切换分支。
8550)]
其他
配置相关
git config --global user.name <user-name>：配置全局用户名（写到磁盘文件，就算重启机器仍然生效）。git config --global user.email <user-email>：配置全局邮箱（写到磁盘文件，就算重启机器仍然生效）。git config --global credential.helper <credential-helper>：配置全局凭证管理（写到磁盘文件，就算重启机器仍然生效）。git config --global --list：查看全局配置。
git checkout 与 git restore
git checkout：是一个老版本多功能命令，可用于切换分支，回复文件等，但多功能性也是缺点，会导致使用不符合预期等，因此目前推荐使用git switch命令切换分支。git restore <file>：用于恢复指定文件，默认将工作区中的文件恢复为暂存区中的版本；也可以使用git restore --source=<hash> <file>，将指定提交中的文件恢复到工作区（注意：可能覆盖工作区中该文件的未暂存修改），若需要将 commit 中的文件恢复到暂存区，则使用git restore --staged <file>。