刚过完年就发版？

没错！新年第一个工作周，对 Gitee 团队来说，最好的拜年方式就是用一场酣畅淋漓的更新开启新年，龙年首更新现在鲜上桌，依旧直接看东西！

企业版上新保护分支支持权重和白名单

本次更新中，保护分支规则支持对了对 规则权重 的配置，用来满足分支在匹配多个分支时，优先选择策略的匹配规则。

权重支持使用 0 - 100 的整数数值进行权重设置，规则的匹配顺序将依据权重进行排序，权重越大的规则越优先匹配。

在之前 Gitee 的保护分支机制中，保护分支由 保护分支策略 + 分支属性 组合进行设定。当用户需要对分支取消保护时，需要将分支从 保护分支策略 中排除，或取消策略才能进行修改。

在本次更新中，我们提供了保护分支策略白名单功能。在不取消策略的前提下，允许用户对具体分支做单独排除。

用户可以直接在分支管理中将保护分支修改为常规分支。

保存后，被设置为常规分支的分支名称，将出现在对应的保护分支策略白名单中。

OpenAPI 上新

在本次更新中，Gitee 团队新增了通过 Commit 反查 Pull Request 的接口。用于快速定位提交出现的 Pull Request。

接口说明：使用 Commit SHA 反查 提交所在的 Pull Request接口文档：https://gitee.com/api/v8/swagger#/getEnterpriseIdProjectsProjectIdCommitCommitIdPullRequests接口地址：https://api.gitee.com/enterprises/{enterprise_id}/projects/{project_id}/commit/{commit_id}/pull_requests请求方式：GET请求参数：见下方表格

专业版上新支持限制用户提交用户昵称

在研发场景中，企业往往会要求开发者在 git commit 时使用企业邮箱进行提交，并不允许员工 A 推送员工 B 的代码。

当前 Gitee 的推送规则支持：

限制开发者只能推送自己的提交（git push 包含的提交中 Commitor 邮箱必须和 push 帐号绑定的邮箱保持一致）仅指定域名后缀的 Commitor 邮箱提交允许被推送

这满足了上述的场景。在更为严格的研发场景中，企业能会要求开发者提交代码时设置的提交者名称也要和帐号保持一致。在本次更新中，我们支持了这一场景诉求，允许推送提交中的提交者名称必须与推送者的用户名一致（忽略英文大小写）。

支持配置仓库容量配额

相比 SaaS，在私有化部署场景中，用户对仓库存储资源的消耗敏感度偏低（一般无需考虑存储问题）。但随着业务的发展，仓库体积膨胀越来越快，存储资源的分配在不同团队和项目间容易产生争论。

为此，Gitee 专业版提供了对单个仓库容量上限的配置，以便于企业在项目发起之初，严格限制项目的代码存储容量。管理员可以通过仓库设置下，对单个仓库的最大容量进行限制。开启后如容量达到上限，仓库将默认进入只读状态，进而让研发团队自行对仓库进行瘦身，以提升资源利用率。

随着近两年企业的私有化部署需求越来越多，Gitee 团队也对此积极响应，推出了 Gitee 企业版的私有化部署版本—— Gitee 专业版，满足企业私有部署需求，并且支持多租户、信创适配、定制化和永久授权。

点击链接：https://gitee.com/professional，立即预约演示并自助下载试用。