Git工作流简述

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

##流程说明：

####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

其他功能参考：

1. Rebase 用法小结