Git工作流实战：Git Flow/GitHub Flow/Trunk Based Development完整指南

【免责声明：本文由AI辅助生成，内容仅供参考，不构成专业建议。】

Git工作流实战：Git Flow/GitHub Flow/Trunk Based Development完整指南

Git工作流是团队协作的基础。本文介绍主流的Git工作流，帮助团队选择最适合的协作模式。

Git基础回顾

工作区/暂存区/仓库：工作区是实际文件，暂存区是待提交区域，仓库是Git存储历史的地方。

分支操作：git branch创建分支，git checkout切换分支，git merge合并分支。

远程操作：git remote管理远程仓库，git push推送，git pull拉取合并。

rebase vs merge：merge保留完整历史，rebase线性历史，各有优劣。

Git Flow工作流

Git Flow是最成熟的分支管理模型。适合有固定发布周期的团队。

主分支：main/master，只读，存放正式发布版本。

开发分支：develop，开发分支，汇总特性分支。

特性分支：feature/*，从develop拉取，开发完成后合并回develop。

发布分支：release/*，从develop拉取，用于发布准备，修复最后问题后合并到main和develop。

热修复分支：hotfix/*，从main拉取，紧急修复后合并到main和develop。

GitHub Flow工作流

GitHub Flow是更简单的分支模型。适合持续部署的团队。

流程：main分支始终可部署。任何开发都从main拉取特性分支。完成后发起Pull Request。代码审查通过后合并到main并部署。

Pull Request：代码审查的工具，也是团队沟通的场所。Reviewer可以提意见，开发者可以讨论。

自动化：CI/CD自动化测试和部署。PR必须通过所有测试才能合并。

Trunk Based Development

Trunk Based Development（TBD）是更激进的实践。适合追求快速迭代的团队。

核心原则：所有开发者频繁向main（或trunk）提交代码。使用特性开关（Feature Toggle）控制未完成功能。

分支策略：很短的特性分支（最多1天），频繁集成到trunk。

特性开关：if (featureToggle.isEnabled(“new-feature”)) { // 新功能代码 } 部署后通过开关控制功能上线。

发布分支：从trunk拉取发布分支，但尽量从trunk直接部署。

分支命名规范

特性分支：feature/功能描述、feature/TICKET-123-描述。

修复分支：bugfix/TICKET-123-描述、fix/TICKET-123-描述。

发布分支：release/v1.0.0、release/2024-Q1。

热修复分支：hotfix/TICKET-123-描述。

Commit规范

Conventional Commits：feat：新功能、fix：修复bug、docs：文档更新、style：格式调整、refactor：重构、test：测试、chore：构建/工具。

Commit Message：type(scope): description。feat(auth): add OAuth login。

提交粒度：每个commit做一件事。原子化提交便于回滚和问题定位。

更多技术文章：https://blog.hanyucloud.com | 客服：400-880-3980