Git 工作流最佳实践：团队协作必备

为什么需要 Git 工作流？

在团队开发中，统一的 Git 工作流能：

• 减少代码冲突
• 保持提交历史清晰
• 便于代码审查
• 支持持续集成/部署

主流工作流对比

1. Git Flow

适合有固定发布周期的项目。

分支结构：

• main：生产环境代码
• develop：开发主分支
• feature/*：功能分支
• release/*：发布分支
• hotfix/*：紧急修复分支

工作流程：

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

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

2. GitHub Flow

适合持续部署的 Web 项目，更简单。

核心规则：

• main 分支随时可部署
• 所有新功能从 main 创建分支
• 通过 Pull Request 合并
• 合并后立即部署

# 创建功能分支
git checkout -b add-oauth

# 推送并创建 PR
git push origin add-oauth
# 在 GitHub 上创建 Pull Request

# 审查通过后合并到 main

3. Trunk Based Development

适合成熟团队，强调小步快跑。

特点：

• 所有开发者直接向 main 提交
• 功能开关控制未完成功能
• 提交频率高，每次改动小

提交规范

Conventional Commits

feat: 添加用户登录功能
fix: 修复登录页面样式问题
docs: 更新 API 文档
refactor: 重构用户认证模块
test: 添加登录功能测试
chore: 更新依赖版本

格式： <type>: <subject>

类型说明：

• feat：新功能
• fix：修复 bug
• docs：文档更新
• style：代码格式
• refactor：重构
• test：测试相关
• chore：构建/工具

实用技巧

1. 提交前检查

# 查看变更
git diff

# 查看暂存区
git diff --staged

2. 撤销操作

# 撤销工作区修改
git checkout -- file.txt

# 撤销暂存
git reset HEAD file.txt

# 撤销最后一次提交
git reset --soft HEAD~1

3. 清理历史

# 交互式变基
git rebase -i HEAD~5

# 压缩提交
git rebase -i --squash HEAD~3

团队规范建议

1. 分支命名统一：feature/xxx, fix/xxx, hotfix/xxx
2. PR 描述模板：包含改动说明、测试情况、截图等
3. 代码审查要求：至少 1 人审查通过才能合并
4. 提交频率：小步提交，避免大堆头
5. 定期同步：每天至少 pull 一次 main 分支

总结

选择合适的 Git 工作流，建立团队规范，能让协作更顺畅，代码质量更高！