Git 工作流终极指南：从混乱到优雅的团队协作

为什么需要 Git 工作流？

你有没有遇到过这些场景？

• 多人同时改一个文件，合并时冲突满天飞
• 不知道该从哪个分支拉代码
• hotfix 上线后忘记合回开发分支
• 发版时发现混入了未完成的功能

一套好的 Git 工作流能解决90%的协作问题。

三种主流工作流对比

1. Git Flow（经典但重量级）

分支结构：

• main：生产环境代码
• develop：开发集成分支
• feature/*：功能开发
• release/*：发版准备
• hotfix/*：紧急修复

# 开始新功能
git checkout -b feature/user-auth develop

# 完成功能
git checkout develop
git merge --no-ff feature/user-auth
git branch -d feature/user-auth

# 准备发版
git checkout -b release/1.2.0 develop
# ... 测试修复 ...
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0
git checkout develop
git merge --no-ff release/1.2.0

优点：适合有固定发版周期的项目。 缺点：分支太多，流程复杂，不适合持续部署。

2. GitHub Flow（简单高效）

分支结构：

• main：始终可部署
• feature 分支：所有开发

# 从 main 拉分支
git checkout -b fix-login-bug main

# 开发、提交、推送
git push origin fix-login-bug

# 创建 PR -> Code Review -> 合并 -> 自动部署

优点：流程简单，适合持续部署。 缺点：没有发版概念，不适合需要多版本维护的项目。

3. Trunk-Based Development（大厂标配）

核心思想：所有人直接往 main 提交（或极短生命周期的分支）。

# 短分支，当天合并
git checkout -b short-lived/add-cache main
# ... 小步提交 ...
git checkout main
git merge short-lived/add-cache

配套要求：

• 完善的 CI/CD 流水线
• Feature Flag 控制功能开关
• 足够的自动化测试覆盖

优点：集成频繁，冲突少，部署快。 缺点：对团队工程能力要求高。

如何选择？

• 小团队 / 开源项目 -> GitHub Flow
• 传统企业 / 固定发版 -> Git Flow
• 大厂 / 持续交付 -> Trunk-Based

实用技巧

1. Commit 信息用 Conventional Commits 规范
2. 开启分支保护，必须 PR + Review 才能合并
3. 用 git rebase 保持提交历史整洁
4. 善用 git stash 暂存未完成的工作
5. 配置 .gitignore 别把 node_modules 提交了

总结

没有完美的工作流，只有适合你团队的工作流。关键是全团队统一执行，有规范比规范本身更重要。