基于GIT如何共建公共项目

1. 维护范围

1.1 项目组

确定好项目组的主负责人

2. 分支管理

2.1 分支命名

主干分支：master，稳定主干，只合并测试完备的develop分支代码，或fix分支代码
主干开发分支：develop, 日常开发不稳定主干，常用于需求开发分支合并
开发分支：feature_#XXX，用于核心需求开发
个人分支：建议命名someone/task_#XXX

2.2 分支权限

每个仓库应由管理员参照下方规则设置严格的权限，设置路径：设置-分支权限-新建分支权限

分支	身份	push	delete	PR merge
开发分支	管理员	√	√	√
develop	管理员	√	√	√
master	管理员	✕	✕	√

分支	身份	push	delete	PR merge
开发分支	非管理员	√	√	√
develop	非管理员	✕	✕	√
master	非管理员	✕	✕	√

2.3 分支合并与删除

每个版本发布后，仓库负责人或管理员应及时将develop分支合并至 master 主干，以保证项目的稳定性。
代码合并完成，开发分支或个人分支如无进一步的开发任务需要删除，避免过多分支留存。
废弃分支将由管理员进行定期清理，以保证分支的干净、有序，一般建议至多保留 5 个分支。

3. Code Review

3.1 原则

1. 杜绝未经 CR 的代码合并上线
2. 杜绝代码带冲突合并
3. 杜绝未格式化的代码合并
4. 提交 PR 的代码须先通过 eslint 校验且无错误
5. 提交 PR 的代码须经过自测
6. 保证 CR 的时效性，在 1 ～ 2 天处理完成，由 CR 发起人跟进并督促合并

3.2 提交PR

1. PR 标题应简要概括本地 PR 的主要功能点、修改点
2. PR 描述应详细列举本地 PR 的所有功能点、修改点及其它有必要的信息（设计理念、bug 描述等如有）
3. PR 描述应按照 commit 类别进行分类展示，分类信息如下：

• feat：新功能（feature）
• fix：修补 bug
• docs：文档（documentation）
• style： 格式（不影响代码运行的变动）
• refactor：重构（即不是新增功能，也不是修改 bug 的代码变动）
• test：增加测试
• chore：构建过程或辅助工具的变动
• build: 构建
• ci: 持续集成
• perf: 优化
• revert: 代码回滚

3.3 PR审核设置

每个仓库应由管理员设置默认审核人，默认审核人应包括仓库负责人或管理员，不少于1人，评审规则建议为协同评审，设置路径：设置-评审设置。

4. 版本发布管理

4.1 版本发布负责人

版本发布负责人为仓库负责人或管理员，发布时应遵守下方发布规则，非管理员请勿擅自发布。
版本发布后，负责人应通过各种渠道，包括邮件、快乐平安群、文档等形式通知到应知人员。

4.2 版本管理

npm 的版本号需严格按照语义化版本规范来进行设置，保证新版本的发布不会对在使用中的项目产生影响。

摘录信息：

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

主版本号：当你做了不兼容的 API 修改，如 1.x -->  2.x
次版本号：当你做了向下兼容的功能性新增，如 1.3 ---> 1.4
修订号：当你做了向下兼容的问题修正，如 1.3.1 ---> 1.3.2
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸，如 1.0.0-beta 或 1.0.0-rc.1

先行版本的区别：
alpha 版——内部测试版，常用于开发阶段版本测试使用
beta 版——公开测试版，常用于对外部团队、公司开放使用
rc 版——候选版本，常用于进入准发布状态的版本

4.3 发布管理

对于正式版本，发布时需指定npm源还是团队私有源，如下所示：

// 官方源
npm publish --registry=https://registry.npmjs.org

4.4 ChangeLog

ChangeLog应详细记录正式版本的发布内容，描述发布内容可能产生的影响

4.5 Tag

版本发布后，应由版本发布负责人在平台或git上对已发布的版本进行标识，以识别特定的版本，如 v0.1.0、v1.0.0 等，标记该版本的源代码，并提供版本发布信息，用于记录与回溯。