Git Workflow
一、为什么需要分支策略
- 多人协作不互相阻塞
- 主分支随时可发布
- 紧急修复能快速上线
- 代码 review 落地
二、常见分支模型
1. Git Flow（重量级）
适合有明确版本发布周期的产品。
master ─────────────────●────●────●──→ (每次发布打 tag)
╲ ╱ ╲ ╱
release/1.2 ─────●─────────● ╲╱
╲ ╱ ╲ ╲╱
develop ──●────●────●────●─────────→
╲ ╱ ╲ ╱
feature/login ●──→ ●──→
╲ ╱
hotfix/pay-bug ●──→
master：生产环境代码develop：开发主分支feature/*：功能开发release/*：发布准备hotfix/*：紧急修复
缺点：分支多、流程重、对 CI 要求高。
2. GitHub Flow（轻量，推荐大多数团队）
适合持续部署的 web 项目。
main ─────●────────●────────●────→ (始终可发布)
╱ ╱ ╱
feature/x ●─────→ ●──→ ●──→
main：生产分支feature/*：任何新功能/修复都开 feature 分支- PR 合入
main之前必须有 review + CI 通过 - 合入
main即部署
3. GitLab Flow
介于两者之间，有 production / pre-production / main 几条长分支。
三、推荐实践：Trunk Based + Feature Flag
main ──●────●────●────●────→
╲ ╱
feature/pay ●───●──→
↓
上线时通过 Feature Flag 渐进放量
- 主分支开发，短命 feature 分支（< 2 天）
- 复杂功能用 Feature Flag 控制（LaunchDarkly、自建配置中心）
- 适合中大型团队 + 高频发布
四、Commit 规范
1. Conventional Commits
<type>(<scope>): <subject>
<body>
<footer>
type 取值：
| type | 含义 |
|---|---|
feat | 新功能 |
fix | 修复 bug |
perf | 性能优化 |
refactor | 重构 |
docs | 文档 |
style | 格式（不影响逻辑） |
test | 测试 |
build | 构建/依赖 |
ci | CI 配置 |
chore | 其他 |
revert | 回滚 |
示例：
feat(user): 支持微信登录
- 接入微信 OAuth
- 新增 wechat-login 组件
- 登录态存储到 localStorage
Closes #123
2. 自动化校验
用 commitlint + husky 在 commit 时校验（详见 统一编码规范）。
五、PR / Code Review
1. PR 标题
和 commit 规范一致：feat(user): 支持微信登录
2. PR 描述模板
## 背景
为什么做这个改动？
## 改动点
- 主要改动列表
## 测试
- [ ] 单元测试已加
- [ ] 自测通过
- [ ] 联调完成
## 截图 / 录屏
（如有 UI 改动）
## 风险
是否影响存量功能？是否需要数据迁移？
3. Review 关注点
- 业务：是否符合需求、边界场景
- 设计：是否符合现有架构、是否过度设计
- 代码：命名、可读性、重复代码
- 性能 / 安全：是否有明显问题
- 测试：覆盖率、关键路径
六、紧急修复 Hotfix
# 1. 从 main 拉 hotfix 分支
git checkout main && git pull
git checkout -b hotfix/pay-bug
# 2. 修复 + 提交
git commit -m "fix(pay): 修复支付回调签名校验问题"
# 3. 合回 main（先合 main 再 cherry-pick 到 develop）
git checkout main
git merge --no-ff hotfix/pay-bug
git tag v1.2.1
git push origin main --tags
# 4. 同步到 develop
git checkout develop && git merge hotfix/pay-bug
git push origin develop
# 5. 清理
git branch -d hotfix/pay-bug
七、避坑指南
- 不要把本地 commit 直接 push 到 main：失去 review 机会
- rebase vs merge：个人 feature 分支用 rebase 保持线性历史；合入 main 用 merge 保留分支轨迹
- 大文件不要进 git：用
.gitignore排除node_modules/dist - 敏感信息不要进 git：
.env/*.pem/*.key走环境变量或密钥管理 - commit 要原子化：一个 commit 只做一件事，方便 revert 和 cherry-pick
八、面试高频
- Q：rebase 和 merge 的区别？什么时候用？ A：merge 保留分支历史，rebase 把当前分支的 commit 重新接到目标分支顶端，历史更线性。个人 feature 分支合入前用 rebase 整理；合入 main 时用 merge 保留合并记录。
- Q：如何解决冲突？
A：理解冲突背景 → 手动解决 →
git add→git rebase --continue（rebase 时）或git commit（merge 时）。避免长分支并行开发，减少冲突概率。 - Q：为什么 main 分支要保持随时可发布？ A：方便紧急回滚、灰度发布、持续部署。任何合入的代码必须经过 review + CI。