Git 入门与本地仓库（二）

本页对应 Git 入门与本地仓库，共 7 段视频，约 1 小时 17 分。

学习目标

• 能够使用 git init、git add、git commit -m 完成项目初始化，并将工作区修改按阶段提交到版本库。
• 能够使用 git status 判断文件处于工作区、暂存区或已提交状态，并通过 .gitignore 配置忽略指定文件或目录。
• 能够使用 git log、git log --oneline、git reflog 查看提交历史，并使用 git reset --hard <版本号> 切换到指定历史版本。
• 能够使用 git branch、git checkout 查看、创建和切换分支，并验证不同分支开发内容互不影响。
• 能够使用 git merge 将指定分支合并到当前分支，并在确认工作区已暂存并提交后，使用 git branch -D 删除无用分支。

知识点

先理解：为什么要忽略文件、为什么要看状态

Git 管理项目时，并不是所有文件都应该进入版本库。日志、编译临时文件、编辑器工作区设置等，常常是自动生成的；把它们塞进 Git，会让 git status 和提交记录变得很乱。笔记里给出的做法是创建 .gitignore，列出要忽略的文件。与此同时，我们还需要用 git status 判断文件到底处在工作区、暂存区，还是已经提交干净。

为什么需要：避免无关文件干扰版本管理。
怎么想：先看状态，再决定哪些文件要跟踪、哪些要忽略。
怎么做：用 git status 查看；用 .gitignore 配置忽略规则。
易错点：.gitignore 只影响“未被 Git 跟踪”的文件；已经提交过的文件，后来再写进 .gitignore 不会自动消失。

查看文件状态：红、绿、nothing to commit

测试步骤：

# 查看文件状态
git status

1. 红色: 工作区有文件更改

2. 绿色: 暂存区有文件更改

3. nothing to commit: 没有任何文件更改

为什么需要：不看状态就提交，很容易漏文件或把不该提交的文件提交上去。
怎么想：红色说明工作区有变化但还没暂存；绿色说明已经进入暂存区但还没提交；nothing to commit 说明当前没有可提交内容。
怎么做：每完成一个小目标就执行一次 git status，确认后再 git add、git commit。
易错点：终端必须在项目文件夹下打开。转写稿里反复强调：操作前先核对终端所在目录，别在别的文件夹里“叮咣咣当一顿操作”。

.gitignore 的基础语法

项目开发中，一般都会默认准备好 .gitignore 文件，了解基础语法即可。

# 这里演示的部分语法
# #之后的内容是注释 会被Git忽略
# 忽略 info.txt 文件
info.txt
# 忽略 .vscode/ 目录下所有的文件
.vscode
# 忽略目录下所有.md结尾的文件
*.md
# 会忽略 doc/目录下扩展名为txt的文件
doc/*.txt

为什么需要：用规则批量排除自动生成文件。
怎么想：忽略单个文件就写文件名；忽略目录就写目录名；按后缀忽略用 *.后缀；忽略某目录下某类文件用 目录/*.后缀。
怎么做：在项目根目录创建 .gitignore，写入规则并保存，再执行 git status 验证。
易错点：文件名是 .gitignore，不是文件夹；写错名字或放错目录，规则不会按预期生效。转写稿中演示了新建 try.txt 后它是红色，写入 .gitignore 后再次 git status，try.txt 消失，只剩 .gitignore 被跟踪。

需求实现：自动保存设置与忽略工作区设置

需求：修改 VSCode 工作区设置，设置失去焦点时自动保存文件，并通过 .gitignore 让 Git 忽略工作区设置。

步骤按笔记整理：

1. 创建新文件夹并初始化仓库，VSCode 打开文件夹，执行 git status。
2. 调整 VSCode 工作区设置，开启“失去焦点自动保存文件”并测试，再执行 git status。
3. 创建 .gitignore，配置忽略生成的工作区设置，再执行 git status。
4. 使用 Git 记录，记录过程中查看文件状态。

为什么需要：工作区设置是本机开发偏好，不应该混进项目提交。
怎么想：先让设置文件出现，用 git status 看见它；再用 .gitignore 排除；最后确认状态里不再出现。笔记语法中已经给出忽略 .vscode 目录的示例，因此可把工作区设置所在目录写进 .gitignore。
怎么做：初始化后先看状态；修改设置后再看状态；创建 .gitignore 写入忽略规则；再次 git status 验证；确认无误后 git add .、git commit -m "创建仓库并生成忽略文件"。转写稿中的验证过程是：新建 try.txt 后状态为红色；创建 .gitignore 写入 try.txt 后，try.txt 不再出现；git add . 后 .gitignore 变绿；提交后 git status 显示 nothing to commit, working tree clean。
易错点：提交前一定先看状态；git add . 前确认忽略规则已经生效；终端位置必须是当前项目文件夹。

小结与检查清单

• 忽略文件用 .gitignore，基础规则包括文件名、目录名、*.后缀、目录/*.后缀。
• 查看状态用 git status：红色在工作区，绿色在暂存区，nothing to commit 表示没有可提交内容。
• 工作区设置这类本机配置应忽略；配置后要再次 git status 验证。
• 每次提交前先看状态，先暂存再提交，提交信息写清楚“做了什么”。

分支是什么：为什么要把工作从主线上分离

本节对应文档：Git 分支-分支简介。笔记里这句话很关键：使用分支意味着可以把工作从开发主线上分离开来，以免影响开发主线。转写稿里讲师举的是团队开发场景：几个人都在一个仓库里开发，如果所有人都直接改主线，容易互相影响；更合理的做法是主线保持稳定，每个人在新分支上开发自己的功能，完成后再合并。这里先不展开合并，只建立“主线”和“新分支”是两条开发线的认识。

为什么需要：查看和切换分支之前，先要知道当前在哪个分支、仓库里有哪些分支，否则容易在错误的分支上提交。怎么想：把分支理解成指向某次提交的可移动指针，HEAD 表示“我现在在哪”。怎么做：先看分支图，再执行查看命令。易错点：不同 Git 版本默认分支名可能是 main，早期是 master；笔记也提醒“默认分支名不相同，不影响后续操作”，所以不要死记名字，先看实际输出。

图形说明：底部蓝色是记录的信息，从左往右；main 是默认分支，初始化仓库后就有；HEAD 指向当前分支 main。

这四张图连起来看：main 先有 3 次提交；从 main 当前提交创建 dev 后，dev 继承了这 3 次记录，又追加自己的 3 次；最后 HEAD 从 main 移到 dev，表示当前工作分支变成 dev。转写稿里口误说成“card 指针”，这里纠正为 HEAD 指针。

查看分支：先知道自己在哪

为什么需要：切换前不确认当前分支，可能把新提交做到主线上，或者以为自己在 dev 实际还在 master。怎么想：git branch 列出本地分支，分支名前的星号 * 表示当前分支；转写稿演示时特别强调“前面有一个星号，就代表你当前所处的就是这个分支”。怎么做：在项目根目录打开终端，执行查看命令。易错点：转写稿反复提醒要先检查终端所在目录是不是项目目录，别在 04 文件夹里操作 05 的仓库；另外默认分支可能叫 main 或 master，以命令输出为准。

# 查看分支
git branch

转写稿的调试过程是：初始化仓库后先完成首页布局、样式、逻辑三次提交，执行 git branch 看到 master 前有星号；创建并切换 dev 后，再执行 git branch，星号移到 dev。为了看清 HEAD 指向，转写稿还用 git log --oneline 观察输出中的 HEAD -> dev。注意：HEAD 只指向当前分支，输出里 dev 和 master 在同一提交上，是因为 dev 刚从 master 当前提交创建，内容相同。

切换分支：让 HEAD 指向另一个分支

为什么需要：开发新功能时要从主线切到独立分支，避免影响主线。怎么想：切换分支不是复制文件，而是把 HEAD 指针移到目标分支，并让工作区呈现该分支对应提交的内容。转写稿演示：从 master 创建 dev 后切到 dev，原首页、CSS、JS 文件都还在，因为 dev 继承了创建时 master 的提交；后来在 dev 提交注册页，再切回 master，注册页不存在，说明两条分支互不影响。怎么做：先 git status 确认当前修改已暂存并提交，再执行切换。易错点：转写稿强调“切分支之前一定要保证当前分支是暂存并提交的状态”；否则未提交内容会跟着工作区走，容易让你误以为已经提交到另一个分支。还要检查目录，别切错仓库。

# 切换分支
git checkout 分支名

调试时可用 git status 看是否干净，用 git log --oneline 看 HEAD -> 当前分支。如果切回 master 后看不到 dev 上独有的提交，是正常的，不是文件丢了。

重命名分支：默认名不一致时再处理

为什么需要：有的仓库默认叫 master，有的叫 main，团队统一命名时可能需要改。怎么想：重命名只改分支名，不改提交内容。怎么做：用 git branch -m 老分支 新分支。笔记代码保留如下。易错点：转写稿演示把 master 改成 main 后又改回，并提醒如果后续要推送到远程，远程默认分支可能仍是 master，随意改名会增加麻烦；知道命令即可，不建议在没沟通时乱改。参数顺序是“老分支 新分支”，别写反。

# 查看分支
git branch
# 切换分支
git checkout 分支名
# 重命名分支 ，如果默认是master，可以通过这个命令改为main
git branch -m 老分支 新分支

最后用转写稿的流程收束：进入项目根目录 → git branch 看当前分支 → 确认 git status 干净 → git checkout dev 切换 → 再用 git branch 和 git log --oneline 验证星号与 HEAD 是否指向 dev。这样就把“查看及切换分支”真正落地了。

先理解：分支就是一条可移动的指针

创建分支，本质上就是创建了一个新的、可以移动的指针；这个指针默认指向的位置和原分支一样。为什么需要它？因为实际开发时，主线上通常要保持可发布、可回退的状态，新功能如果直接在主线上写，容易互相影响。怎么想？把分支理解成“从当前提交位置复制出一条新的工作线”，创建出来时内容与当前分支一致，但后续提交会各自向前走。怎么做？在项目根目录执行：

# 创建分支
git branch 新分支名
# 切换分支
git checkout 分支名

# 这些是上一节学习的
# 查看分支
git branch
# 切换分支
git checkout 分支名
# 重命名分支 ，如果默认是master，可以通过这个命令改为main
git branch -m 老分支 新分支

易错点：git branch dev 只是创建，不会自动切换；执行后你仍在原分支。转写稿里反复强调“创建分支就是多出来一个分支，并将指针指向这个分支”，但当前工作分支要看 git branch 前面的星号，不能凭感觉。

查看与切换：先确认自己在哪条线

为什么需要查看？因为创建、切换、提交都依赖“当前分支”，一旦看错，代码就可能提交到错误分支。怎么想？操作前先 git branch 看星号，再 git status 看工作区是否干净；转写稿也强调“任何在切分支、做分支操作之前，都要先查看当前分支状态”。怎么做？用 git branch 查看，用 git checkout dev 切换。易错点：切换前若有未暂存、未提交的修改，先处理干净；提交信息要写清楚，别写“123”，要让自己和同事看得懂。

创建分支的完整演示

比如默认仓库状态如下：

• 1个分支：main
• 提交：3次
• 当前所在分支：main

执行 git branch dev 后：

• 2个分支：main，dev
• 提交：3次
• 当前所在分支：main

再执行 git checkout dev：

• 2个分支：main，dev
• 提交：3次
• 当前所在分支：dev

在 dev 分支继续“编码 → git add . → git commit -m"信息"”，重复3次后：

• 2个分支：main，dev
• 提交：3次（main），6次（dev，包含了main的提交）
• 当前所在分支：dev

易错点：转写稿里有一个真实调试过程：创建 dev 后没有立刻切换，就在 master 下新建 login.html 并提交，随后用 git log --oneline 才发现当前还在 master。切到 dev 后，dev 里没有这次 login 提交，因为 dev 是从切换前的位置创建的。这说明：正式开发前一定先切换，再写代码。

需求：创建并切换到 dev，实现注册页并记录

需求是基于提供的 Git 仓库（素材：08.Git分支-创建分支），创建并切换到新的分支 dev，实现注册页布局、样式、逻辑，并记录提交；布局、样式、逻辑实现基本效果即可。

参考步骤：

1. 创建并切换分支（dev）
2. 实现注册页布局、样式、逻辑，并记录

具体操作顺序可以这样走：先进入项目根目录，执行 git branch 确认当前分支；执行 git branch dev 创建分支；执行 git checkout dev 切换；再执行 git branch 确认星号在 dev 上。然后新建注册页文件，编写注册页结构和样式，补上基本逻辑，完成后执行：

git add .
git commit -m "完成注册页布局、样式与基本逻辑"

最后用 git log --oneline 查看提交，确认 HEAD 指向 dev，而 main 仍停在原来的提交位置。易错点：不要创建完分支就直接写代码；不要在 main 上提交注册页；提交前先 git status，确认改动都在 dev 分支下。

合并分支到底在合并什么

为什么需要：每个人在自己的分支上开发，开发完成后项目要整合。合并分支的作用，是把某个分支上的所有 commit 并到当前分支的 commit 上；合并完成后，多余分支就可以删除。

怎么想：先分清“接收方”和“来源方”。git merge 分支名 表示把指定分支合并到“当前所在分支”。所以不能站在 dev 上执行 git merge dev 自己合自己，而应先切到 main，再合并 dev。

怎么做：本节命令如下，原样保留：

# 将指定分支合并到当前分支
git merge 分支名
# 删除已合并的分支
git branch -d 分支名

# 这些是目前学习的分支相关命令
# 创建分支
git branch 新分支名
# 切换分支
git checkout 分支名
# 查看分支
git branch
# 切换分支
git checkout 分支名
# 重命名分支 ，如果默认是master，可以通过这个命令改为main
git branch -m 老分支 新分支

易错点：合并方向容易反。记住“先切到要保留的分支，再 merge 要并进来的分支”。删除分支用 -d，它针对已合并分支；删除前应先确认合并成功。

操作前先检查当前分支状态

为什么需要：转写稿里反复强调，切分支、做分支操作前要先查看当前分支状态。若工作区还有未暂存、未提交内容，直接切换容易把现场弄乱。

怎么想：合并前先确认自己在哪个分支、有没有未提交内容。视频中的调试过程是：先用 git status 看是否为 nothing to commit，确认干净后再切换。这里纠正同音字：不是“get states”，是 git status；不是“check out”读错，是 git checkout。

怎么做：上一节仓库操作完毕后状态如下：

• 2个分支：main、dev
• 提交：3次（main），6次（dev）
• 当前所在分支：dev

执行 git checkout main 后，当前分支变为 main，但此时 main 仍只有 3 次提交：

易错点：不要一上来就 merge。先 git branch 看分支，再 git status 看状态，最后切换。

把 dev 合并到 main

为什么需要：dev 上有 6 次提交，main 只有 3 次。整合时就是要把 dev 多出来的提交并到 main。

怎么想：当前已在 main，来源分支是 dev，所以命令是 git merge dev。执行后，main 也拥有 6 次提交。

怎么做：执行：

git merge dev

合并后状态：2个分支，提交 6次（main）、6次（dev），当前分支 main。

易错点：合并的是提交记录，不是简单“复制文件”。合并后应查看分支和日志，确认 main 已包含 dev 的提交。

删除已经合并的 dev

为什么需要：dev 的内容已经并入 main，保留它会增加分支管理成本，所以合并完可以删除多余分支。

怎么想：删除的是“已合并分支”。当前在 main，执行 git branch -d dev。转写稿中“杠D”就是 -d，不是大写随意写。

怎么做：执行：

git branch -d dev

删除后：只剩 1个分支 main，提交 6次（main），当前分支 main。

易错点：删除前确认已合并；若分支还有未合并提交，-d 不会随便删除，应先处理合并问题。不要在当前分支上删除自己正在使用的分支。

完整需求：合并并删除 dev

为什么需要：把零散命令串成真实流程：切到接收分支 → 合并来源分支 → 删除多余分支。

怎么想：需求是“将上一节 Git 仓库中的 dev 分支合并到 main 分支，并删除 dev 分支”。参考步骤就是：1. 切换到 main；2. 合并 dev；3. 删除 dev。

怎么做：

git checkout main
git merge dev
git branch -d dev

易错点：顺序不能乱。先 checkout main，再 merge dev，最后 branch -d dev。转写稿中调试时还先执行了 git status 确认 nothing to commit，这是好习惯：切分支前保证暂存并提交到仓库，再操作分支更稳。

分支命令补充总览

日常开发里，分支不只“查看、创建、切换”，还会遇到“创建后立刻切换”“删错分支要强制删”“分支名写错要重命名”。本节笔记先把常见命令列出来，标红部分就是补充内容：

操作	命令
查看分支	git branch
创建分支	git branch 新分支名
切换分支	git checkout 分支名
创建+切换分支	git checkout –b 新分支名
合并分支	git merge 分支名
删除分支	git branch –d 分支名
强制删除分支	git branch –D 分支名
重命名分支	git branch –m 老分支名 新分支名

为什么需要：多人开发时，每个人从主线上分出自己的分支，避免互相影响。
怎么想：先用 git branch 看自己在哪，再用补充命令减少重复操作。
怎么做：下面按“创建+切换、强制删除、重命名”逐条演练。
易错点：转写稿反复强调，任何分支操作前先看当前分支状态，必须“暂存并提交到仓库”再切换；转写稿里默认分支显示为 master，本节素材按笔记使用 main，名称不同不影响操作。

补充命令一：git checkout -b 创建并切换分支

为什么需要：如果先 git branch test 再 git checkout test，要敲两条命令；开发中更常用一条命令完成。
怎么想：checkout -b 可以理解为“创建分支 + 切换过去”，新分支默认指向和原分支相同的提交，相当于把当前状态复制出一条新线。
怎么做：

git status
git checkout -b test
git branch

执行后 git branch 里 test 前面有 *，表示当前在 test 分支。
易错点：-b 不能漏，漏了就可能变成切换已有分支；切换前工作区若有未提交改动，可能被带到新分支，所以先 git status。转写稿中“暂存机”应纠正为“暂存区”，提交前仍要先 git add 再 git commit。

需求演练：在 test 分支写两个功能并记录

素材是 main 分支 + 3 次 commit 的仓库：

参考步骤：先创建并切换到 test 分支，再写两个功能，比如注册页布局、样式并记录。命令流程可写成：

git status
git checkout -b test
# 创建注册页布局并提交
git add .
git commit -m "完成注册页布局"
# 编写注册页样式并提交
git add .
git commit -m "完成注册页样式"
git log --oneline

提交后仓库状态如下：

为什么需要：每完成一个小目标就提交一次，方便回看和回退。
怎么想：转写稿说“完成一个阶段目标就记录一次”，布局一次、样式一次，提交信息要让自己和同事看得懂。
怎么做：git add . 先放暂存区，git commit -m "信息" 再进版本库；用 git log --oneline 看提交和 HEAD 指针。
易错点：不能跳过暂存区直接提交；提交信息不要写“123”，要写清做了什么。

补充命令二：git branch -D 强制删除分支

为什么需要：普通 git branch -d 删除已合并分支；如果分支还有未合并提交，Git 会拒绝删除。此时才用 -D 强制删除。
怎么想：先切回 main，再删 test；不能删除当前所在分支。
怎么做：

git checkout main
git branch -D test
git branch

删除后回到 main 分支，状态如下：

易错点：-D 会强制丢弃该分支引用，未合并的提交可能丢失，删前先确认；转写稿中合并完 DV 后用 git branch -d DV 删除，是在“已合并”场景下用的，未合并才需要 -D。

补充命令三：git branch -m 重命名分支

为什么需要：分支名写错、命名不规范时需要改。
怎么想：-m 可理解为移动/重命名，格式是“老分支名 新分支名”。
怎么做：

git branch -m 老分支名 新分支名

例如转写稿演示过把 master 改成 main，再改回来。
易错点：老名和新名顺序不要反；转写稿提醒不建议随意改默认分支名，因为后续提交到远程时，远程默认分支可能仍叫 master，改名会增加麻烦。

调试与收尾

完整需求可以按下面顺序走一遍：

git status
git checkout -b test
git add .
git commit -m "完成注册页布局"
git add .
git commit -m "完成注册页样式"
git checkout main
git branch -D test
git branch

易错点：切分支前先 git status，确保暂存并提交；用 git branch 看星号确认当前位置；终端太长可用 clear 清屏。转写稿里的“get”应纠正为 Git，“her/card”应纠正为 HEAD，“杠杠 one line”即 --oneline。本节补充命令的核心就是：checkout -b 一步创建并切换，branch -D 强制删除，branch -m 重命名。

冲突为什么会出现：同文件、同位置、不同修改

文档地址。笔记里给出一句核心判断：如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修改，Git 就没法干净地合并它们。

为什么需要：分支让 main 和 dev 各自开发、互不打扰；但合并时 Git 必须判断“同一处到底听谁的”。当两边都改了同一处，Git 不能替你猜。怎么想：先把冲突理解成“合并时的选择题”，不是 Git 坏了。怎么做：让两个分支先有共同的前三次提交，再在第 4 次分别修改同一个文件 A（素材里是 index.js）的同一位置，且修改方式不同。易错点：不要以为“不同分支改同一文件”一定冲突，只有同一文件的同一部分被不同修改才容易冲突；也不要先执行 git branch -d dev 把 dev 删掉，否则后面无法合并。

复现冲突：让 main 和 dev 在第 4 次提交分叉

为什么需要：只有先复现，才能看到合并冲突的真实提示。怎么想：按笔记操作说明，准备两个分支 main、dev；前 3 次提交相同，第 4 次 main 改文件 A，dev 也改文件 A，但改法不同；当前所在分支是 main。怎么做：保留 dev，不要删除；在 main 上确认第 4 次提交已经完成。笔记里出现了下面这个命令：

git branch -d dev

它的作用是删除 dev 分支，不是制造冲突。本节实验里如果先执行它，git merge dev 就找不到 dev，这是典型误操作。易错点：转写稿里反复强调，做分支操作前先看当前分支状态，必须暂存并提交到仓库；否则带着未提交内容切分支或合并，容易把问题搅在一起。转写稿中的“get”应写作 Git，“抗it/commit”应写作 commit，“her/head”指 HEAD。

执行合并：在 main 上合并 dev

为什么需要：合并是把 dev 分支上的提交合并到当前分支，所以当前分支必须是 main。怎么想：笔记第 2 步是执行 git merge dev，把 dev 合并到 main。怎么做：在 main 分支上执行：

git merge dev

如果两个分支第 4 次都改了 index.js 的同一处，Git 会提示无法干净合并，文件进入冲突状态。易错点：合并前可用 git status 看工作区是否干净；转写稿里 nothing to commit 就表示暂存并提交过、没有待提交内容。合并后出现冲突不要慌，也不要直接删文件；先看 Git 和 VSCode 标出的冲突位置。合并成功后，笔记记录 main 会有 5 次提交：前 3 次与 dev 相同，第 4 次改文件 A，第 5 次是合并之后处理冲突的记录。

在 VSCode 里解决冲突并记录

为什么需要：冲突必须人为决定保留哪边、还是合并两边，解决后还要提交，才算完成合并。怎么想：笔记参考步骤要求根据 VSCode 提示解决冲突并记录。怎么做：打开冲突文件，使用顶部那一排选项：1—3 选了之后可以用 Ctrl+Z 撤销；4 选了之后会弹出新页面，对比新旧修改，可以关闭。处理完保存文件，再执行暂存和提交，例如：

git add .
git commit -m "记录：解决main合并dev的冲突"

提交后再用 git status 确认没有冲突文件，用 git log --oneline 可以看到 main 多出一次处理冲突的提交。易错点：只保存不 add、只 add 不 commit，都不算完成；不要漏掉“记录”这一步。VSCode 选项 1—3 可以撤销，适合先试看效果；选项 4 的对比页面看完可关闭，不要误以为关闭就是丢弃。最后再提醒：git branch -d dev 是删除分支的命令，应在合并完成、确认 dev 不再需要后再用，不要把它当成冲突解决步骤。

课件图示

代码示例

示例 1：.gitignore 忽略文件 + 查看状态命令

# 1. 初始化仓库（只需执行一次，重复执行会提示已存在）
git init

# 2. 查看文件状态
git status

# 3. 新建 try.txt 后再次查看状态（红色 = 工作区有文件未暂存）
git status

# 4. 创建 .gitignore（是文件，不是文件夹），内容如下

# .gitignore 文件内容
# #之后的内容是注释 会被Git忽略

# 忽略 info.txt 文件
info.txt

# 忽略 .vscode/ 目录下所有的文件（VSCode 工作区设置）
.vscode

# 忽略目录下所有 .md 结尾的文件
*.md

# 会忽略 doc/目录下扩展名为 txt 的文件
doc/*.txt

# 需求中演示：忽略 try.txt
try.txt

# 5. 忽略生效后再查看状态：try.txt 不再出现在未跟踪列表
git status

# 6. 先暂存，再提交（两步不能跳过）
git add .
git commit -m "创建仓库并且生成忽略文件"

# 7. 再次查看：nothing to commit, working tree clean
git status

关键行与易错点

• git status 三种结果要认清：红色 = 工作区有文件更改（未暂存）；绿色 = 暂存区有文件更改（未提交）；nothing to commit = 工作树干净，没有任何可提交内容。
• .gitignore 是文件名带点、没有后缀的文件，不是文件夹；写错名字（如 gitignore、.gitignore.txt）会导致忽略不生效。
• 每条规则一行，# 开头是注释；info.txt 忽略指定文件，.vscode 忽略整个目录，*.md 忽略某后缀全部文件，doc/*.txt 只忽略指定目录下的文件。
• git add . 的点代表全部文件，点前必须有空格；想只提交单个文件就把文件名写在那里（一般不推荐）。
• 必须遵循「工作区 → 暂存区 → 版本库」的顺序，不能直接提交到版本库；git commit -m 后面要写自己和同事都能看懂的提交信息。

---

示例 2：index.html（提交后引入 CSS 与 JS）

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>记录每次更新到仓库</title>
  <link rel="stylesheet" href="./css/index.css">
</head>
<body>
  hello
  <script src="./js/index.js"></script>
</body>
</html>

关键行与易错点

• 页面结构写完后先 git add . + git commit -m "初始化首页"，做到完成一个小目标就记录一次。
• href="./css/index.css"、src="./js/index.js" 是相对当前 html 文件的路径，文件夹名写错（css/js）样式和脚本都不会生效。
• 每新增/修改一次文件（新建 css、新建 js、再回头引入），都要重新 git add . 再 git commit -m "..."，一次提交对应一件事。
• 只改文件不暂存，git status 会一直显示红色；只 add 不 commit，则显示绿色。

---

示例 3：index.css 与 index.js

/* css/index.css */
body {
  background-color: #8df; /* 蓝色背景 */
}

// js/index.js
alert('你好');

# 对应记录过程（提交信息写清做了什么）
git add .
git commit -m "创建CSS文件并引入"
git add .
git commit -m "创建JS文件并引入"

# 分支相关操作（本节 07~11 命令汇总）
git branch                 # 查看分支，* 号所在行即当前分支
git branch dev             # 创建分支，默认指向与原分支相同
git checkout dev           # 切换分支
git checkout -b dev        # 创建并切换分支
git checkout main          # 切回主分支前，必须保证工作区已暂存并提交
git merge dev              # 把 dev 的提交合并到当前分支
git branch -d dev          # 删除已合并的分支
git branch -D test         # 强制删除未合并的分支
git branch -m master main  # 重命名分支

关键行与易错点

• 新建 css/、js/ 文件夹及文件后，文件都还在工作区，必须再走一遍 git add . → git commit -m。
• 分支操作前先 git status 确认是 nothing to commit（干净状态）再切换分支，否则容易把改动带到别的分支。
• git branch dev 只创建不切换，git checkout -b dev 才是创建+切换；git branch 前有 * 的才是当前分支。
• git merge dev 的含义是把 dev 合并到当前分支，当前分支写自己（如 main 合 main）没有意义。
• git branch -d 只能删除已合并的分支，删不掉时先确认是否已合并，需要丢弃才用 -D 强制删除。
• 两个分支对同一文件同一位置做不同修改时，合并会冲突，需在编辑器中选保留方案后重新 git add . + git commit -m "解决冲突" 记录。

常见错误

1. 现象：git status 里文件是红色，执行 git commit -m "xxx" 后提示 nothing to commit，或提交里根本没有这个文件。 原因：红色表示文件只停留在工作区，尚未进入暂存区；commit 只提交暂存区内容。 修法：先 git add .（或指定文件名），再 git status 确认变绿后 commit；养成“先看颜色，再提交”的习惯。

2. 现象：已经把 xxx 写进 .gitignore，git status 里它仍然出现。 原因：忽略规则只对未跟踪文件生效；已被 Git 跟踪的文件不受 .gitignore 约束。 修法：git rm --cached xxx（目录加 -r，本地文件保留），再提交一次；此后规则才生效。

3. 现象：本意只忽略某目录下的文档，结果根目录 README.md 也被忽略；或写了 doc/*.txt 却没忽略 doc/a/b.txt。 原因：规则相对 .gitignore 所在目录匹配，*.md 会递归匹配所有层级；doc/*.txt 只匹配 doc 下一层。 修法：用路径收窄（/README.md 只匹配根目录、doc/**/*.txt 匹配多级）；不确定时用 git check-ignore -v 文件名 看是哪条规则命中。

4. 现象：切换分支时报 Your local changes would be overwritten by checkout；或者切过去后，改动“跑”到了另一个分支上。 原因：工作区/暂存区有未提交内容，checkout 要么拒绝，要么把改动一起带过去。 修法：切分支前先 git status 确认 clean（暂存并提交），临时不想提交就 git stash，切完再 git stash pop。

5. 现象：git branch -d dev 报 not fully merged，删不掉。 原因：dev 上有提交还没合并进当前分支，-d 拒绝删。 修法：先切到 main 执行 git merge dev，再 -d；确认提交不要了才用 -D 强删（强删不删提交，仍可用 git reflog 找回指针）。

6. 现象：合并冲突后 git status 一直显示 unmerged paths，分支卡在合并中，后续提交都不正常。 原因：只手工改完了文件，没有 add + commit 完成这次合并提交；冲突解决是三步闭环，不是一步。 修法：改文件 → git add . → git commit（用默认合并信息即可）；想反悔用 git merge --abort 回到合并前。

7. 现象：命令都“执行成功”了，但文件不见了、提交出现在意料之外的分支或仓库。 原因：终端不在项目根目录——在上级目录或另一个仓库里操作，命令作用在了别的 .git 上。 修法：执行前先看终端路径（pwd）和 git status 输出的分支名与文件列表；确认目录对得上再敲命令。

8. 现象：git branch dev 创建成功，但开发了半天发现代码提交在 main 上。 原因：branch 只创建不切换，HEAD 仍在原分支。 修法：用 git checkout -b dev 一步创建并切换；开发前用 git branch 看星号在哪一行。

---

练习

1. 忽略工作区设置 新建空文件夹 → git init → 在 VSCode 中开启“失焦自动保存”，生成 .vscode/settings.json → 用 .gitignore 让 Git 忽略它 → 提交。 验收：git status 中看不到 .vscode；git check-ignore -v .vscode/settings.json 能指出命中的规则。 追问：如果先提交了 .vscode 再写忽略规则，怎么补救？写出命令。

2. 分支完整生命周期 在 main 上做 3 次提交 → 创建并切到 dev → 在 dev 上完成注册页布局、样式共 2 次提交 → 切回 main 观察文件是否消失 → 合并 dev → 删除 dev。 验收：git log --oneline 中 main 比原来多出 2 条记录；git branch 只剩 main。 加分：故意在 main 有未提交改动时执行切换，把报错原文抄下来并说明原因。

3. 制造并解决一次冲突 让 main 和 dev 修改 index.js 的同一处 → 在 main 上 git merge dev → 用编辑器解决冲突并提交。 验收：git log --oneline 中多出一条合并提交；git status 回到 clean。 要求：说明冲突标记 <<<<<<< / ======= / >>>>>>> 三段各代表什么，以及为什么解决后必须再 commit。

4. 命令补充与强删 用 git checkout -b test 建分支 → 写 2 个功能并各自提交 → 切回 main → 分别尝试 -d 和 -D 删除 test。 验收：记录两次删除的终端输出差异；强删后用 git log --oneline 与 git reflog 分别看 test 的提交还在不在，并解释结论。

5. 忽略规则设计 给一个前端项目写 .gitignore，至少覆盖：依赖目录、构建产物、日志、编辑器配置、本地环境变量文件。 验收：逐条用 git check-ignore -v 验证命中；再故意写一条会误伤的规则（如 *.md），说明它的副作用并改成安全写法。

---

原视频对照

#	视频	时长
1	记录每次更新到仓库-完成需求	09:25
2	记录每次更新到仓库	12:20
3	查看及切换历史版本	11:05
4	Git忽略文件	12:52
5	Git分支操作-查看及切换	16:01
6	Git分支操作-创建分支	06:44
7	Git分支操作-合并及删除分支	08:35

小结

1. git status 是每次操作前后的例行体检：颜色只告诉你文件停在哪个区，不代表操作对错；nothing to commit + clean 才是可以安全切换/合并的信号。
2. add 是选材、commit 是定格。一次提交只做一件事，提交信息写“做了什么”，是给同事和三个月后的自己看的。
3. .gitignore 必须在文件被跟踪之前生效；补救靠 git rm --cached，不是删本地文件。
4. 忽略规则按路径匹配，越具体越安全；拿不准就用 git check-ignore -v 验证，而不是靠猜。
5. 分支是指针不是拷贝，创建和切换成本极低——所以按任务开分支，主分支保持随时可交付。
6. 切换分支和合并前，工作区必须干净（已暂存并提交），这是硬性前置条件，不是建议。
7. merge 的方向是“把指定分支的提交搬到当前分支”，方向搞反是最常见也最贵的低级错误。
8. 冲突不是故障，是 Git 拒绝替你决策；解决冲突 = 改文件 + add + commit 三步闭环，缺一步都卡住。