基于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 原则
- 杜绝未经 CR 的代码合并上线
- 杜绝代码带冲突合并
- 杜绝未格式化的代码合并
- 提交 PR 的代码须先通过 eslint 校验且无错误
- 提交 PR 的代码须经过自测
- 保证 CR 的时效性，在 1 ～ 2 天处理完成，由 CR 发起人跟进并督促合并
3.2 提交PR
- PR 标题应简要概括本地 PR 的主要功能点、修改点
- PR 描述应详细列举本地 PR 的所有功能点、修改点及其它有必要的信息（设计理念、bug 描述等如有）
- 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 等，标记该版本的源代码，并提供版本发布信息，用于记录与回溯。
