分支模型和提交规范：主干开发、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 合并。

代码示例

# 功能分支开发
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 面试题：你们用什么分支模型、提交规范、怎么做代码评审。

3.4 KiB Raw Permalink Blame History Unescape Escape

分支模型和提交规范：主干开发、Git Flow、Conventional Commits、代码评审

解释说明

案例

代码示例

易错点

面试常问

3.4 KiB

Raw Permalink Blame History