正在读取本机记录…

重要技术沟通◷ 70 分钟

Git、分支、提交、合并与版本发布

学会用版本记录参与工程协作。

学完你能做到

用自己的话解释“Git、分支、提交、合并与版本发布”及其核心术语。
在真实 AI 产品场景中识别何时应该使用本课方法。
完成一份可沉淀进“系统关系图、一次 API 调用与基础 SQL 练习”阶段任务的实践产出。

前置与关联课程

完成阶段 2 的能力检查，或先预览相关基础课

前置 · NoSQL、缓存、对象存储与向量数据库关联 · 环境、云服务、DNS、部署、CI/CD 与回滚

REAL SCENE

先从一个真实场景开始

开发修复登录问题时顺便混入课程样式改版，合并后线上又出现新错误。团队无法快速看出哪段变更导致，也不敢回退。Git 的价值不是“把代码上传”，而是用小而可解释的历史支持协作、审查和发布。

PLAIN EXPLANATION

说人话：它到底是什么？

Git 记录文件版本与变更关系。工作区是正在编辑的内容，暂存区选择准备提交的变化，commit 是带作者和说明的快照。分支让不同工作并行，合并把历史整合，冲突需要理解双方意图后解决。产品经理可用 Git 管理文档、原型说明或内容，至少要能查看状态与差异、创建清晰提交、理解评审和版本标签。

原子提交与差异

一个提交只表达一个可独立理解的目的，提交前查看 diff，避免临时文件、密钥和他人改动。消息说明做了什么及范围，必要时在正文记录原因和迁移影响。

先查看状态再开始工作
相关验证通过后再提交
生成文件按项目规则处理

分支、评审与冲突

短生命周期分支降低集成难度，评审围绕差异讨论。冲突不是简单选择任一边，而要确认两种变化的业务意图，整合后重新测试；长期分支会积累更大风险。

合并前同步目标分支变化
评审关联需求和验收证据
冲突解决后检查完整文件

版本与安全回退

标签或发布版本把提交与上线建立联系。回退通常创建一个撤销变更的新提交，保留历史；已经执行的数据迁移和外部副作用可能不能仅靠代码回退，需要独立方案。

发布记录精确 commit
密钥泄露需立即轮换
不随意重写共享历史

每次提交只包含一个已验证、可解释的变化。

合并冲突按业务意图整合并重新测试，不机械覆盖。

发布绑定精确版本，代码回退与数据恢复分别设计。

#Git #分支 #代码审查

KEY POINT

这节课最重要的结论

核心重点

小而清晰的提交让变更可理解、可审查、可回退。

为什么重要: 这决定了听懂工程语言、阅读接口和数据库方案，并判断技术取舍时，团队是否拥有一致、可验证的判断标准。
适用边界: 当问题目标、数据来源或失败成本发生变化时，不要机械套用；先重新确认假设和风险等级。

EXAMPLES

正确案例与常见反例

✓ 正确做法

产品文档与课程内容分别在短分支更新；提交前查看状态和差异，只暂存本任务文件。PR 关联需求、截图和测试。冲突时与作者核对两项规则后整合。发布记录 commit 与标签，发现问题可撤销该提交而不破坏共享历史。

× 常见误区

一个提交同时包含登录修复、样式重构、个人配置和密钥，消息写“update”。冲突时选择“接受全部我的更改”覆盖同事规则，没运行测试就合并。上线后只知道“大概是今天版本”，无法安全定位与回退。

和工程师这样沟通

“这次课程内容和登录修复请拆成两个可独立验证的提交。提交前看 diff 并排除本地配置；PR 写明验收结果。发布记录精确 commit，若涉及数据迁移，请另给前向修复与数据恢复步骤。”

HANDS-ON

必做实操任务

本节产出：“系统关系图、一次 API 调用与基础 SQL 练习”阶段任务中的《Git、分支、提交、合并与版本发布》一页实践卡

步骤 1在练习仓库查看 Git 状态并区分已修改、已暂存和未跟踪文件。
步骤 2只暂存一个小改动，检查差异后创建含范围和目的的原子提交。
步骤 3创建短分支修改同一段文档，模拟冲突并基于双方意图整合。
步骤 4为一个发布版本记录 commit、验证结果、回退命令和数据注意事项。

○

实践完成度 0/4

实践结果会自动保存在本机，并进入项目工坊的任务来源。

Git 变更交付记录

任务与范围：____
开始前状态：____
分支：____
修改文件及原因：____
不属于本任务的现有变化：____
暂存文件：____
差异检查：功能____ 安全____ 格式____
验证：____
提交信息：type(scope): summary____
评审链接与证据：____
冲突及双方意图：____
发布 commit / tag：____
代码回退：____
数据或外部副作用恢复：____

CHECKLIST

产品经理工作检查表

开发前是否记录仓库状态与已有未提交修改？提交是否只包含本任务文件且差异已逐项检查？提交信息是否说明变化类型、范围和目的？冲突是否依据业务意图解决并重新运行相关测试？发布是否绑定精确版本并区分代码回退与数据恢复？

INTERVIEW

常见面试题

产品经理为什么值得理解 Git 与版本发布？

展开参考回答

Git 让需求、内容和代码变更具有精确历史，产品经理可查看差异、确认范围、关联验收和追踪发布版本。回答应强调原子提交、短分支、评审、冲突按业务意图解决、发布绑定 commit，以及不夹带配置密钥和区分代码回退、数据恢复。

RECAP & FURTHER READING

重点回顾、延伸阅读与下一步

一句话回顾小而清晰的提交让变更可理解、可审查、可回退。

1
围绕“Git、分支、提交、合并与版本发布”继续阅读：查阅对应技术的官方入门文档，重点核对输入输出、失败方式、权限边界与可观测性。
2
用“Git、分支、代码审查”作为检索词，分别写下一条定义、一条适用边界和一个反例。
3
对照本课正确案例与反例，寻找一个公开案例并记录其中可复用的判断与不能照搬的条件。

关联术语