2022Gitee 功能更新

CodeOwners

在做日常迭代交付时提交的 PR，指定组内成员进行代码评审，当代码变更涉及到某文件或目录 A 时，大多数情况下会指派固定的人员 B 进行代码评审。我们就可以称为 B 是组件 A 的 CodeOwner。简单来说，Codeowner 用来定义谁负责仓库中的特定文件或目录。

想要使用 CodeOwners 功能，需要在仓库中创建一个名为CODEOWNERS的文件，点此查看具体规则。

设置完成后，在提交 PR 后即可按照设定的规则，在修改某一文件或目录时，自动指派相应的负责人进行审查，无需再进行手动设置。

依赖包跳转

通常我们使用 npm/rpm/yarn 等包管理工具时，会自动生成一个描述文件（如使用 npm 就会生成package.json）。这个文件会描述这个包的所有相关信息，包括作者、简介、包依赖、构建等信息。

很多开发者在了解和学习开源项目时，经常会访问描述文件查看项目的依赖包，为了让开发者们更方便地直接访问这些依赖包，Gitee 推出了这个小功能，可以让开发者们直接点击即可前往依赖包地址。

在仓库的文件浏览页面中，可以直接点击访问的依赖包前方会有橙色标记，点击即可前往该组件的原始仓库。

Pull Request 草稿

Gitee 现已支持提交 PR 草稿的功能，当项目成员还没有完成开发时，可以在提交 PR 时选择创建 Pull Request 草稿。同时，使用 PR 草稿的功能也有助于让其他成员检查你的 Fork 以获得反馈，

以草稿形式提交的 PR 会在该 PR 的各个相关页面给予提示，并且该 PR 无法合并，当准备好进行代码审查时，可以取消 PR 的草稿状态，进行正常的代码审查与合并。

推送规则限制

在研发管理流程中，建立一定的共识已经成为业界的标准实践，建立共识的好处就是减少沟通成本，固化团队的一些行为方式，让团队更加专注于业务的开发而不必在研发过程中花费过多的精力，降低团队的认知负荷。

基于以上的一些考量，Gitee 推出了推送规则限制功能，帮助团队在提交规范化上更加精进，减少人工介入的成本，通过推送规则的配置，团队可以灵活的配置符合团队文化的一些硬性限制，比如提交信息的格式、提交邮箱以及单文件大小的限制等等。

功能介绍

推送规则设置能够限制仓库提交的的一些属性，使整个提交更加规范化，易于管理，目前推送规则设置包含以下几个维度：

指定是否只能推送自己的提交（提交邮箱必须与推送用户的注册邮箱保持一致）
指定提交邮箱的后缀（比如只允许企业邮箱的提交如 @gitee.com）
提交信息的正则验证（指定提交信息的格式，比如必须是 fix: #888 bug fixed）
限制单文件的大小（指定最大可提交的单文件大小，比如 5M）除此之外，还给出了特权用户的设置，可以配置仓库管理员是否受上述规则限制，覆盖一些特殊的使用场景。

1.邮箱规则配置

邮箱规则设置主要有两种：只能推送自己的提交以及指定提交邮箱的后缀规则。

限制提交的推送者

勾选了只能推送自己的提交将会开启这个限制，开启之后，用户所推送的提交只能是自己的提交，判定是否是自己的提交的方式是提取提交的邮箱，然后与推送者的注册邮箱进行比对，如果一致则认为是推送者自己的提交，反之则不是，将会被拒绝：

指定提交邮箱的后缀

在一些公司的研发管理流程中，规定提交者必须使用公司的邮箱进行提交，一方面是可以很好的进行提交信息的统一，与公司内部的系统进行统一标准化，方便进行度量统计；另一方面是可以在一定程度上声明所提交的代码是公司的资产。

勾选了只允许指定邮箱域名后缀的提交将会开启这个限制，开启之后，用户所推送的提交必须是以指定的邮箱后缀为结尾，实例中给出的配置就必须以@gitee.com为结尾，如zoker@gitee.com、admin@gitee.com等。如果用户使用了非指定后缀的邮箱进行了提交，在推送的时候将会被拒绝：