Git 分支命名规范与工作流程
git分支命名规范与工作流程
快速预览
| 分支 | 命名 | 说明 |
|---|---|---|
| 主分支 | master | 主分支，所有提供给用户使用的正式版本，都在这个主分支上发布 |
| 预发布分支 | release/v1.0.0 | 发布正式版本之前，最终确认的分支 |
| 开发主分支 | develop/v1.0.0 | 开发主分支，永远是功能最新最全的分支 |
| 功能开发分支 | feature/xxx | 新功能分支，某个功能点正在开发阶段 |
| 紧急bugfix分支 | hotfix/xxx | 修复线上代码的 bug |
详解
- master：主分支，永远是可用的、稳定的、可直接发布的版本，不能直接在该分支上开发
- release/v1.0.0 (bugfix)：预发布分支，预发布分支是从 develop 分支上面分出来的。【预发布环境，该分支修复bug，稳定后合并进 develop 和 master 分支】
- develop/v1.0.0：开发主分支，代码永远是最新，所有新功能以这个分支来创建自己的开发分支，该分支只做只合并操作，不能直接在该分支上开发。【测试环境，feature分支修复bug后，再合入】
- feature/xxx (bugfix)：功能开发分支，在 develop 上创建分支，以自己开发功能模块命名，开发完成或修复bug后合并到 develop 分支
- hotfix/xxx：紧急bug修改分支，项目上线之后可以会遇到一些环境问题需要紧急修复，在对应版本的release 分支上创建，流程跟 release 分支相似，修复完成后合并 release 分支，根据情况判断需不需要再合并到 develop 和 master 分支
Workflow Diagram
注意事项
- 一个分支尽量开发一个功能模块，不要多个功能模块在一个分支上开发。
- 开发过程中，如果组员A开发的功能依赖组员B正在开发的功能，可以待组员B开发好相关功能之后，组员A直接 pull 组员B的分支下来开发，不需要先将组员B的分支 merge 到 develop 分支。
- feature 分支在申请合并之前，最好是先 pull 一下 develop 主分支下来，看一下有没有冲突，如果有就先解决冲突后再申请合并。
