记录团队 Git 工作流的实践总结，涵盖分支模型、提交规范与冲突处理。

分支模型选择

Git Flow（适合发布周期长的项目）

  • main：生产环境代码，每次合并打 tag。
  • develop：集成测试分支。
  • feature/*：功能开发分支，从 develop 拉出。
  • hotfix/*：紧急修复分支，从 main 拉出。

GitHub Flow（适合持续部署的项目）

  • main：始终可部署。
  • feature/*：功能分支，通过 PR 合并到 main。
  • 合并即部署，强调 CI 自动化。

提交信息规范

推荐使用 Conventional Commits 格式：

<type>(<scope>): <subject>

<body>

<footer>

常见 type：

type 说明
feat 新功能
fix 修复缺陷
docs 文档变更
refactor 重构（不改变功能）
test 测试相关
chore 构建/工具变更

示例：

feat(auth): 添加 OAuth2 登录支持

集成 Google 和 GitHub OAuth2 登录，
用户可选择第三方账号登录。

常用协作命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 同步远程分支并清理已删除的远程分支引用
git fetch --prune

# 交互式 rebase 整理提交历史
git rebase -i origin/develop

# cherry-pick 挑选特定提交到当前分支
git cherry-pick <commit-hash>

# 查看分支差异
git log --left-right --graph --cherry-pick --oneline main...feature/xxx

冲突处理原则

  1. 先理解冲突双方的意图，不要盲目选择一方。
  2. 小步提交、频繁合并 develop，减少冲突范围。
  3. 冲突解决后务必本地测试再推送。
  4. 复杂冲突建议结对解决，避免遗漏逻辑。

小结

好的工作流不是越复杂越好，而是匹配团队规模和发布节奏。后续会记录 Git Hooks 自动化检查与 Monorepo 管理的实践经验。