67 lines
3.4 KiB
Markdown
67 lines
3.4 KiB
Markdown
---
|
||
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)：你们用什么分支模型、提交规范、怎么做代码评审。
|