115 lines
6.8 KiB
Markdown
115 lines
6.8 KiB
Markdown
|
||
|
||
<div align=center><font size=5>众望通科技 研发中心</font></div>
|
||
<div align=center><font size=6>Git分支与版本发布管理规范</font></div>
|
||
|
||
> <div><font>拟稿：周志尧</font></div>
|
||
> <div><font>版本号： 1.0.0 </font></div>
|
||
> <div><font>发布时间：2020.10.06 </font></div>
|
||
[TOC]
|
||
|
||
## GIT分支管理
|
||
|
||
### 流程管理概述
|
||
|
||
Git代码管理的流程和规范参考 `Git Flow` 进行设计，详细可以阅读 Vincent Driessen [A Successful Git Branching Model](http://nvie.com/posts/a-successful-git-branching-model/) 。
|
||
|
||
### Master分支
|
||
|
||
master 分支始终代表生产环境的状态，不能直接在上面提交代码。Master分支上的Commit应该Tag，存储正式发布的历史。
|
||
|
||
|
||
|
||
### Develop分支
|
||
|
||
develop 分支作为功能的集成分支，包含所有的代码提交记录。develop 分支代表针对下一版本的最新交付的代码。开发人员从 develop 分支创建新分支，并开发新功能。功能开发完毕后，将对其进行测试，与 develop 分支合并，在合并了其他功能分支的情况下使用 develop 分支的代码进行测试，然后与 master 分支合并。
|
||
|
||
|
||
|
||
### Feature分支
|
||
每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。以develop分支作为父分支，当功能完成时，合并回develop分支，不能直接合并到master分支。
|
||
|
||
|
||
|
||
### Release分支
|
||
|
||
|
||
|
||
分支名 release-*
|
||
|
||
Release分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)
|
||
|
||
发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。
|
||
|
||
一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上fork一个发布分支。 新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。 另外，这些从新建发布分支以来的做的修改要合并回develop分支。
|
||
使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能。 这也打造定义良好的开发阶段（比如，可以很轻松地说，『这周我们要做准备发布版本4.0』，并且在仓库的目录结构中可以实际看到）。
|
||
|
||
* 常用的分支约定：
|
||
用于新建发布分支的分支: develop
|
||
用于合并的分支: master
|
||
分支命名: release-*
|
||
|
||
### Hotfix分支
|
||
|
||
分支名 hotfix-*
|
||
|
||
维护分支或说是热修复（hotfix）分支用于生成快速给产品发布版本（production releases）打补丁，这是唯一可以直接从master分支fork出来的分支。 修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。
|
||
为Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。 你可以把维护分支想成是一个直接在master分支上处理的临时发布
|
||
|
||
hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag
|
||
|
||
|
||
|
||
|
||
|
||
## feature功能分支管理
|
||
|
||
1. **功能划分：**开发负责人对开发需求进行模块划分、工作任务分解，将相对独立的开发功能分配给相应的开发人员，可多个开发协同开发一个功能；
|
||
2. **分支创建：**开发负责人（或开发人员）给相应的开发功能分支命名，可以按功能命名，也可以按照开发人员的姓名命名，如：feature-login；从develop分支拉取创建该分支；# 创建功能分支：git checkout -b feature-login develop
|
||
3. **功能开发**：开发人员在相应的feature分支进行功能开发，每天早晚更新提交feature分支代码；
|
||
4. **分支合并：**开发人员完成功能开发和单元测试后，提交代码后，提交分支合并请求，由项目开发负责人或者Git管理员将相应的feature分支合并到develop分支，合并冲突协同开发人员一起解决；# 开发完成后，合并到develop分支：①git checkout develop ②git merge --no-ff feature-login
|
||
5. **分支删除：**feature分支代码合并回develop之后，将feature分支删除（谁创建谁删除）。# 最后删除分支: git branch -d feature-login
|
||
|
||
## release预发布分支管理
|
||
|
||
1. **功能划分：**开发负责人对开发需求进行模块划分、工作任务分解，将相对独立的开发功能分配给相应的开发人员，可多个开发协同开发一个功能；
|
||
|
||
2. **分支创建：**开发负责人（或开发人员）给相应的开发功能分支命名，可以按功能命名，也可以按照开发人员的姓名命名，如：feature-login；从develop分支拉取创建该分支；# 创建功能分支：git checkout -b feature-login develop
|
||
|
||
3. **功能开发**：开发人员在相应的feature分支进行功能开发，每天早晚更新提交feature分支代码；
|
||
|
||
4. **分支合并：**开发人员完成功能开发和单元测试后，提交代码后，提交分支合并请求，由项目开发负责人或者Git管理员将相应的feature分支合并到develop分支，合并冲突协同开发人员一起解决；# 开发完成后，合并到develop分支：①git checkout develop ②git merge --no-ff feature-login
|
||
|
||
5. **分支删除：**feature分支代码合并回develop之后，将feature分支删除（谁创建谁删除）。# 最后删除分支: git branch -d feature-login
|
||
|
||
|
||
|
||
## 版本发布流程设计
|
||
|
||
（工作流发布图）
|
||
|
||
|
||
|
||
|
||
|
||
## 补丁规范
|
||
|
||
### 补丁文件结构
|
||
|
||
* 工程文件，目录结构遵循约定，与部署环境一致
|
||
|
||
* auth文件，补丁的授权信息
|
||
|
||
* version.info文件，补丁的版本信息
|
||
|
||
* README.txt文件，补丁的描述信息
|
||
|
||
### 版本号说明
|
||
|
||
*
|
||
|
||
|
||
### 邮件发布规范
|
||
|
||
|