GIT分支开发模型
-
最稳定的代码放在
master分支上（相当于 SVN 的 trunk 分支），我们不要直接在master分支上提交代码，只能在该分支上进行代码合并操作，例如将其它分支的代码合并到master分支上。 -
我们日常开发中的 代码需要从
master分支拉一条develop分支出来，该分支所有人都能访问，但一般情况下，我们也不会直接在该分支上提交代码，代码同样是从其它分支合并到develop分支上去。 -
当我们需要开发某个特性时，需要 从
develop分支拉出一条feature分支，例如feature-name1与feature-name2，在这些分支上并行地开发具体特性。 -
当特性开发完毕后，我们决定需要发布某个版本了，此时需要从
develop分支上拉出一条qa分支，例如qa-name1-name2，并将需要发布的特性从相关feature分支一同合并到qa分支上，随后将针对qa分支部署测试环境，测试工程师在该分支上做功能测试，开发工程师在该分支上修改 bug。 -
待测试工程师无法找到任何 bug 时，我们可继续从
master分支拉出一条release分支，此时release的版本号必须根据master的tag版本号来递增，递增规则参见下面版本号规范，例如release1.0.0，并将qa-name1-name2分支合并到release1.0.0，并部署到预发环境，再次验证以后，均无任何 bug，此时可将release分支部署到生产环境。 -
待上线完成后，将
release分支上的代码同时合并到develop分支与master分支，并在master分支上打一个tag，例如v1.0.0。 -
当生产环境发现 bug 时，我们需要从对应的
tag上（例如v1.0.0）拉出一条hotfix分支（例如hotfix1.0.1），并在该分支上做 bug 修复。待 bug 完全修复后，需将hotfix分支上的代码同时合并到develop分支与master分支。最后，在master分支打tag（例如v1.0.1）。
对于版本号规范：
格式为：x.y.z，其中，x 用于有重大重构时才会升级，y 用于有新的特性发布时才会升级，z 用于修改了某个 bug 后才会升级。
使用GIT管理代码应该遵循以下规范：
- 上传内容：
保证GIT上保存的是“干净”的代码，不得有编译后再次生成的代码，如Java字节码文件和JSP生成文件，也不能有IDE生成文件； - 上传注释：
必须加简要的注释，注释的内容应包含开发的模块名称以及功能描述；功能提交：[模块名称]功能描述，如：[用户模块]用户列表增加手机号字段显示；
Bug Fix：[模块名称]Bug-编号：Bug描述，如：[用户模块]Bug-1203：用户创建保存失败已修复； - 上传质量：
提交和合并到分支上的代码尽量保证是自己测试通过的代码，以免影响别的项目/同事；