Git工作流简述

为了规范gerrit使用流程,减少代码协同过程中以及上线过程中的分支错误,团队内部特定制一下gerrit工作流。

gitflow

流程说明:

1. 分支说明:

master分支:主干分支,需要保持稳定,不允许直接提交代码进master
develop分支:开发分支,平时主要工作分支,测试完成的分支代码需要合并到develop分支
hotfix分支:从develop拉出的紧急bug修复分支
feature分支:功能开发分支,从develop拉出,用于日程功能修改、优化等
test分支:测试分支,从develop拉出,用于部署到测试服务器供QA测试使用
local分支:本地开发分支,与远程feature分支关联对应,本地开发完成,提交远程feature进行review

2. 分支间操作说明:

2.1 master分支原则上只有项目指定人才能操作,而且只能从develop上合并,操作流程大致如下,合并过程中如有冲突,正常解决冲突即可

git checkout master
git pull
git merge --no-ff develop
git push origin HEAD:refs/for/master

2.2 master分支合并了新代码后,需要打tag,tag格式为v[version]-[yyyyMMdd],如v1.0.0-20180615,同时需要注释要写清楚本次合并主要功能,操作如下

git checkout master
git tag -a v1.0.0-20180615   #这个步骤会提示提交注释说明
git push origin v1.0.0-20180615
git tag # 查看tag
git show v1.0.0-20180615  # 查看指定tag git show [tag-name]
# 如果tag需要修改,先删除原来到tag,给指定commit_id打上一个新打tag

2.3 feature分支,统一从web管理器创建,来源develop,创建完成本地后操作如下(如今web端创建分支feature_lyl_calendarList_0620)

git fetch # 这个命令会把远程新建到分支拉取到本地 origin/feature_lyl_calendarList_0620
git checkout feature_lyl_calendarList_0620 #直接创建一个本地分支,并与远程对应分支关联,注意名称要与远程到一样

#剩下的就是正常开发……
git push origin HEAD:refs/for/feature_lyl_calendarList_0620 #提交review

2.4 feature分支合并到test提交测试

git checkout test
git merge origin/feature_lyl_calendarList_0620  # 解决冲突如果有
git push origin HEAD:refs/for/test

2.5 测试通过后,确定要上线,需要把feature分支合并到develop中,合并前最好先同develop做一次rebase,尽量把冲突放到当前feature分支解决

git checkout feature_lyl_calendarList_0620
git rebase origin/develop
git checkout develop
git merge --no-ff origin/feature_lyl_calendarList_0620  # 解决冲突如果有
git push origin HEAD:refs/for/develop

# 上线时,专人把develop merge到master,参照步骤1

2.6 hotfix分支是紧急分支,临时从develop拉取

git fetch #获取在web端创建到分支hotfix_0620
git checkout hotfix_0620

# 修改代码,提交测试,这个时候直接部署hotfix_0620分支到测试服务器即可

git checkout develop
git pull --rebase
git merge --no-ff origin/hotfix_0620
git push origin HEAD:refs/for/develop

# 合并到master参考步骤1

参考文献
Gerrit Code Review for Git
Gerrit 代码审核服务器的工作流和原理
A successful Git branching model

猜你喜欢

转载自blog.csdn.net/zombres/article/details/80697698