-
最稳定的代码放在 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:用户创建保存失败已修复;
- 上传质量:提交和合并到分支上的代码尽量保证是自己测试通过的代码,以免影响别的项目/同事;