实际开发各个环境介绍
简化版 开发环境（dev)：开发环境是程序猿们专门用于开发的服务器，配置可以比较随意，为了开发调试方便，一般打开全部错误报告。 测试环境(test)：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。 生产环境（prod）：是值正式提供对外服务的，一般会关掉错误报告，打开错误日志。 三个环境也可以说是系统开发的三个阶段：开发->测试->上线，其中生产环境也就是通常说的真实环境。
全面版 dev（Development environment）：开发环境。用于开发者调试使用。 test：测试环境。 sit（System Integration Test）：系统集成测试。 uat（User Acceptance environment）：用户验收测试环境。生产环境下的软件测试者测试使用。预发布环境。 pre：灰度环境。灰度测试环境就是生产环境，生产数据，所影响的也是生产环境，只是范围比测试环境更广，更真实。其实就是小范围的生产环境。类似于游戏内测。 fat（Feature Acceptance Test environment）：功能验收测试环境。软件测试者测试使用。 prod（Production environment）：生产环境。正式线上环境。
分支作用及介绍
master(主分支)
存在一条主分支（master）。 所有用户可见的正式版本，都从master发布（也是用于部署生产环境的分支，确保master分支稳定性）。 主分支作为稳定的唯一代码库，不做任何开发使用。 master 分支一般由develop以及hotfix分支合并，任何时间都不能直接修改代码
develop(开发分支)
存在一条开发分支（develop）。这个分支维护了当前开发中代码的主线，始终保持代码新于master以及bug修复后的代码。 持续集成、最新隔夜版本的生成等都是基于这个分支。由于当前版本迭代较快，开发分支只提供拉取，不进行实际开发。一般开发的新功能时，feature分支都是基于develop分支下创建的
feature(功能分支)
临时性多个功能分支（feature）
开发新功能时，以develop为基础创建feature分支。
从develop拉取。开发feature完成，merge回develop。为了降低对其他feature的影响，一般在提测前merge回develop分支。
分支命名: feature/*开头的为特性分支， 命名规则: feature/user_module、 feature/order_module
hotfix(修补bug分支)
临时性多个bug修复分支（fixbug），用于修复线上问题。 从master拉取，修复并测试完成merge回master和develop。如果修复期间，有其他版本合并入master ，需要同步到fixbug版本，并进行测试。 分支命名: hotfix/*开头的为修复分支，它的命名规则与 feature 分支类似
release(预发布分支)
临时性多个预发布（测试）分支（release）
release 为预上线分支，发布提测阶段，会release分支代码为基准提测
用于QA测试。从develop拉取，测试完成merge回master和develop。如果测试期间，有其他版本合并入master，需要同步到release版本，并进行测试。
总结：dev包和rb包==功能测试包，最后都会合到master分支去发布上线生产环境。
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：构建流程或辅助工具的变动
相关经验
相关资讯
相关文档
