团队开发规范培训（代码管理篇）

  团队开发工作中，最重要的一个环节就是对代码的版本管理了。代码是软件开发公司的核心资产，所有的一切业务开展都是围绕着代码展开的，在团队协作中，就需要一个统一的代码管理规范来保证开发人员的工作流程可以高效、正常的进行下去

分支结构

  代码库的分支，统一划分为master(生产)、pre_production(准生产)、develop（测试）、feature（特性）、release（发布）、test（测试，可选）等多个分支，每个分支的作用和应用场景会在下方逐一介绍。

• master，该分支是代码库的主分支，所有按照项目进度规划并且通过了相关测试的代码，最终都会汇聚到该分支下面，并且生产服务器上所使用的代码也是该分支内的。该分支只接受由release分支单向合并过来代码，不接受任何人单独对该分支的修改，一般会将该分支设置为保护分支，避免代码被污染。同时当我们每次给master合并了代码后，其余每个正在开发的feature分支都应该将master分支合并至自己的分支中，保证代码最新。
• pre_production，该分支是用于每次正式上线前部署于准生产服务器的代码分支，只有每次在该分支合并的代码通过了测试，才可以最终合并至master分支内。该分支只接受由release分支单向合并过来的代码，且只能通过pr的方式来提交代码合并。
• develop，该分支是部署于线上测试服务器的代码分支，每个团队内的开发人员都可以随时、任意的将正在开发的代码合并至该分支内，这样可方便开发人员快速的使用线上服务器进行功能测试；该分支同样只接受由每个人自己创建的feature分支单向合并。
• feature，该分支是开发人员在接手需求后，根据所需开发的内容从当前master创建的分支。一个feature只能对应一个需求，如果该需求有多个开发人员参与协同开发，最佳建议是大家在同一个feature分支上进行开发工作，这样可以避免后期代码合并时的冲突。
• release，该分支是按照项目进度推进，测试组通过对项目中转测试的需求进行测试环境的测试完毕后，指定上线时间和上线内容，团队负责人从当前master分支创建该release分支，所有相关需求的负责人将各自需求对应的分支代码开始逐步合并至该分支内，并在合并的过程中解决相应的代码冲突等问题（一般情况只要大家的feature分支都随时保持合并了最新的master分支，那么冲突的几率和影响都会最小）。当该分支准备就绪后，由团队负责人发起release分支pr至pre_production和master分支的请求。
• test，该分支时可选的，如果develop分支对应的测试环境因为受到开发人员频繁修改而导致无法让测试团队稳定测试时，可以添加该分支。所有转测的需求对应的分支都合并至该分之下，测试团队只需要针对该分支进行首次的测试环境测试即可。
• bugfix，该分支在上线出现问题是，需要紧急修复时可创建。通过从master分支创建该分支，开发人员在该分支上进行代码修复

命名规则

  目前有release、feature、bugfix等分支需要有不同的名称。制定命名规则的主要目的，是为了保证分支的可读性，让团队成员可以通过名称快速的了解该分支的相关信息。

• feature分支的命名规则是，年月日-姓名简写-需求id或内容描述，比如20220329-wrq-1008001，这个名称可以看出该分支的创建时间时2022年3月29日，分支的负责人是王阮强，分支对应的项目管理工具中的需求id时1008001。通过这些信息就可以快速的了解到负责人和需求信息，方便后续的代码评审或追溯。
• release分支的命名规则是，release-版本号-年月日，比如release-v1.0.3-20221228，这个名称可以看出该分支对应的版本号时v1.0.3，准备上线时间时2022年12月28日。
• bugfix分支的命名规则是，bugfix-年月日-缺陷id，比如bugfix-20221228-188002。

工作流程

  工作流程尽可能简单且数据单向流转，具体步骤如下。

1. 开发人员从master分支创建新的feature分支，按照命名规则进行分支命名，如20221228-wrq-10086
2. 持续进行编码，每日及时提交工作代码，及时解决冲突；当达到可转测条件时，将自己的20221228-wrq-10086分支合并至develop分支内
3. 测试人员测试通过后，制定上线计划，项目负责人从master分支创建新的release分支，按照命名规则进行分支命名，如release-v1.0-20221228
4. 所有上线计划内的需求对应的负责人，将各自的feature分支合并至release-v1.0-20221228分支内
5. 相关代码合并完成后，项目负责人提起pr请求，将release-v1.0-20221228分别pr至pre_production和master
6. 评审人评审pr请求通过后，合并代码通过，此时pre_production更新，测试组可以进行准生产环境的测试
7. 准生产环境若测试有问题，相应的开发人员可以通过重复4-6的步骤，提交最新的代码
8. 准生产环境测试通过，评审人可以通过release-v1.0-20221228合并入master的请求，并对master打版本tag
9. 上线后测试组再次进行相关测试，如果此时发现问题，则从master最新代码创建新的bugfix分支，然后按照feature的上线流程走一遍（即2-8步骤）

附图：

  以上，就是代码管理相关规范的介绍。