GIT分支开发模型规范

骑猪看日落 2022-04-13 08:23 289阅读 0赞

![Image 1][]

GIT分支开发模型

1.  **最稳定的代码放在 `master` 分支上（相当于 SVN 的 trunk 分支）**，我们不要直接在 `master` 分支上提交代码，**只能在该分支上进行代码合并操作**，例如将其它分支的代码合并到 `master` 分支上。
2.  我们日常开发中的 **代码需要从 `master` 分支拉一条 `develop` 分支出来，该分支所有人都能访问**，但一般情况下，我们也不会直接在该分支上提交代码，代码同样是从其它分支合并到 `develop` 分支上去。
3.  当我们需要开发某个特性时，需要 **从 `develop` 分支拉出一条 `feature` 分支**，例如 `feature-name1` 与 `feature-name2`，在这些分支上并行地开发具体特性。
4.  当特性开发完毕后，**我们决定需要发布某个版本了，此时需要从 `develop` 分支上拉出一条 `qa` 分支**，例如 `qa-name1-name2`，并将需要发布的特性从相关 `feature` 分支一同合并到 `qa` 分支上，随后将针对 `qa` 分支部署测试环境，**`测试工程师在该分支上做功能测试，开发工程师在该分支上修改 bug`**。
5.  **待测试工程师无法找到任何 bug 时**，我们可继续从 `master` 分支拉出一条 `release` 分支，**`此时release的版本号必须根据master的tag版本号来递增，递增规则参见下面版本号规范`**，例如 `release1.0.0`，并将`qa-name1-name2`分支合并到`release1.0.0`，并部署到预发环境，再次验证以后，均无任何 bug，**此时可将 `release` 分支部署到生产环境**。
6.  待上线完成后，**将 `release` 分支上的代码同时合并到 `develop` 分支与 `master` 分支，并在 `master` 分支上打一个 `tag`**，例如 `v1.0.0`。
7.  当生产环境发现 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管理代码应该遵循以下规范：**

1.  上传内容：**`保证GIT上保存的是“干净”的代码，不得有编译后再次生成的代码`**，如Java字节码文件和JSP生成文件，也不能有IDE生成文件；
2.  上传注释：**`必须加简要的注释，注释的内容应包含开发的模块名称以及功能描述`**；
    
    > 功能提交：**\[模块名称\]功能描述**，如：\[用户模块\]用户列表增加手机号字段显示；  
    > Bug Fix：**\[模块名称\]Bug-编号：Bug描述**，如：\[用户模块\]Bug-1203：用户创建保存失败已修复；
3.  上传质量：**`提交和合并到分支上的代码尽量保证是自己测试通过的代码`**，以免影响别的项目/同事；

[Image 1]: