Ch15 §02 Git 与仓库管理 · 讲解稿¶
章节定位: Ch15 协作工具。教"如何用 Git 高效协作": commit / branch / merge / rebase / PR。 承接: §01 Linux → §02 版本控制 走向: §03 代码设计 / §04 测试 / §05 DevOps 篇幅: ~3700 字 / 阅读 11 分钟 / 讲解 22-25 分钟
一 · 一句话总览¶
Git = 分布式版本控制。AI 工程师日常 80% 协作靠 Git: clone / commit / branch / PR / rebase / merge。代码 + 模型 + 数据版本管理, Git 是单一真相。
二 · 章节主线 (5 段)¶
第 1 段 · Git 基础 (8 分钟)¶
3.1.1 三状态¶
3.1.2 初始化与克隆¶
git init # 新仓库
git clone https://github.com/x/y # 克隆
git config --global user.name "Name"
git config --global user.email "a@b.com"
3.1.3 基本命令¶
git status # 状态
git add file.py # 加暂存
git add . # 全部
git commit -m "feat: add ..." # 提交
git commit --amend # 改最近 commit
git log --oneline -20 # 看历史
git diff # 工作区 vs 暂存
git diff --staged # 暂存 vs 仓库
3.1.4 远程仓库¶
git remote -v # 看远程
git remote add origin <url> # 加远程
git push -u origin main # 首次推送
git pull # 拉取 + 合并
git fetch # 只拉取, 不合并
第 2 段 · 分支管理 (10 分钟)¶
3.2.1 分支操作¶
git branch # 列出本地
git branch -a # 含远程
git checkout -b feature/x # 创建并切换
git checkout main # 切回
git branch -d feature/x # 删除 (已合并)
git branch -D feature/x # 强删 (未合并)
3.2.2 merge 与 rebase¶
merge: 保留分支结构, 生成 merge commit。
rebase: 把 commit 重放到目标分支, 历史线性。
比较:
| 维度 | merge | rebase |
|---|---|---|
| 历史 | 分支结构 | 线性 |
| commit 数 | +1 merge commit | 不变 |
| 冲突解决 | 一次性 | 每个 commit |
| 适用 | 公共分支 | 个人分支 |
黄金法则: 推送前 rebase, 推送后 merge。
3.2.3 冲突解决¶
git pull # 自动 merge
# 冲突文件
<<<<<<< HEAD
你的代码
=======
队友的代码
>>>>>>> branch
# 手动编辑
git add .
git commit # 解决冲突后 commit
3.2.4 交互式 rebase¶
编辑器中:
- pick: 保留
- reword: 改 message
- squash: 合并到前一个
- drop: 删除
3.2.5 stash¶
暂存未提交修改:
第 3 段 · 协作: PR / Code Review (8 分钟)¶
3.3.1 Pull Request 流程¶
- Fork / 切分支
- 写代码 + commit
- push 到远端
- 开 PR (描述变更)
- Review → 修改 → merge
- 删分支
3.3.2 Code Review 要点¶
- 正确性: bug, 边界
- 可读性: 命名, 注释
- 性能: 算法, IO
- 风格: linter / formatter
- 测试: 覆盖, 边界
3.3.3 提交规范 (Conventional Commits)¶
类型: feat / fix / docs / style / refactor / test / chore。
例: feat(auth): add OAuth login。
工具: commitlint, standard-version。
第 4 段 · 高级 Git (8 分钟)¶
3.4.1 cherry-pick¶
挑单个 commit 应用:
3.4.2 submodule¶
嵌入子仓库:
3.4.3 Git LFS¶
大文件存储:
3.4.4 worktree¶
多工作目录:
3.4.5 reflog¶
恢复误删:
第 5 段 · 实战与陷阱 (8 分钟)¶
3.5.1 仓库结构¶
project/
├── .git/
├── .gitignore # 忽略文件
├── README.md
├── src/
├── tests/
├── docs/
└── data/ # 通常 .gitignore
3.5.2 .gitignore 模板¶
Python:
3.5.3 Git LFS 用于 AI¶
避免 git 仓库膨胀。
3.5.4 常见陷阱¶
- commit 敏感信息: 用 BFG / git-filter-repo 清理。
- 大文件 push: 用 LFS 或外部存储 (S3)。
- force push: 慎用, 可能覆盖队友。
- submodule 嵌套: 复杂, 考虑 monorepo。
- 分支命名: 用前缀
feature/,bugfix/,release/。
3.5.5 Git 平台¶
| 平台 | 特点 |
|---|---|
| GitHub | 主流, Actions, Copilot |
| GitLab | 自托管, CI 强大 |
| Bitbucket | Atlassian 集成 |
| Gitee | 国内 |
三 · 易错点 (5 条)¶
- merge vs rebase: 已推送的分支别 rebase。
- commit --amend: 已推送别 amend。
- force push: 慎用, 通知队友。
- 大文件: 用 LFS, 别直接 add。
- git stash pop: 可能有冲突, 检查。
四 · 跨章连接¶
| 章节 | 关联 |
|---|---|
| Ch13 §03 OS | 文件系统 |
| Ch15 §04 测试 | CI 触发 |
| Ch15 §05 DevOps | GitOps |
五 · 自测 5 题¶
git rebase与merge区别?git reset --hard HEAD^后果?- cherry-pick 用途?
- Git LFS 解决什么问题?
- Conventional Commits 的 type?
六 · 一句话总结¶
Git = 协作核心。commit / branch / merge / rebase / PR 是基础, LFS / submodule / worktree 是高级。AI 工程师每天 80% 时间在 Git。Ch15 §03 进入代码设计。
七 · 板书建议¶
[板书 1: 三状态]
工作区 → 暂存 → 本地 → 远程
add / commit / push
[板书 2: 分支]
merge 保留 / rebase 线性
推送前 rebase
[板书 3: PR 流程]
分支 → 写代码 → push → PR → review → merge
[板书 4: LFS]
大文件追踪
模型权重
八 · 参考资料¶
- Pro Git (免费书)
- Conventional Commits 规范
- GitHub Docs
- Atlassian Git Tutorial