工作流程
1、每个sprint开始前从master拉出开发分支，分支类型选择feature；
2、以Story为单位从Master拉取开发分支，开发人员在开发分支完成开发后先内部合并代码然后merge到dev-merge分支，解决掉冲突后再从dev-merge合并到develop分支；
3、在develop分支完成集成测试并做desk check，一般会在一个sprint结束后从develop整体发一次SIT(VT)，也可能会单独将开发分支合并到SIT分批交付；
4、修改VT defect需要单独从SIT分支拉出代码，修改完成后需要先合到develop验证结果，验证通过后单独提交merge请求到sit分支；
5. 修改UAT defect需要单独从UAT分支拉出代码，修改完成后需要先合到develop验证结果，验证通过后单独提交merge请求到UAT分支；
6、每个sprint开发和desk check都结束后需要整体合一次代码到master并打tag，如果vt环境上个sprint测试能正常完成同时会整体合一次代码到SIT分支；
7、SIT上测试通过的代码（可能是一个sprint或多个sprint）可以统一从sit分支提交到uat分支做uat测试；
7、整个Release的代码都在UAT测试通过后，拉出release分支，同时合并代码到production分支；
8、production分支发布后打tag，如果发现线上问题此时也是从uat分支拉出代码，走uat的修复流程。
特殊说明：
1、Develop分支作为集成环境会包含多个spring正在集成或测试的所有功能代码，是一个不稳定分支
2、Master分支作为稳定分支，包含当前正在开发的sprint以前的所有代码
3、UAT实际上会有两个环境，一个是production问题修复环境，一个是下个release代码测试环境，具体代码拉出和提交流程都类似
git分支命名规范
1、开发分支从master拉出，按feature - 当前release(RX) - 当前sprint编号-story编号命名
2、sit defect分支从sit拉出 按feature/sit-defect编号命名
3、uat defect分支从uat拉出，按bugfix/uat-defect或bugfix/prd-defect编号命名
bugfix/UAT-PTPHDMSP-751(for uat defect)
bugfix/PRD-PTPHDMSP-751(for production defect)
代码合并注意事项
1、开发分支代码提交与合并
从master拉出的feature分支代码统一提交pull request 到dev-merge审核
如果代码有冲突需要在dev-merge分支解决冲突，禁止将dev-merge代码合入自己的开发分支
2、defect分支代码提交与合并
从sit/uat拉出的分支统一提交pull request 到dev-merge审核
如果代码有冲突需要在dev-merge分支解决冲突，禁止将dev-merge代码合入自己的defect分支
dev测试通过后将defect分支合到sit/uat分支
如何merge代码？
如果你当前有个本地分支feature/S5-PTPHDMSP-184完成了开发需要合并到develop-merge-branch
（1） 在bit bucket提交pull request做代码review
（2）如果此时产生冲突，先不要着急合代码，待review完后再合并代码
（3）合并流程为
#首次检出develop-merge-branch分支使用
git checkout -b dev-merge-branch origin/dev-merge-branch
#dev-merge-branch已经在本地checkout使用
git checkout develop-merge-branch
git pull
# 以下流程都一样
git merge feature/S5-PTPHDMSP-184
# 解决冲突(在本地)
git commit -am 'reslove confilct'
git push
