Git 基础概念与Git 基础命令总结（Day4 4/4）

本页对应 Day04_ES6&Git，共 6 段视频，约 40 分钟。

学习目标

能独立完成 Git 初始化配置，设置用户名和邮箱，并通过 git config --list 验证配置结果。
能在指定项目目录中执行 git init 初始化仓库，并说明 .git 目录与当前项目管理范围的关系。
能区分工作区、暂存区、版本库，并准确描述“工作区修改 → 暂存区 → 版本库”的提交流程。
能使用 git add -A 和 git commit -m "提交说明" 将工作区修改添加至暂存区并提交到版本库。
能使用 git status、git diff、git diff --cached 查看工作区、暂存区与版本库之间的状态和差异。
能在未提交前使用 git restore . 撤销工作区修改，使用 git restore --staged . 撤销暂存区内容，并验证撤销结果。

知识点

1. 初始化配置：先告诉 Git 你是谁

为什么需要：Git 每次提交都要记录“是谁提交的”。如果不配置用户名和邮箱，执行提交时会报错，提示你还没有设置用户名和邮箱。
怎么想：这是 Git 安装后的起始配置，不是每个项目都要做；同一台电脑、不重装系统，通常做一次即可。以后想改名字或邮箱，再执行一遍相同命令即可。
怎么做：在任意目录打开命令行都可以，执行下面两条命令，把名字和邮箱换成你正在使用的信息：

bash

git config --global user.name "小料"
git config --global user.email "小料@qq.com"

查看全部配置：

bash

git config --list

只看某一项配置：

bash

git config --get user.name

易错点：--global 是全局配置，两个横杠不要漏；--list 可以简写为 -l，但 --get 和 --list 都属于选项，写法要分清。转写稿里“confire”应纠正为 config，“get”应理解为 Git。配置成功后命令通常不输出内容，不代表失败。

2. 初始化仓库：一个项目一个 `.git`

为什么需要：Git 的管理单位是仓库，也叫版本库。一个项目对应一个仓库，仓库里记录代码的版本，方便备份和回退。
怎么想：不是整台电脑只建一个仓库，而是每个项目各自初始化一次。项目开发几天、几个月，通常也只初始化一次；换一个新项目再初始化。
怎么做：先进入项目目录，再执行：

bash

git init

执行后目录里会多出 .git 文件夹，它就是仓库相关数据的存放位置。
易错点：必须在项目目录下执行，项目代码也应放在该目录中；不要删除 .git，也不要手动修改里面的内容，改坏后仓库可能无法正常使用。转写稿里“IEIT”“IIT”应纠正为 git init。

3. 三个区域：工作区、暂存区、版本库

为什么需要：理解三个区域，才能明白为什么提交要分两步。
怎么想：工作区是你写代码、改文件的地方；暂存区是提交前的缓冲区；版本库保存一次次提交产生的版本。.git 里包含暂存区和版本库相关数据。
怎么做：开发时在工作区修改文件，然后先放入暂存区，再提交到版本库。每提交一次产生一个版本，后续可以回退。
易错点：只放到暂存区还不算完成提交；暂存区相当于“后悔缓冲区”，让你在真正提交前还能检查、撤回。转写稿里的“展存区”“感情区”都是“暂存区”，“白马库”是“版本库”。

4. 提交流程：`git add` 与 `git commit`

为什么需要：Git 不会自动把工作区所有修改变成版本，需要你明确选择并记录提交信息。
怎么想：最常用的一套流程是“先 add 到暂存区，再 commit 到版本库”。修改、删除、新增都属于变化。
怎么做：把工作区所有变化加入暂存区，推荐：

bash

git add -A

然后提交并写清楚本次提交内容：

bash

git commit -m "完成商品列表"

也可以用合并写法：

bash

git commit -am "修改首页"

易错点：git commit -m 后面的提交信息必须写，而且要认真写，方便以后版本回退时判断每个版本做了什么。-am 看起来省事，但它主要适用于已跟踪文件；新增的未跟踪文件仍要先 git add。课程里强调记 git add -A，因为新增、修改、删除都能一步到位；-A 的 A 要大写。

5. 查看状态与差异：`git status` / `git diff`

为什么需要：修改多了容易记不清哪些文件变了、哪些已暂存、哪些还没提交。
怎么想：git status 用来看整体状态：红色通常表示工作区有未暂存修改，绿色表示已进入暂存区；理想状态是工作区、暂存区、版本库一致。
怎么做：

bash

git status

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

bash

git diff

查看暂存区与最新提交的差异：

bash

git diff --cached

易错点：git diff 默认不是直接拿工作区与版本库比，而是看工作区与暂存区的差异；暂存区为空时，效果上接近工作区与最新版本比较。git diff 输出较长时可能进入分页界面，按 q 退出。转写稿里的“getd”“地府”应纠正为 git diff，“get space”是 git status。

6. 撤销修改与撤销暂存：没提交前的后悔药

为什么需要：改错了、删错了，在还没提交前应该能恢复。
怎么想：分两种情况。修改还没 add，直接撤销工作区修改；已经 add 到暂存区但还没 commit，先从暂存区撤回，再撤销工作区修改。
怎么做：撤销工作区所有修改：

bash

git restore .

从暂存区撤回：

bash

git restore --staged .

撤回后再执行 git restore .，工作区文件才会恢复。旧命令 git checkout 也能用，但新写法推荐 git restore。
易错点：git restore . 不会删除你新建的文件，新增文件需要手动删除；git restore --staged . 只把修改从暂存区撤回，工作区内容还在，所以通常要两步。转写稿里“rese到”“re stop”应纠正为 git restore，“杠杠STEG”是 --staged。只要还没提交，就有后悔机会；提交后要走版本回退，不在本节范围内。

一、安装后先做一次全局配置

为什么需要：Git 提交版本时要记录“是谁提交的”。如果没配置用户名和邮箱，执行到提交步骤会报错，提示你还没有设置用户名和邮箱。所以这是安装 Git 后的第一步。

怎么想：git config 是配置命令，--global 表示全局配置，对当前电脑上的 Git 生效。用户名和邮箱不需要实名认证，但邮箱最好用你正在使用的，方便以后识别提交记录。这个操作只在安装 Git 后做一次；只要不重装系统，以后不用反复做。换新电脑或重装系统后要重新配置。

怎么做：

bash

git config --global user.name "小料"
git config --global user.email "小料@qq.com"

查看所有配置：

bash

git config --list

只看某一项：

bash

git config --global user.name

易错点：命令是 git，不是转写里容易听成的“get”；--global 是两个横杠；两条命令要分别执行；以后想改名字或邮箱，再执行一遍对应命令即可；在命令行里粘贴不好使时，可以右键选择粘贴。

二、一个项目一个仓库：git init

为什么需要：Git 的管理单位是“仓库”，也可以叫版本库。仓库里记录项目的版本，方便备份和回退。但不是整台电脑只建一个仓库，而是一个项目一个仓库。

怎么想：先进入项目目录，再初始化仓库。初始化后目录里会多出一个 .git 文件夹，它就是这个项目的仓库。以后项目代码要放在这个目录里，Git 才能管理它。一个项目初始化一次；再做另一个项目，就在另一个项目目录里重新初始化。

怎么做：

bash

cd project
git init

初始化后可以用 ls -a 看到 .git 目录。

易错点：必须在项目目录下执行；每个新项目初始化一次，不是每次提交都初始化；.git 不要手动修改，也不要随便删除，改坏了仓库就可能出问题；项目代码要放在仓库目录里，放到别处 Git 管不到。

三、三区与提交流程：工作区→暂存区→版本库

为什么需要：Git 仓库分成工作区、暂存区和版本库。工作区是你写代码的地方；暂存区是提交前的缓冲；版本库保存一次次提交产生的版本。每提交一次产生一个版本号，以后才能回退。

怎么想：修改代码后，不能直接就算一个版本，要先 git add 把修改放进暂存区，再 git commit 提交到版本库。分两步不是麻烦，而是给你一次“后悔”的机会：放进暂存区后还可以再改、再撤。提交信息要写清楚，因为以后回退时主要看提交记录。

怎么做：

bash

git add -A
git commit -m "PC项目"
git status

git add -A 会把工作区里新增、修改、删除的变化都添加到暂存区。提交后暂存区就空了。

易错点：commit -m 后面必须写提交信息，不写会报错；提交信息不要乱写，要能说明这次改了什么；git add -A 里的 A 要大写；不要改一个字母就提交一次，也不要攒太久，比较合适的节奏是完成一个相对完整的功能后提交一次。

四、查看状态和差异

为什么需要：git status 能告诉你哪些文件变了，但不会展示具体改了什么；git diff 可以看更细的差异。

怎么想：git status 主要看两件事：工作区有没有未暂存的修改，暂存区有没有待提交的内容。红色通常表示还在工作区，绿色表示已经进入暂存区。git diff 看工作区和版本库的差异；git diff --cached 看暂存区里的内容。

怎么做：

bash

git status
git diff
git diff --cached

易错点：差异内容太长时可能进入 Vim 分页界面，按 q 退出，不要乱保存；git status 显示 nothing to commit, working tree clean 是理想状态；新增文件在 git diff 里不一定像修改文件那样列出内容，这是正常现象。

五、未提交前的后悔药：撤销修改与撤销暂存

为什么需要：代码改错了，但还没提交，应该能恢复。要分两种情况：修改还没 add，和修改已经 add 到暂存区。

怎么想：没进暂存区时，用 git restore . 把工作区恢复到当前版本库的样子；已经进暂存区时，先 git restore --staged . 把修改撤出暂存区，再 git restore . 恢复工作区。旧命令 git checkout 也能用，但新命令是 restore。注意：git restore . 恢复的是已跟踪文件的修改和删除，新增文件不会被自动删除。

怎么做：

bash

git restore .
git restore --staged .
git restore .

演示过程是：删除两个 js 文件、修改 html、新增一个文件后，git status 能看到变化；执行 git restore . 后，删除和修改被恢复，新增文件还在；如果已经 git add -A，先执行 git restore --staged .，状态会从绿色变回红色，再执行 git restore . 恢复工作区，最后手动删除新增文件即可。

易错点：撤销的前提是还没提交；--staged 只撤暂存区，不动工作区，所以要分两步；新增文件不要指望 restore . 删除；checkout 是旧写法，遇到时知道它和 restore 作用相近即可。

六、常用组合与提交节奏

最常用的完整流程就是：

bash

git add -A
git commit -m "完成商品列表"

转写里还演示了 git commit -am "修改首页"，它可以把已跟踪文件的修改和提交合为一步，省掉一次 add。但要注意：视频演示的是已跟踪文件的修改；新增文件仍应先 add，不要把所有情况都依赖 -am。

提交节奏没有死规定，核心是“完成一个相对完整的功能就提交一次”。这样版本库里的版本比较完整，回退时也能回到一个可用的状态。

作业目标：先把 GitHub 和 Gitee 账号准备好

为什么需要：这一节的作业是注册 GitHub 账号和码云账号。GitHub、Gitee 都是代码托管平台，后续做项目时，本地 Git 仓库可以推送到远程仓库，方便备份、协作和展示。账号是后续操作的前置准备，所以先完成注册，再进入本地 Git 配置。

怎么想：注册账号不是目的，目的是让本地 Git 与远程平台衔接起来。转写稿里反复强调，Git 操作前要先做初始化配置；账号邮箱最好使用你正在使用的邮箱，这样后续提交记录、账号识别更清楚。Git 的用户名不是实名认证，可以随便改，但邮箱最好真实可用。

怎么做：按下面作业要求打开官网，按页面提示完成注册，并记录好用户名和邮箱：

1. 注册 github 账号 https://github.com/
2. 注册码云账号 https://gitee.com/

易错点：不要把平台账号名直接当成 Git 的 user.name；不要用临时邮箱注册后忘记；注册完成后不要急着把密码写进 Git 配置。账号注册只是准备，本地 Git 还要单独配置。

从账号到本地：完成一次 Git 初始化配置

为什么需要：转写稿里说得很清楚，如果不配置用户名和邮箱，执行提交时会报错，提示你还没有设置用户名和邮箱。这个配置是 Git 提交记录的身份信息。

怎么想：这是“初始化配置”，只在 Git 安装后做一次；只要电脑不重装系统，以后不用反复做。换新电脑或重装系统后，再执行一次即可。转写稿里的 confire 应纠正为 config，get 指的就是 Git。

怎么做：在命令行执行两条命令，分别配置用户名和邮箱：

git config --global user.name "小料"
git config --global user.email "小料@qq.com"

查看配置可以用：

git config --list
git config --get user.name

易错点：--global 表示全局配置；粘贴命令时如果 Ctrl+V 不好使，可以右键选择粘贴；想改用户名或邮箱，重新执行一遍配置命令即可；邮箱最好用正在使用的邮箱。

每个项目初始化一个仓库

为什么需要：Git 的管理单位是“项目”，一个项目对应一个仓库，也叫版本库。仓库里记录代码的版本，方便备份和回退。

怎么想：不是整个电脑共用一个仓库，而是每个新项目初始化一次。转写稿里说“每个新项目只要初始化一次”，做完这个项目再做另一个项目，再初始化另一个仓库。

怎么做：先进入项目目录，再执行：

git init

执行后会生成 .git 目录，这个目录就是仓库相关内容的存放位置。

易错点：.git 不要手动修改，改坏了仓库可能就坏了；项目代码要放在该仓库目录下；不要在每个子目录里乱执行 git init，一个项目初始化一次即可。

用 add 和 commit 形成版本

为什么需要：工作区里改代码后，Git 不会自动形成版本。转写稿强调，要先把工作区修改添加到暂存区，再从暂存区提交到版本库；暂存区相当于多一次“后悔机会”。

怎么想：用 git status 看当前状态。红色通常表示工作区有修改，绿色表示已进入暂存区。提交后暂存区为空，工作区和版本库一致，就是理想状态。

怎么做：常用流程是：

git add -A
git commit -m "完成商品列表"

git add -A 把新增、修改、删除等变化都添加到暂存区；git commit -m 把暂存区内容提交到版本库，并写清提交说明。

易错点：-A 的 A 要大写；commit -m 后面必须写提交信息，不能不写；提交信息要有意义，方便以后回退时判断版本；不要改一个字母就提交一次，也不要攒太久，完成一个相对完整的功能后提交比较合适。

查看状态与撤销：提交前可以后悔

为什么需要：git status 只能告诉你哪些文件变了，不能详细展示具体改了什么；git diff 可以查看工作区与版本库的差异，git diff --cached 可以查看暂存区内容。转写稿里“地府”应纠正为 diff，“states”应纠正为 status。

怎么想：如果修改还没有 add，可以直接撤销工作区修改；如果已经 add 到暂存区，就先撤销暂存，再撤销工作区修改。新增文件通常不会被 restore 删除，需要手动处理。

怎么做：

git status
git diff
git diff --cached
git restore .
git restore --staged .

已添加到暂存区时，先执行 git restore --staged .，再执行 git restore .。

易错点：git diff 内容较长时可能进入分页界面，按 q 退出；restore 主要撤销未提交的修改，提交后要用版本回退思路；新增文件不在撤销范围内时，要手动删除。

完成作业时，先注册好 GitHub 和 Gitee 账号，记录常用邮箱；再按转写稿完成一次 Git 初始化配置，之后每个新项目执行一次 git init，用 git add -A 和 git commit -m "说明" 形成版本。这样账号、配置、仓库和提交这条链路就打通了。

课堂画面

课堂画面 1

课堂画面 2

课堂画面 3

课堂画面 4

课堂画面 5

课堂画面 6

代码示例

示例一：Git 三区示意图页面（HTML + CSS）

html

<!DOCTYPE html>
<html lang="zh-CN">
<head>
  <meta charset="UTF-8">
  <title>Git 基础命令速查</title>
  <style>
    :root {
      --bg: #0f172a;
      --card: #1e293b;
      --line: #334155;
      --text: #e2e8f0;
      --green: #22c55e;
      --blue: #38bdf8;
    }
    * { box-sizing: border-box; }
    body {
      margin: 0;
      padding: 24px;
      background: var(--bg);
      color: var(--text);
      font-family: system-ui, "Microsoft YaHei", sans-serif;
    }
    h1 { font-size: 20px; }

    /* 三个区域横向排列，窄屏自动换行 */
    .area { display: flex; gap: 12px; flex-wrap: wrap; margin: 16px 0; }
    .zone {
      flex: 1 1 180px;
      min-height: 96px;
      padding: 12px;
      border: 1px dashed var(--line);
      border-radius: 8px;
    }
    .zone h2 { font-size: 14px; margin: 0 0 8px; color: var(--blue); }
    .zone p { font-size: 12px; margin: 0; color: #94a3b8; }
    /* 暂存区和版本库同属 .git，用同样的绿色边框表示 */
    .zone.stage { border-color: var(--green); }
    .zone.repo { border-color: var(--green); background: rgba(20, 83, 45, .2); }

    ul { list-style: none; padding: 0; margin: 0; }
    li {
      background: var(--card);
      border: 1px solid var(--line);
      border-radius: 6px;
      padding: 10px 12px;
      margin-bottom: 8px;
      cursor: pointer;
    }
    li:hover { border-color: var(--blue); }
    code { color: var(--green); font-family: Consolas, monospace; }
    .tip { font-size: 12px; margin-top: 4px; color: #94a3b8; }
  </style>
</head>
<body>
  <h1>Git 基础命令速查</h1>

  <div class="area">
    <div class="zone">
      <h2>工作区</h2>
      <p>写代码的地方，开发者说了算</p>
    </div>
    <div class="zone stage">
      <h2>暂存区</h2>
      <p>git add 之后到这里，多一次后悔的机会</p>
    </div>
    <div class="zone repo">
      <h2>版本库（.git）</h2>
      <p>git commit 之后才有版本号，可以回退</p>
    </div>
  </div>

  <ul id="cmdList"></ul>

  <script src="./git-cmd.js"></script>
</body>
</html>

要点解释 / 易错点

三个 .zone 用 flex: 1 1 180px 均分并允许换行，对应“工作区 → 暂存区 → 版本库”的顺序。
暂存区和版本库的边框都设成绿色，因为转写稿强调“它俩放在一块儿，就是 .git 里边”。
box-sizing: border-box 必须写，否则 padding 会把三个卡片撑得宽度不一致。
中文页面必须写 <meta charset="UTF-8">，否则注释里的中文会乱码。

示例二：命令清单渲染与点击复制（JS）

// 所有命令均来自本节课的转写稿
const commands = [
  { cmd: 'git config --global user.name "小料"',   desc: '初始化配置：用户名，git 安装后只做一次' },
  { cmd: 'git config --global user.email "xx@qq.com"', desc: '初始化配置：邮箱，最好用正在使用的' },
  { cmd: 'git config --global --list',            desc: '查看所有配置，简写为 -l' },
  { cmd: 'git config --global user.name',         desc: '只看某一项配置' },
  { cmd: 'git init',                              desc: '仓库初始化，一个项目只做一次' },
  { cmd: 'git add -A',                            desc: '新增 / 修改 / 删除 全部加入暂存区，A 必须大写' },
  { cmd: 'git add index.html',                    desc: '只把指定文件加入暂存区' },
  { cmd: 'git commit -m "更新首页"',               desc: '提交到版本库，-m 后必须写提交信息' },
  { cmd: 'git commit -am "修改首页"',              desc: '添加并提交，一步到位' },
  { cmd: 'git status',                            desc: '查看状态：红=工作区，绿=暂存区，无输出=干净' },
  { cmd: 'git diff',                              desc: '查看工作区与版本库的差异' },
  { cmd: 'git diff --cached',                     desc: '查看暂存区与版本库的差异' },
  { cmd: 'git restore .',                         desc: '撤销工作区全部修改（新增的文件不会被删）' },
  { cmd: 'git restore --staged .',                desc: '把修改从暂存区撤回工作区' },
  { cmd: 'git checkout .',                        desc: '旧版撤销命令，向下兼容仍可用' }
];

const list = document.getElementById('cmdList');

// 用 createElement + textContent 拼装，避免命令里的双引号破坏 HTML 结构
commands.forEach(({ cmd, desc }) => {
  const li = document.createElement('li');
  li.dataset.cmd = cmd;

  const code = document.createElement('code');
  code.textContent = cmd;

  const tip = document.createElement('div');
  tip.className = 'tip';
  tip.textContent = desc;

  li.append(code, tip);
  list.appendChild(li);
});

// 点击整行复制命令
list.addEventListener('click', (e) => {
  const li = e.target.closest('li');
  if (!li) return;
  navigator.clipboard?.writeText(li.dataset.cmd);
});

要点解释 / 易错点

git add -A 与 git add . 不等价：转写稿明确说 . 能加“修改的和新建的，但删除的不行”，-u 只能加“被删除和被修改的，新增的不行”，只有 -A 三者通吃，且 A 必须大写。
git commit -m 后不写内容会直接报错（“必须包含一个值”），提交信息要写清楚这次改了什么，方便以后版本回退时辨认。
不要用字符串模板直接拼 data-cmd="${cmd}"，"小料" 里的双引号会把属性截断，这里改用 li.dataset.cmd = cmd 赋值。
navigator.clipboard 只在 https 或 localhost 下可用，本地双击打开文件时可能拿不到，所以用了 ?. 做保护。

示例三：用 JS 模拟“工作区 → 暂存区 → 版本库”流程

// 模拟 git 的三个区域，验证“两步提交”和“两级后悔”
const git = {
  repo: false,
  work: {},     // 工作区
  stage: {},    // 暂存区
  commit: {},   // 版本库（上一次提交的内容）

  init() {
    this.repo = true;
    console.log('Initialized empty Git repository in .git/');
  },

  write(file, content) {
    if (!this.repo) return console.log('还不是 git 仓库，先执行 git init');
    this.work[file] = content;
  },

  rm(file) {
    delete this.work[file];
  },

  // git add -A：把工作区所有修改放进暂存区
  addAll() {
    this.stage = { ...this.work };
    console.log('git add -A 已执行，修改进入暂存区');
  },

  // git commit -m "xxx"
  commitM(msg) {
    if (!msg) return console.log('fatal: -m 必须包含一个值');
    this.commit = { ...this.stage };
    this.stage = {};                       // 提交后暂存区清空
    console.log(`[master] ${msg}`);
  },

  // git status：只对比 工作区 vs 版本库、暂存区是否为空
  status() {
    const changed = Object.keys({ ...this.work, ...this.commit })
      .filter(f => this.work[f] !== this.commit[f]);
    if (!changed.length && !Object.keys(this.stage).length) {
      console.log('nothing to commit, working tree clean');
    } else {
      console.log('工作区改动（红）:', changed.join(', ') || '无');
      console.log('暂存区待提交（绿）:', Object.keys(this.stage).join(', ') || '无');
    }
  },

  // git restore --staged .：从暂存区撤回，工作区改动还在
  restoreStaged() {
    this.stage = {};
    console.log('已从暂存区撤回，工作区修改仍保留');
  },

  // git restore .：工作区回到版本库的样子
  restore() {
    this.work = { ...this.commit };
    console.log('工作区已恢复到上次提交的状态');
  }
};

// —— 走一遍完整流程 ——
git.init();
git.write('index.html', 'PC 项目首页');
git.write('index.js', 'function(){}');
git.status();          // 工作区有改动
git.addAll();
git.status();          // 变绿，在暂存区
git.commitM('PC 项目'); // 产生版本
git.status();          // nothing to commit, working tree clean

// —— 后悔一次：只撤销工作区 ——
git.write('index.html', '改坏了');
git.restore();
git.status();          // 又干净了

// —— 后悔两次：先撤暂存区，再撤工作区 ——
git.write('index.html', '又改坏了');
git.addAll();
git.restoreStaged();
git.restore();
git.status();

要点解释 / 易错点

commitM 里先把 stage 复制给 commit、再把 stage 清空，对应“从暂存区提交到版本库之后，暂存区就空了”。
status 同时检查两件事：工作区是否和版本库不同、暂存区是否有内容；两者都没有才是 nothing to commit, working tree clean 的理想状态。
git commit -m 缺少提交信息必须直接返回，对应转写稿里“它不允许，说 -m 必须包含一个值”。
撤销是“两级”的：restore --staged 只把修改从暂存区撤回工作区，工作区内容还在，必须再执行 restore 才能回到上一次提交的样子。
真实 Git 里 git restore . 不会删除新增的文件（转写稿：“新增的不会给你删”），本例简化了这一点，新增文件仍需手动 rm。

常见错误

1. 提交时报 Please tell me who you are / Author identity unknown

现象：git commit 直接失败，提示需要设置 user.email 和 user.name。
原因：安装后跳过了初始化配置，或换电脑/重装系统后没重做。
修法：执行一次 git config --global user.name "xxx" 与 git config --global user.email "xxx@xx.com"；用 git config --global --list 确认已写入。改名改邮箱也是重跑同样两条命令。

2. 仓库建错了地方，整个桌面/父目录都被"管理"了

现象：git status 里出现大量与项目无关的文件；或者在自己项目里敲 git status 却说 not a git repository。
原因：git init 之前没有先 cd 到项目根目录，仓库建在了上层目录或建在了子目录里。
修法：删掉误建的 .git（确认里面没有需要保留的历史），cd 到项目根目录重新 git init；仓库必须建在项目最外层。

3. 以为 git add 就算存好了，关机/改坏后找不回来

现象：git log 是空的或看不到刚才的改动；文件被覆盖后无法恢复。
原因：只把改动放进了暂存区，没有 git commit，暂存区不产生版本。
修法：git add -A 之后必须 git commit -m "有意义的信息"；用 git log --oneline 确认版本已生成，用 git status 确认回到 clean。

4. git commit 不带 -m 或信息为空，卡在编辑器里出不来

现象：屏幕进入一个奇怪的界面，光标不动，敲字也没反应；或提交被 abort。
原因：漏写 -m，Git 打开默认编辑器等你写提交信息；空信息会被拒绝提交。
修法：退出编辑器用 :q（或 :wq）；规范写法始终是 git commit -m "完成商品列表"，信息写清"这次改了什么"。

5. git diff 之后界面卡住，回不到命令行

现象：显示一大堆差异后，按回车只往下滚，无法输入命令。
原因：diff 内容被分页器（vim/less）接管，处于阅读模式。
修法：按 q 退出；嫌麻烦可 git config --global core.pager cat 关掉分页。

6. 撤销时只敲了 git restore --staged .，以为改动全没了

现象：git status 里文件还是红的，工作区内容依旧是被改坏的样子。
原因：--staged 只把改动从暂存区退回工作区，不动工作区文件本身。
修法：确认要丢弃工作区改动后，再执行一次 git restore .；两步顺序是"先退暂存、再退工作区"。注意 restore 不会删除你新建的文件，需要自己手动清理。

7. 手动删改 .git 目录里的东西

现象：仓库突然报错、分支丢失、无法提交。
原因：把 .git 当成普通文件夹清理或编辑。
修法：.git 只读不改；确实要重建，先备份整个项目再删 .git 重新 init（历史会一起丢掉）。

练习

练习 1：从零建一个受管理的项目 新建 demo 目录，在其中完成初始化配置检查（git config --global --list）、git init，放入两个文件后一次性提交，最后用 git status 与 git log --oneline 证明工作区干净且存在 1 个版本。验收：.git 位于 demo 根目录；git log 只有一条提交且信息可读。

练习 2：制造四种变化并观察 在上题仓库中同时做四件事：新增一个文件、删除一个文件、修改一个文件的内容、重命名一个文件。先跑 git status 记录每个文件的状态与颜色含义，再跑 git diff 看具体差异（记得退出分页器）。验收：能说出哪几项属于"修改"，并解释为什么新增文件在 git diff 里看不到内容。

练习 3：分步提交 vs 一步提交 先用 git add -A + git commit -m 提交一次；再改两处后用 git commit -am "..." 提交一次。验收：两次都成功，并能说明第二次为什么省掉了 add、以及在什么情况下 -am 会漏掉东西（提示：新增文件）。

练习 4：撤销三级演练 分别构造三种局面并各自恢复到干净状态：①改动只在工作区；②改动已 add 进暂存区；③改动已 commit。验收：①②用 restore 两步走完成；③能说明为什么 restore 无效、需要换哪类命令，并在纸上写出思路（不必真的回退成功）。

练习 5：提交信息规范化 给你手上这个项目连续做三次有意义的功能改动，每次提交信息按"动词 + 对象"格式书写（如"新增商品列表页"）。验收：git log --oneline 三条信息互不重复，且不看代码也能大致还原开发顺序。

原视频对照

#	视频	时长
1	git初始化配置	05:05
2	git初始化	04:11
3	工作区、暂存区、版本库	06:36
4	添加暂存区并提交版本库	12:35
5	查看状态和变化	04:48
6	撤销修改和撤销暂存	07:34

小结

初始化配置是"一次性成本"：装完 Git 做一次，除非换电脑或重装系统，否则不再重复。
管理单位是项目，不是磁盘：一个项目一个仓库，git init 只在项目根目录执行一次。
一个版本 = 一次完整提交；只在暂存区停留的改动不构成版本，也无法回退。
日常最高频的动作就是 add → commit 这一对，其余命令都是围绕它做检查与补救。
git status 是仪表盘：红=还在工作区，绿=已进暂存区，什么都没有=工作区、暂存区、版本库三者一致。
提交粒度以"完成一个相对完整的功能"为准，别攒太久，也别改一个字母提交一次。
后悔要分情况：没提交的用 restore（先退暂存、再退工作区）；已提交的属于版本回退，是另一套操作。
.git 是仓库本体，只读不改、不删；它一旦损坏，版本历史就一起没了。

Git 基础概念与Git 基础命令总结（Day4 4/4） ​

学习目标 ​

知识点 ​

1. 初始化配置：先告诉 Git 你是谁 ​

2. 初始化仓库：一个项目一个 .git ​

3. 三个区域：工作区、暂存区、版本库 ​

4. 提交流程：git add 与 git commit ​

5. 查看状态与差异：git status / git diff ​

6. 撤销修改与撤销暂存：没提交前的后悔药 ​

一、安装后先做一次全局配置 ​

二、一个项目一个仓库：git init ​

三、三区与提交流程：工作区→暂存区→版本库 ​

四、查看状态和差异 ​

五、未提交前的后悔药：撤销修改与撤销暂存 ​

六、常用组合与提交节奏 ​

作业目标：先把 GitHub 和 Gitee 账号准备好 ​

从账号到本地：完成一次 Git 初始化配置 ​

每个项目初始化一个仓库 ​

用 add 和 commit 形成版本 ​

查看状态与撤销：提交前可以后悔 ​

课堂画面 ​

代码示例 ​

示例一：Git 三区示意图页面（HTML + CSS） ​

示例二：命令清单渲染与点击复制（JS） ​

示例三：用 JS 模拟“工作区 → 暂存区 → 版本库”流程 ​

常见错误 ​

练习 ​

原视频对照 ​

小结 ​

Git 基础概念与Git 基础命令总结（Day4 4/4）

学习目标

知识点

1. 初始化配置：先告诉 Git 你是谁

2. 初始化仓库：一个项目一个 `.git`

3. 三个区域：工作区、暂存区、版本库

4. 提交流程：`git add` 与 `git commit`

5. 查看状态与差异：`git status` / `git diff`

6. 撤销修改与撤销暂存：没提交前的后悔药

一、安装后先做一次全局配置

二、一个项目一个仓库：git init

三、三区与提交流程：工作区→暂存区→版本库

四、查看状态和差异

五、未提交前的后悔药：撤销修改与撤销暂存

六、常用组合与提交节奏

作业目标：先把 GitHub 和 Gitee 账号准备好

从账号到本地：完成一次 Git 初始化配置

每个项目初始化一个仓库

用 add 和 commit 形成版本

查看状态与撤销：提交前可以后悔

课堂画面

代码示例

示例一：Git 三区示意图页面（HTML + CSS）

示例二：命令清单渲染与点击复制（JS）

示例三：用 JS 模拟“工作区 → 暂存区 → 版本库”流程

常见错误

练习

原视频对照

小结