阶段2（下）：运维专题 Docker/Nginx/Linux/CI-CD/Git 的课程、企业场景、面试题和可运行示例

topics/devops/git/01-branch-commit.md

@@ -0,0 +1,66 @@
+---
+id: devops.git.branch-commit
+title: 分支模型和提交规范：主干开发、Git Flow、Conventional Commits、代码评审
+type: lesson
+domain: devops
+stack: [git]
+tags: [分支模型, Git Flow, 主干开发, 提交规范, Code Review]
+level: basic
+est_hours: 1.5
+related: [devops.git.merge-rebase-recovery, devops.cicd.pipeline, devops.git.interview]
+week: [1, 8]
+order: 1
+---
+
+# 分支模型和提交规范：主干开发、Git Flow、Conventional Commits、代码评审
+
+## 解释说明
+
+**分支模型**
+
+| 模型 | 做法 | 适合 |
+| --- | --- | --- |
+| 主干开发（Trunk-Based） | 所有人基于 main 开短期功能分支（一两天内合并），未完成的功能用特性开关隐藏 | 有完善 CI、持续部署的团队 |
+| GitHub Flow | main 永远可发布；功能分支 → 合并请求 → 评审 → 合并 → 部署 | 大多数 Web 项目 |
+| Git Flow | `main`（发布）、`develop`（集成）、`feature/*`、`release/*`、`hotfix/*` | 有固定版本发布周期（App、客户端、私有化交付） |
+
+**提交规范（Conventional Commits）**：`类型(范围): 描述`，类型常用 `feat`、`fix`、`docs`、`refactor`、`test`、`chore`、`perf`。好处：历史清晰、能自动生成变更日志、方便按类型筛选。
+
+**好的提交**：一个提交只做一件事；提交信息说明“为什么”而不只是“改了什么”；不要把格式化和逻辑改动混在一起；不要提交生成文件、依赖目录和密钥（`.gitignore`）。
+
+**合并请求和代码评审**：合并请求小而聚焦（几百行以内）；描述写清背景、改动、测试方式；CI 通过 + 至少一人评审才能合并；main 分支开启保护，禁止直接推送和强制推送。
+
+## 案例
+
+本学习仓库的约定：直接在 main 上提交（个人项目），提交信息用中文描述；每个阶段完成后提交一次并推送；提交前运行 `tools/build_catalog.py --check` 和 `tools/check_sensitive.py` 检查内容规范和敏感信息。团队项目则用 GitHub Flow：`feat/xxx` 分支 → 合并请求 → CI + 评审 → squash 合并。
+
+## 代码示例
+
+```bash
+# 功能分支开发
+git switch -c feat/order-export
+git add -p                                 # 按块挑选要提交的改动，避免把调试代码带进去
+git commit -m "feat(order): 支持按月导出订单" -m "运营需要按月对账，导出改为异步任务，避免接口超时"
+git push -u origin feat/order-export       # 然后在平台上创建合并请求
+
+# 全局忽略编辑器和系统文件
+git config --global core.excludesFile ~/.gitignore_global
+printf '.DS_Store\n.idea/\n.vscode/\n' >> ~/.gitignore_global
+
+# 提交前钩子：.git/hooks/pre-commit（或用 pre-commit 框架统一管理）
+#!/bin/sh
+python3 tools/check_sensitive.py || exit 1
+```
+
+## 易错点
+
+- **一个提交几千行、混合多件事**：没法评审，出问题也没法单独回滚。
+- **提交信息写“update”“fix bug”**：半年后没人知道改了什么。
+- **长期不合并的功能分支**：和 main 差异越来越大，最后合并冲突无数。
+- **把 `.env`、密钥、大文件提交进仓库**：删除也会留在历史里。
+- **在公共分支上强制推送**：覆盖别人的提交。
+- **把 `node_modules`、构建产物提交**：仓库膨胀、冲突频繁。
+
+## 面试常问
+
+见 [Git 面试题](interview.md)：你们用什么分支模型、提交规范、怎么做代码评审。