Git 工作流最佳实践：团队协作不踩坑

为什么需要 Git 工作流？

很多团队刚开始用 Git 时，大家都是直接 push 到 main 分支，结果：

• 代码冲突频繁
• 线上 bug 难追溯
• 新人不敢提交代码
• Code Review 形同虚设

一个好的 Git 工作流能解决这些问题。

主流工作流对比

1. Git Flow（经典但复杂）

main (生产)
  └── develop (开发)
        ├── feature/* (功能)
        ├── release/* (发布)
        └── hotfix/* (热修复)

优点：结构清晰，适合长期维护的项目 缺点：分支太多，流程复杂 适用：传统软件、版本发布周期长的项目

2. GitHub Flow（简单高效）⭐推荐

main
  └── feature-branch (从 main 创建，PR 后合并)

流程：

1. 从 main 创建功能分支
2. 开发完成后提 PR
3. Code Review 通过后合并到 main
4. 立即部署

优点：简单、快速、适合持续部署 缺点：不适合多版本并行维护 适用：SaaS、Web 应用、持续部署团队

3. Trunk Based Development（极致敏捷）

所有人直接提交到 main，配合功能开关（Feature Flags）。

优点：集成频率最高，冲突最少 缺点：需要完善的自动化测试 适用：成熟团队、高测试覆盖率项目

实战：GitHub Flow 详细流程

分支命名规范

# 功能开发
feature/user-login
feature/payment-integration

# Bug 修复
bugfix/login-timeout
bugfix/null-pointer-exception

# 紧急修复
hotfix/security-patch

# 文档更新
docs/api-reference
docs/readme-update

格式：type/description（用短横线分隔）

提交信息规范

# 格式：<type>(<scope>): <subject>

# 示例
feat(auth): add user login API
fix(api): resolve null pointer in user service
docs(readme): update installation guide
refactor(core): simplify data validation logic
test(api): add unit tests for payment module

常用 type：

• feat: 新功能
• fix: Bug 修复
• docs: 文档
• refactor: 重构
• test: 测试
• chore: 构建/工具

Code Review 清单

提交 PR 前自检：

• 代码通过本地测试
• 更新了相关文档
• 提交信息规范
• 无调试代码（console.log 等）
• 无敏感信息（密码、密钥）

Review 重点：

• 逻辑是否正确
• 是否有安全隐患
• 代码是否可读
• 是否有性能问题
• 测试是否充分

合并策略

Squash and Merge（推荐）：

• 将多个提交压缩成一个
• main 分支历史清晰
• 适合功能分支提交频繁的场景

Rebase and Merge：

• 保持提交历史线性
• 适合小改动

Create Merge Commit：

• 保留完整历史
• 适合重要功能，需要追溯

常见坑及解决方案

坑 1：长期不合并，冲突爆炸

场景：feature 分支开发了 2 周，合并时发现 100+ 冲突

解决：

# 每天同步 main 分支
git checkout feature-branch
git fetch origin
git rebase origin/main

坑 2：大文件误提交

场景：不小心提交了 node_modules 或构建产物

解决：

# 从历史中彻底删除
git filter-branch --force --index-filter \
  "git rm --cached --ignore-unmatch path/to/file" \
  --prune-empty --tag-name-filter cat -- --all

预防：完善 .gitignore

坑 3：敏感信息泄露

场景：密码、API Key 被提交到仓库

解决：

1. 立即撤销相关密钥
2. 使用 BFG Repo-Cleaner 清理历史
3. 使用 git-secrets 等工具预防

团队协作建议

1. 保护 main 分支：禁止直接 push，必须 PR
2. 要求 Code Review：至少 1 人 approve 才能合并
3. CI/CD 集成：PR 自动运行测试
4. 小步快跑：分支生命周期不超过 3 天
5. 及时清理：合并后删除已合并分支

工具推荐

• 可视化：GitKraken, SourceTree
• 命令行增强：git-delta, lazygit
• Code Review：GitHub PR, GitLab MR
• CI/CD：GitHub Actions, GitLab CI

结语

Git 工作流没有银弹，关键是适合你的团队。小团队用 GitHub Flow，大项目用 Git Flow，成熟团队可以尝试 Trunk Based。

最重要的是：保持一致，持续改进。

---

你们团队用的是什么 Git 工作流？有什么踩坑经历？