Git 之五 - 深入理解 Git 工作流
Git 工作流概念
Git 工作流指在项目开发过程中使用 Git 的方式,包括集中式工作流、功能分支工作流、GitFlow 工作流、Forking 工作流、Pull Requests。
Git 工作流分类
集中式工作流
像 Subversion 一样,集中式工作流以中央仓库作为项目所有修改的单点实体。所有修改都提交到 Master 这个分支上,这种方式与 SVN 的主要区别就是开发人员有本地库,但 Git 很多特性并没有使用到。
功能分支工作流
功能分支工作流以集中式工作流为基础,不同的是为各个新功能分配一个专门的分支来开发。这样可以在把新功能集成到正式项目前,用 Pull Requests 的方式讨论变更。
Gitflow 工作流
Gitflow 工作流通过为功能开发、发布准备和维护设立了独立的分支,让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。
Forking 工作流
Forking 工作流是在 GitFlow 基础上,充分利用了 Git 在分支和克隆上的优势、Git 的 Fork 和 Pull Request 功能,实现代码审核的目的。可以安全可靠地管理大团队的开发者(developer),并能接受不信任贡献者(contributor)的提交。
Pull Requests
Pull Requests 是 Bitbucket 提供的让开发者更方便地进行协作的功能,提供了友好的 Web 界面可以在提议的修改合并到正式项目之前对修改进行讨论。
GitFlow 工作流中分支类型详解
- 主干分支(master)
- 主要负责管理正在运行的生产环境代码,永远保持与正在运行的生产环境完全一致。
- Bug 修复分支(hotfix)
- 主要负责管理生产环境下需要紧急修复的代码。从主干分支分出,修理完毕并测试上线后,并回主干分支。并回后,视情况可以删除该分支。
- 准生产分支(release)
- 较大的版本上线前,会从开发分支中分出准生产分支(预发布分支),进行最后阶段的集成测试。该版本上线后,会合并到主干分支。生产环境运行一段阶段较稳定后可以视情况删除。
- 开发分支(develop)
- 主要负责管理正在开发过程中的代码,一般情况下应该是最新的代码。
- 功能分支(feature)
- 为了不影响较短周期的开发工作,一般把中长期开发模块,会从开发分支中独立出来,开发完成后会合并到开发分支。
- 分支详细图解
Git 提交规范
feat
增加新功能fix
修复问题 / BUGstyle
代码风格相关无影响运行结果的perf
优化 / 性能提升refactor
重构revert
撤销修改test
测试相关docs
文档 / 注释build
对构建系统或者外部依赖项进行了修改chore
依赖更新 / 脚手架配置修改等workflow
工作流改进ci
持续集成types
类型定义文件更改wip
开发中