GitFlow

最新推荐文章于 2023-06-17 19:54:05 发布

WSYW126

最新推荐文章于 2023-06-17 19:54:05 发布

阅读量650

点赞数

分类专栏： Git 文章标签： git 流程

本文链接：https://blog.csdn.net/WSYW126/article/details/55001367

版权

Git 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

Git

Git工具

版本控制工具，管理代码，方便追溯和协作开发。

安装：

brew intall git
git config --global user.name 'Git用户名'
git config --global user.email '账号邮箱'

克隆项目：

git clone 地址

基本使用：

git add xxx
git commit -m 'xxx'

查看状态和日志：

git status
git log

管理分支：

git checkout -b 新分支
git branch 查看分支
git chekcout 切换分支名次

远程分支：

git remote add 名称 地址
git remote -v
git fetch
git pull
git push

分支合并：

git merge
git rebase

GitFlow

Git Flow是基于GIT的开发流程规范，能够通过创建有分别的分支进行管理开发，有效的进行开发合作的工具。

分支概述

这里结合下图，对博文内容中的分支做一个概述性的说明：

gitFlow

如图所示,一个项目需要被分成master、develop、feature、release、hotfix五个分支。
根据类别可以分为主要分支和辅助分支两个类别：

主要分支：master、develop
辅助分支：feature、release、hotfix

主要分支

主分支（master）

master是git创建项目后默认在orign中的，他的头(HEAD)永远是produciton-ready的状态。也是当每个项目发布的最终版本的分支。

开发分支（develop）

develop分支是所有代码头是记录下一个发布版本的最新更新的分支。
当develop分支的代码已经可以被发布的时候，他将会被合并到主分支上并打上发布标签。

辅助分支

辅助分支是帮助团队成员进行协同开发使用的，它可以比较容易追踪特性，准备产品发布且快速修复产品中的问题，每个辅助分支有着不同的作用和界限。

特性分支（feature branches）

特性分支是用来开发下一个版本的新特性使用的分支，他在开发完成后合并到开发分支中。也就是说一般开发新功能都是要创建这个分支。

一般来说特性分支遵从下面规范：

来源如无特别情况是develop；
必须合并到develop上；
命名规则除了master、develop、release/、hotfix/ 以外的命名。

发布分支（release branches）

发布分支是为产品发布做准备的分支,他可以修复小的bug且准备发布元信息（版本号码、创建日期等）。也就是发布到master前的最后一步准备。

一般来说发布分支遵从下面规范：

来源如无特别情况是develop；
必须合并到develop和master上；
命名规则为release/*的形式。

修复分支（hotfix branches）

修复分支主要是突发情况下对发布产品进行版本BUG修复的分支。如果遇到重大BUG，需要立即创建分支进行修复合并。

一般来说修复分支遵从下面规范：

来源如无特别情况是master；
必须合并到develop和master上；
命名规则为hotfix/*的形式。

注：辅助分支都在自己的本地分支进行开发。

Github

项目组织上利用Github或者Gitlab中milestone、label及issue来组织整个项目。

开发组织元素

版本号

Whiterun的版本号用三位的命名，例如“v1.1.1”，其中：

前两位数为主版本号及发布的版本；
最后一位数为内部开发的版本，在为milestone组织提供依据。

Label

目前根据需求分为五种Label，之后可能会根据需求进行修改：

分支合并：当合并到develop分支时，进行添加；
功能改进：当开发需求在原先基础上的拓展，进行添加；
版本发布：只有当develop合并到master进行发布时添加；
特性添加：当开发需求是添加新的功能时，进行添加；
bug修复：当开发需求是修复原先的Bug时，进行添加。

开发流程

当收集了一定的需求后，建立milestone，以版本来命名milestone，说明里写入主要内容，并确立开发截至时间，通常一周；
根据需求建立各自的issue，issue命名根据需求是技术、业务以及bug等在开头用[]来注明，issue里需要写出具体的需求内容以及检查点，为issue设立label、对应的milestone以及开发者；
根据情况构建特性(features)、hotfixes等分支进行开发，提交的代码需要进行测试且构建其文档，提交commit里以Fix #issue号: 提交内容的格式书写；
PR的合并需要基于develop分支，合并的代码需要进行CodeReview，完成后可以进行合并；
完成每个milestone后，将develop合并到master上，在PR内容里写上本次迭代的全部issue内容号，完成迭代。

PR

检查列表

对每个issue，提交的PR需要添加CheckList来说明PR中的点，最好勾选其中的完成项目，保证PR的考虑完整。

PR CheckList模版如下：

描述: xxxxxx

检查项:
- [ ] 修改models层
 - [ ] 修改查询语句
 - [ ] 创建新表
  - [ ] 已提交建表SQL到DBA审核
  - [ ] 已提交查询和写入SQL到DBA审核
  - [ ] 已评估读写频次

- [ ] 新增/修改业务逻辑
 - [ ] 已通知受影响方
  - [ ] 业务方1
  - [ ] 业务方2
 - [ ] 新增/变更的功能点列表
  - [ ] 功能点1
   - [ ] 已测试
  - [ ] 功能点2
   - [ ] 已测试

- [ ] 上线方案
 - [ ] 确定预期上线时间
 - [ ] 上线时间已通知运维
 - [ ] 是否特别需要监控
  - [ ] 已通知监控
 - [ ] 是否需要添加新配置项
  - [ ] 已通知运维