git合作规范

第一种方式:
develop 开发分支：开发人员每天都需要拉取/提交最新代码的分支
test 测试分支：开发人员开发完并自测通过后，发布到测试环境的分支
release 预发布分支：测试环境测试通过后，将测试分支的代码发布到预发环境的分支（这个得看公司支不支持预发环境，没有的话就可以不采用这条分支）
master 线上分支：预发环境测试通过后，运营/测试会将此分支代码发布到线上环境
hotfix 分支：在 master 发现新的 bug 时，需要创建一个 hotfix，完成后，合并到 master 和 develop 分支

大致流程
开发人员每天都需要拉取、提交最新的代码到 develop 分支
开发完毕后，开始 集成测试，测试无误后提交到 test 分支，并发布到测试环境，交由测试人员测试
测试环境通过后，发布到 release 分支上，进行预发布环境测试
预发环境通过后，发布到 master 分支上并打上标签 tag
如果线上分支出现 bug，这时开发者应该基于预发布（没有预发布环境就用 master 分支），新建一个 bug 分支用来临时解决 bug，处理完成后申请合并到预发布分支（好处是不会影响正在开发中的功能）

第二种方式:
工作流程:

核心思想：feature分支需要单独合并到dev、test、release分支，而不是传统的从dev合并到test，再顺着test合并到release。
优点：单独合并保证各个功能分支上线的自由度，各个feature分支测试完可以随时合并到release发布上线，适用于我们当前某些功能需要紧急上线，某些功能又暂缓上线的情况。
缺点：由于需要多次单独合并，意味着同一个冲突需要解决多次。如，feature分支合并到dev分支时解决一次冲突，然后feature分支合并到test分支时也需要解决一次冲突，最后feature分支合并到release分支时还再要解决一次冲突。所以解决冲突时务必多加注意

1.1 新功能开发
基于release分支创建新功能分支，分支命名为【feature_4位日期_功能简述】，并将service层包版本号改为【1.0.0-姓名拼音-SNAPSHOT】，deploy到maven仓库，再将web层中引用的service包版本号改为此版本号
注意，这个是本地开发环境的包版本号，每个人都是固定的，不需要升版本号。

1.2 合并到开发分支
feature分支功能开发完成，提交代码，切换至dev分支，拉取dev分支最新代码，合并feature分支进dev分支，提示pom文件冲突时，使用dev分支的包版本号，即【1.0.0-SNAPSHOT】，解决完冲突，推送代码，deploy一次service包，即可到paas平台构建开发环境，与前端进行联调。
注意，dev分支包版本号保持为【1.0.0-SNAPSHOT】即可，不需要升版本号。

1.3 合并到测试分支
切换至test分支，拉取test分支最新代码，合并feature分支进test分支，提示pom文件冲突时，将包版本号升级，版本号规范请参照开发规范-二方库依赖。解决完冲突，推送代码，deploy一次service包，即可到paas平台构建测试环境，提测。
注意，test分支需要升版本号，例如：原版本号为【1.0.0-alpha】，可升级为【1.0.1-alpha】。

1.4 合并到正式分支
切换至release分支，拉取release分支最新代码，合并feature分支进release分支，提示pom文件冲突时，将包版本号升级，版本号规范请参照开发规范-二方库依赖。解决完冲突，推送代码，deploy一次service包，即可到paas平台构建正式环境，上线。
注意，release分支需要升版本号，例如：原版本号为【1.0.0-release】，可升级为【1.0.1-release】。

1.5 紧急修复正式bug
基于release分支创建热修复分支，分支命名为【hotfix_4位日期_修复简述】，其余操作步骤同新功能分支一致，hotfix分支其实和feature分支是完全一样的。
核心思想：feature分支需要单独合并到dev、test、release分支，而不是传统的从dev合并到test，再顺着test合并到release。
优点：单独合并保证各个功能分支上线的自由度，各个feature分支测试完可以随时合并到release发布上线，适用于我们当前某些功能需要紧急上线，某些功能又暂缓上线的情况。
缺点：由于需要多次单独合并，意味着同一个冲突需要解决多次。如，feature分支合并到dev分支时解决一次冲突，然后feature分支合并到test分支时也需要解决一次冲突，最后feature分支合并到release分支时还再要解决一次冲突。所以解决冲突时务必多加注意。

1.6 新功能开发
基于release分支创建新功能分支，分支命名为【feature_4位日期_功能简述】，并将service层包版本号改为【1.0.0-姓名拼音-SNAPSHOT】，deploy到maven仓库，再将web层中引用的service包版本号改为此版本号
注意，这个是本地开发环境的包版本号，每个人都是固定的，不需要升版本号。

1.7 合并到开发分支
feature分支功能开发完成，提交代码，切换至dev分支，拉取dev分支最新代码，合并feature分支进dev分支，提示pom文件冲突时，使用dev分支的包版本号，即【1.0.0-SNAPSHOT】，解决完冲突，推送代码，deploy一次service包，即可到paas平台构建开发环境，与前端进行联调。
注意，dev分支包版本号保持为【1.0.0-SNAPSHOT】即可，不需要升版本号。

1.8 合并到测试分支
切换至test分支，拉取test分支最新代码，合并feature分支进test分支，提示pom文件冲突时，将包版本号升级，版本号规范请参照开发规范-二方库依赖。解决完冲突，推送代码，deploy一次service包，即可到paas平台构建测试环境，提测。
注意，test分支需要升版本号，例如：原版本号为【1.0.0-alpha】，可升级为【1.0.1-alpha】。

1.9 合并到正式分支
切换至release分支，拉取release分支最新代码，合并feature分支进release分支，提示pom文件冲突时，将包版本号升级，版本号规范请参照开发规范-二方库依赖。解决完冲突，推送代码，deploy一次service包，即可到paas平台构建正式环境，上线。
注意，release分支需要升版本号，例如：原版本号为【1.0.0-release】，可升级为【1.0.1-release】。

2.1 紧急修复正式bug
基于release分支创建热修复分支，分支命名为【hotfix_4位日期_修复简述】，其余操作步骤同新功能分支一致，hotfix分支其实和feature分支是完全一样的。

2.2 git 提交日志规范
feat：新功能（feature）
fix：修补bug
docs：文档修改
style： 不影响代码含义的修改(例如：white-space; 格式化等)
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
perf: 提升性能的修改
test：增加或修改测试
chore：构建流程或辅助工具的变动