git开发流程 公司项目开发流程

1、分支介绍：

永久分支：
master：主分支。用于存放经过测试，完全稳定的代码。
dev：开发分支。一开始从master分离而来，用于存放基本稳定的代码。
testing：测试分支。从dev分离而来，用于生成测试产品和修改bug。
临时分支：

feature：特性分支。 从dev分支分离而来，用于开发项目功能。
hotfixes：紧急分支。当产品已经发布，发现紧急bug，创建hotfixes分支进行紧急修复，完成后合并到master和dev。
release：预发布分支。每次发布有一个分支。从testing分离而来，用于生成预发布产品和回归测试。

2、工作流程：

每个spring 和 项目创建不同的feature分支。
开发人员基于feature分支进行开发。
开发人员完成功能开发及单元测试后，提交pull request请求。
技术组长审核pull request并进行code review。 
技术组长进行拒绝或者合并到dev分支。
jenkins自动更新dev代码，自动进行sonar检测，自动构建，将成功或者是失败信息通过邮件反馈给开发人员和技术组长。
技术组长将dev合并到testing分支。
jenkins自动更新testing代码，自动构建并部署到测试环境，将成功或者是失败信息通过邮件反馈给开发人员和技术组长。
jenkins自动进行单元测试，集成测试，系统测试，生成测试报告。
测试人员在测试环境进行手动测试。发现bug及时反馈给开发人员。
开发人员在dev分支及时进行修复。
开发人员修复完成后，提交pull request请求合并到dev。
技术组长审核pull request并进行code review。 
技术组长进行拒绝或者合并到dev分支。
技术组长将dev合并到testing分支。
测试人员测试通过后，技术组长合并testing到新的release分支。

3. pull request格式要求
pull request的格式要求如下：
标题：【jira任务号】feature或bugfix分支名称
同一个任务、bug的所有pull request标题要一致。
说明：本次提交的一则说明，包括，但不限于：
本次合并涉及哪些端的pr
本次合并和是否有依赖于别的合并
本次合并是否涉及脚本审核
本次合并的功能说明

jenkins自动更新release代码，自动构建并部署到预发布环境，将成功或者是失败信息通过邮件反馈给开发人员和技术组长
jenkins自动进行单元测试，集成测试，系统测试，生成测试报告。
测试人员在预发布环境进行回归测试。
测试完成后，技术组长合并release分支到dev分支以及master 分支并在master 分支打上Tag标签。

运维负责人部署升级数据库
1.运维负责人拉生产环境新建实例执行SQL脚本，验证实例环境网络连接及访问正常、确认有效升级数据库，将成功或者是失败信息通过微信群QQ群等实时反馈给开发人员和技术组长。
2.技术组长和开发人员验证SQL脚本无误，以及新额数据库脚本可以兼容旧的程序代码无误，将成功或修正信息反馈运维负责人。
3.运维负责人执行升级生产环境数据库SQL脚本，验证生产环境网络连接及访问正常、确认有效升级数据库，将成功或者是失败信息通过微信群QQ群等实时反馈给开发人员和技术组长。

运维负责人拉取release分支，打包，并部署到生产环境，验证生产环境网络连接及访问正常、确认有效升级程序，将成功或者是失败信息通过微信群QQ群等实时反馈给开发人员和技术组长
测试人员在发布环境进行冒烟测试。
产品负责人在生产环境进行验证。
测试完成后，运维负责人发布版本发布信息。
技术组长合并release分支到dev分支以及master 分支并在master 分支打上Tag标签。

Git工作流指南：Gitflow工作流：http://blog.jobbole.com/76867/
Git工作流指南：Pull Request工作流：http://blog.jobbole.com/76854/