前言
为了提高团队协作效率，基于 git-flow 规范制定了此代码管理操作规范，此规范主要从分支说明、 协作流程图解、常用约定和 git 工具等方面进行介绍。如果有疑问和建议欢迎讨论。
分支说明
master
- 主分支 , 产品的功能全部实现后 , 最终在master分支对外发布
- 该分支为只读唯一分支 , 只能从其他分支(release/hotfix)合并 , 不能在此分支修改
develop
- 主开发分支 , 基于master分支克隆
- 包含所有要发布到下一个release的代码 该分支为只读唯一分支 , 只能从其他分支合并
- feature功能分支完成 , 合并到develop(不推送) develop拉取release分支 , 提测
- release/hotfix 分支上线完毕 , 合并到develop并推送
feature
- 功能开发分支 , 基于develop分支克隆 , 主要用于新需求新功能的开发
- 功能开发完毕后合到develop分支(未正式上线之前不推送到远程中央仓库)
- feature分支可同时存在多个 , 用于团队中多个功能同时开发 , 属于临时分支 , 功能完成后可选删除
release
- 测试分支 , 基于feature分支合并到develop之后 , 从develop分支克隆
- 主要用于提交给测试人员进行功能测试 , 测试过程中发现的Bug在本分支进行修复 , 修复完成上线后合并到develop/master分支并推送(完成功能) , 打Tag
- 属于临时分支 , 功能上线后可选删除
hotfix
- 补丁分支 , 基于master分支克隆 , 主要用于对线上的版本进行BUG修复
- 修复完毕后合并到develop/master分支并推送 , 打Tag
- 属于临时分支 , 补丁修复上线后可选删除
协作流程图解
历史分支
功能分支
发布分支
维护分支
常用约定
代码提交约定
- 尽可能说明本次提交内容
分支命名约定
- 主分支 master 和 develop 名称不变
- 其他分支采用 分支名称/英文简称-处理人-日期
feature/wechatMiniProgramPay-zhongjian-20190710 /为文件夹形式，当分支太多的时候会很乱，文件夹的形式能很好的防止这种情况
tag 命名约定
- 只有当 release 分支合并至 master 分支上时才需要打 tag
- A 一般以 x.y.z 方式命名，例如
0.1.0，详细说明可以参考 语义化版本 2.0.0 - B 也可以直接使用分支名称作为 tag。
个人见解 ，x.y.z方式适合客户端作为版本号发布，但是对于服务端来说版本号的概念比较弱。个人喜欢 B 方式打标签。
管理工具 SourceTree
- 支持 Windows 和 Mac OS X
- 免费
- 用户图形界面对初学者友好
- 支持 git-flow
- 使用 https 协议时能保存密码
There are no comments on this post.