进入虎年的首个月，大家纷纷回归到正常的工作节奏中，Gitee 团队当然也没有闲着，为大家带来新年的第一波更新，一起来和马建仓看看这些超实用的新功能吧！

推送规则限制

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

基于以上的一些考量，Gitee 推出了推送规则限制功能，帮助团队在提交规范化上更加精进，减少人工介入的成本，通过推送规则的配置，团队可以灵活的配置符合团队文化的一些硬性限制。

目前推送规则设置包含以下几个维度：

1.指定是否只能推送自己的提交（提交邮箱必须与推送用户的注册邮箱保持一致）；

2.指定提交邮箱的后缀（比如只允许企业内部邮箱的提交，如@gitee.com）；

3.提交信息的正则验证（指定提交信息的格式，比如必须是fix: #888 bug fixed）；

4.限制单文件的大小（指定最大可提交的单文件大小，比如5M）。

关于推送规则限制的更多信息，可以前往 Gitee 帮助中心/更新日志 查看。

依赖包跳转

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

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

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

CodeOwners

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

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

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

Pull Request 草稿

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

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

GPG 功能完善

目前 Gitee 已经支持 GPG 公钥的使用，点此查看如何在 Gitee 上使用 GPG。

近期 Gitee 团队也对 GPG 相关的功能进行了完善，具体更新项如下：

• Pull Request 创建时（未提交完成创建），Commit 列表支持显示 GPG 标记；
• 平台通过 Web 页面 提交/合并 代码，支持自动添加平台 GPG 签名；
• 现有平台 GPG 签名提示卡片文案表述优化；
• 支持识别来自其他三方 SaaS 的 GPG 签名。

以上功能更新均已在 Gitee 社区版及企业版全面上线，如果你有更多在使用中遇到的问题与建议，欢迎在 Gitee Feedback 仓库中向我们反馈：gitee.com/oschina/git…。