GIT分支开发规范
来源:互联网 发布:p2p网络金融平台 编辑:程序博客网 时间:2024/05/19 04:06
最稳定的代码放在 master 分支上(相当于 SVN 的 trunk 分支),我们不要直接在 master 分支上提交代码,只能在该分支上进行代码合并操作,例如将其它分支的代码合并到 master 分支上。
我们日常开发中的代码需要从 master 分支拉一条 develop 分支出来,该分支所有人都能访问,但一般情况下,我们也不会直接在该分支上提交代码,代码同样是从其它分支合并到 develop 分支上去。
当我们需要开发某个特性时,需要从 develop 分支拉出一条 feature 分支,例如 feature-1 与 feature-2,在这些分支上并行地开发具体特性。
当特性开发完毕后,我们决定需要发布某个版本了,此时需要从 develop 分支上拉出一条 release 分支,例如 release-1.0.0,并将需要发布的特性从相关 feature 分支一同合并到 release 分支上,随后将针对 release 分支部署测试环境,测试工程师在该分支上做功能测试,开发工程师在该分支上修改 bug。
待测试工程师无法找到任何 bug 时,我们可将该 release 分支部署到预发环境,再次验证以后,均无任何 bug,此时可将 release 分支部署到生产环境。
待上线完成后,将 release 分支上的代码同时合并到 develop 分支与 master 分支,并在 master 分支上打一个 tag,例如 v1.0.0。
当生产环境发现 bug 时,我们需要从对应的 tag 上(例如 v1.0.0)拉出一条 hotfix 分支(例如 hotfix-1.0.1),并在该分支上做 bug 修复。待 bug 完全修复后,需将 hotfix 分支上的代码同时合并到 develop 分支与 master 分支。
对于版本号规范:
格式为:x.y.z,其中,x 用于有重大重构时才会升级,y 用于有新的特性发布时才会升级,z 用于修改了某个 bug 后才会升级。
GIT提交规范
使用GIT管理代码应该遵循以下规范:
- 上传内容:保证GIT上保存的是“干净”的代码,不得有编译后再次生成的代码,如Java字节码文件和JSP生成文件,也不能有IDE生成文件;
- 上传注释:必须加简要的注释,注释的内容应包含开发的模块名称以及功能描述;
功能提交:[模块名称]功能描述,如:[用户模块]用户列表增加手机号字段显示;Bug Fix:[模块名称]Bug-编号:Bug描述,如:[用户模块]Bug-1203:用户创建保存失败已修复;
- 上传质量:提交和合并到分支上的代码尽量保证是自己测试通过的代码,以免影响别的项目/同事;
- GIT分支开发规范
- [开发规范] Git分支使用规范
- Git各开发分支管理规范
- 项目开发中git分支规范
- Git分支使用规范
- Git分支管理规范
- git 开发规范1--在工作分支上开发代码然后合并到主分支
- git 开发分支模型
- Git分支开发图解
- git branch分支开发
- git的分支开发
- Git分支开发模式
- git分支开发流程
- Git分支开发策略
- git 开发分支图解
- Git分支管理规范和解析
- git上的分支命名规范
- git 分支管理,分支中进行开发
- FastJson Jackson Gson使用教程
- 排序算法--shel来排序
- linux的mount(挂载)命令详解
- QT智能家居界面qss渲染
- IMSI与MSISDN
- GIT分支开发规范
- 消息队列
- python中sort的常用方法
- java中的分布式应用(二)之各类中间件中用到的算法
- Android ToggleButton:状态切换的Button
- Servlet 读取表单数据
- hadoop报错report: Call From xxx to xxx failed on connect
- c# 打开文件对话框
- 分布式文件系统FastDFS设计原理