GitFlow-工作流程

目的

1. 减少冲突
2. 加强分支管理
3. 提高开发效率

GitFlow分支

核心分支：master、develop
临时分支：feature、release、hotfix
标签：tag

master

线上运行的代码
权限配置：

• 组长：合并（√），提交（√）
• 开发：合并（×），提交（×）

develop

存放所有功能最新最完整的代码
如：
开发新功能时，在develop分支上克隆
开发完成且测试通过，合并到develop分支

feature

开发新功能的分支，每一个功能一个分支
比如：07月份需求有1.1、1.2、1.3、1.4、1.5、1.6
开发A负责：1.1、1.2
开发B负责：1.3、1.4
开发C负责：1.5、1.6
feature命名规范：feature/版本号-需求名称或需求序列
如：feature/3.6.0-1.1，feature/3.6.0-migu

每次上线完后，版本号递增+1，如：3.6.0 -> 3.6.1
从develop分支克隆

# 1.开发创建本地feature分支
git checkout develop	 #如果切换不了，先执行git fetch origin --prune，再切换
git checkout -b feature/3.6.0-1.1 develop

# 2.开发在feature上开发功能，完成后提交代码，并推送feature分支到远程仓库
git status
git add .
git commit -m ‘某某某功能已开发完毕’
git push origin feature/3.6.0-1.1

# 3.测试构建feature分支，开始测试
# tip：jenkins也会改成gitflow模式，方便构建

# 4.如果有bug，开发继续在feature分支上修改提交
# tip：命令和②一样

# 5.测试继续测，如果仍不通过则继续3、4步骤，止到通过为止

# 6.测试反馈通过，开发将feature分支代码合并到develop
git checkout develop
git pull origin develop	# 先更新
git merge --no-ff feature/3.6.0-1.1 develop
git push origin develop

# 7.开发删除本地feature分支和远程feature分支
git branch -d feature/3.6.0-1.1
git push origin -d feature/3.6.0-1.1

同理，feature-3.6.0-1.2也是一样，开发B、开发C也都一样

补充：如果1.6功能延后或不是这版本上线的功能，都不要合并到develop，等到下个版本才合并，确保develop是当前版本上线的功能

release

预上线分支、回归测试分支、主要由组长操作
至少在上线1~3天前创建release分支，进行回归测试。

release命名规范：release/版本号，如release/3.6.0
从develop分支克隆

# 1.组长创建本地release分支，并推送到远程仓库
git checkout develop
git checkout -b release/3.6.0 develop
git push origin release/3.6.0

# 2.测试构建release分支，进行回归测试。回归测试验证功能的正常流程，确保代码完整或功能正常即可，不需要细粒度测试

# 3.如果有bug，测试告知对应的开发，开发直接在release分支上修改提交
git checkout release/3.6.0	# 如果切换不了，先执行git fetch origin --prune

# 4.测试反馈通过，组长将release的分支代码合并到master和develop
git checkout master
git merge --no-ff release/3.6.0 master
git push origin master

# 如果回归测试没有BUG，则不需要合并develop了
git checkout develop
git pull origin develop
git merge --no-ff release/3.6.0 develop
git push origin develop

# 5.组长删除本地release分支和远程release分支
git branch -d release/3.6.0
git push origin -d release/3.6.0

# 6.组长在master分支上构建，打包给运维上线

# 7.组长在master分支上打tag，tag命名：项目名-release-版本号
git checkout master
git tag -a release-3.6.0 master -m '需求版本'
git push origin release-3.6.0
git tag -l

hotfix

热修复上线版本的分支
hotfix命名规范：hotfix-版本号-需求名称或需求序列
如：hotfix-3.6.0-1.1

从master分支克隆

# 1.开发创建本地hotfix分支
git checkout master
git checkout -b hotfix/3.6.0-1.1 master

# 2.开发在hotfix上修改提交代码，并推送hotfix分支到远程仓库

# 3.测试构建hotfix分支，开始测试

# 4.测试反馈通过，开发将hotfix分支合并到develop，通知组长将hotfix分支合并到master

# 5.组长合并完后，开发删除本地hotfix分支和远程hotfix分支

# 6.组长在master分支上构建，打包给运维上线

# 7.组长删除之前上线的tag，重新在master上打tag，注释最好加上补丁说明，便于区分
git tag -d ccs-release-3.6.0
git push origin :refs/tags/ccs-release-3.6.0

git checkout master
git tag -a ccs-release-3.6.0 master -m '7月信控需求版本-补丁v1.0'
git push origin ccs-release-3.6.0
git tag -l

补充：Git-flow插件安装

参考博客：https://blog.youkuaiyun.com/wyc_cs/article/details/51458978