Git 本身只提供了底层的版本控制能力，而真正决定团队协作效率的， 是使用 Git 的方式——也就是工作流（Workflow）。
Git Flow：经典的分支模型
- master（main）：生产环境代码
- develop：开发主线
- feature/*：功能开发分支
- release/*：发布准备分支
- hotfix/*：紧急修复分支
# Feature 分支工作流
git checkout -b feature/user-login develop
# ... 开发完成 ...
git checkout develop
git merge --no-ff feature/user-login
# Hotfix 工作流
git checkout -b hotfix/critical-bug master
# ... 修复 ...
git checkout master && git merge --no-ff hotfix/critical-bug
git checkout develop && git merge --no-ff hotfix/critical-bug
适用场景：有明确发布周期的传统软件项目。不适合需要频繁部署的 Web 应用。
GitHub Flow：轻量级替代方案
- master 分支始终可部署
- 所有新工作从 master 拉出分支
- 尽早创建 Pull Request
- PR 通过 Review 和 CI 后才能合并
- 合并后立即部署
git checkout -b add-email-verification main
# ... 开发 ...
git push -u origin add-email-verification
# 创建 PR → Code Review → CI → 合并 → 部署Trunk-Based Development
被 Google、Facebook 等公司采用，分支生命周期极短（不超过一天）， 通过 Feature Flag 控制未完成功能的可见性。
三种策略对比
| 特性 | Git Flow | GitHub Flow | TBD |
|---|---|---|---|
| 分支数量 | 多（5 种类型） | 少 | 极少 |
| 分支生命周期 | 数周到数月 | 数天到数周 | 数小时到一天 |
| 部署频率 | 按计划发布 | 持续部署 | 每日多次 |
| CI/CD 要求 | 中等 | 高 | 非常高 |
Commit 规范
# 格式: <type>(<scope>): <subject>
# type: feat / fix / docs / refactor / test / chore / perf
feat(auth): 添加 JWT 刷新令牌支持
当访问令牌过期时，客户端可以使用刷新令牌获取新令牌。
Closes #234总结
没有"最好"的工作流，只有最适合团队的工作流。小型团队推荐 GitHub Flow； 传统项目考虑 Git Flow；技术实力强的团队可以尝试 TBD。 保持一致 Commit 规范和 Code Review 流程才是关键。
← 返回首页