【第6期】小蓝伞的 Git 第一课：从工作区到分支合并，真正把代码管起来

【第6期】小蓝伞的 Git 第一课：从工作区到分支合并，真正把代码管起来

系列：《从小白到 AI 大模型开发工程师的进阶之路》
技术点：AI-0006 Git 基础
主人公：小蓝伞

这一期解决什么问题

写 AI 项目时，最可怕的不是代码报错，而是“昨天还能跑，今天不知道改了什么”。Git 解决的不只是文件备份，而是让每次修改都有记录、每条实验线可以隔离、出现问题能够回到可靠节点。

本文从空目录开始，讲清工作区、暂存区、本地仓库和远程仓库的关系，并完成提交、分支、合并和冲突处理。命令可以在 PowerShell 或终端执行，路径请换成自己的练习目录。

一、先建立四层心智模型

1. 工作区：正在编辑的文件。保存文件，不等于 Git 已记录。
2. 暂存区：下一次提交的候选清单。git add是把修改放入清单。
3. 本地仓库：提交历史所在的位置。git commit才形成可回退版本。
4. 远程仓库：GitHub、GitLab 等服务器上的副本，由push和pull同步。

小蓝伞把它比作实验记录：工作区是草稿纸，暂存区是准备交作业的文件夹，本地仓库是实验日志，远程仓库是异地保险柜。把文件拖进保险柜，并不会自动生成实验过程。

二、最小实践：完成一次可回退提交

mkdir ai-git-demo cd ai-git-demo git init Set-Content -Path README.md -Value "# AI Git Demo" -Encoding utf8 git status git add README.md git diff --cached git commit -m "docs: 初始化练习仓库" git log --oneline --decorate -1

观察重点：git add前，文件是未跟踪状态；git diff --cached展示即将提交的内容；提交后git status应显示工作区干净。提交信息应说明“做了什么”，不要只写update。

三、分支是隔离变化，不是复制文件夹

git switch -c feature/prompt-notes Add-Content -Path README.md -Value "`n## Prompt notes" -Encoding utf8 git add README.md git commit -m "docs: 添加提示词笔记章节" git switch main git merge --no-ff feature/prompt-notes git log --oneline --graph --decorate --all

分支适合隔离功能和实验。AI 项目经常比较不同模型、数据清洗规则和提示词版本，先分支再实验，比在主分支上反复覆盖更容易复盘。

四、冲突不是报错，而是一道判断题

当两个分支修改同一段内容，Git 无法替你判断哪一版正确，于是留下冲突标记。处理顺序：

git status rg -n "<<<<<<<|=======|>>>>>>>" README.md # 手动保留正确内容并删除冲突标记 git add README.md git diff --check git commit -m "merge: 解决文档冲突"

不要直接git add .结束战斗。先检查冲突文件和最终差异；如果发现合并方向错了，可在提交前执行git merge --abort。

五、撤销操作的边界

目标	命令	风险说明
查看未暂存差异	git diff	只读、安全
查看已暂存差异	git diff --cached	提交前必看
取消暂存	git restore --staged 文件	保留工作区内容
丢弃未暂存修改	git restore 文件	会丢失该文件修改
查看提交图	git log --oneline --graph --all	只读、安全

git reset --hard会同时丢弃工作区和暂存区内容，不应当成“试试看”的快捷键。重要实验先提交临时节点，或至少做好备份。

六、面试题

1.git add与git commit有什么区别？
add选择下次提交的内容，commit把暂存区内容写入本地历史。

2. 为什么需要暂存区？
它允许从一批修改中精确选择本次提交的内容，使一次提交只表达一个完整意图。

3. 为什么使用分支？
为了隔离功能、实验和修复，降低互相覆盖风险，并让合并过程可审计。

4. 冲突应该怎样处理？
先定位冲突，人工判断最终内容，删除标记并验证，再暂存和提交；必要时中止合并。

5. 工作区干净是否代表远程也最新？
不代表。工作区干净只说明没有未提交修改，还需获取远程信息并比较分支状态。

七、本期小结

Git 的核心不是背命令，而是形成“修改—检查—提交—回退”的节奏。下一期学习 GitHub、SSH、Issue 和 Pull Request，给本地仓库接上异地备份与协作能力。

点个关注不迷路，继续跟着小蓝伞把 AI 工程基础一块块搭牢。把每一次修改留下证据，才能把一次次试错沉淀成真正的成长。

官方资料

• Pro Git 中文版
• Git 官方参考文档

  九、把本期练习变成可交付成果

  完成命令后，不要只截一张终端图。建议在仓库中保留 CHANGELOG.md，写下本次提交的目标、修改文件、验证命令和未解决问题；再执行 git status，确认没有把临时日志或个人配置带进去。每次提交尽量只表达一个完整意图，后面排查回归时才容易定位。

  如果实验失败，保留失败分支和错误说明并不可耻，真正危险的是删除现场后重新猜。可以用 git diff 对比失败前后，用 git log 找到最后一个可靠节点，并说明依赖的 Python 版本、数据文件和运行命令。