GitHub AE release notes

企业所有者可以从企业帐户的“组织”页面作为成员或所有者加入 GitHub AE 上的组织。 有关详细信息，请参阅“管理企业拥有的组织中的角色”。

通常可以使用自定义存储库角色。 通过自定义存储库角色，组织所有者现在可以对授予用户的存储库访问权限进行更精细的控制。 REST API 也完全支持自定义存储库角色。 有关详细信息，请参阅 REST API 文档中的“管理组织的自定义存储库角色”和“组织”。

企业所有者可以阻止组织所有者邀请协作者访问 GitHub AE 存储库。 有关详细信息，请参阅“强制实施用于邀请协作者访问存储库的策略”。

用户可以选择接收当有人为组织或存储库启用或禁用代码安全或分析功能时触发的 Webhook 事件。 有关详细信息，请参阅以下文档。

• Webhook 文档中的“Webhook 事件和有效负载”
• 管理组织的安全和分析设置
• “管理存储库的安全和分析功能”

企业所有者和用户可以在企业和组织审核日志中以及通过 REST API 查看机密扫描警报和绕过机密扫描推送保护的情况。 有关详细信息，请参阅以下文档。

• “使用机密扫描保护推送”
• “企业的审核日志事件”
• 审查组织的审核日志
• REST API 文档中的“机密扫描”

组织所有者现在可以在管理自定义存储库角色时为机密扫描配置两个新的权限。

• 查看机密扫描结果
• 关闭或重新打开机密扫描结果

有关详细信息，请参阅“管理组织的自定义存储库角色”。

用户可以根据其访问权限，在企业、组织或存储库级别执行自定义机密扫描模式的试运行。 试运行使用户可以在发布模式和生成警报之前检查和训练他们的模式。 可以撰写一个模式，然后使用“保存和试运行”来检索结果。 扫描通常只需要几秒钟，但当试运行结果准备就绪时，GitHub AE 还会通过电子邮件通知用户。 有关详细信息，请参阅“关于机密扫描”和“定义机密扫描的自定义模式”。

用户可以使用 UI 或 API 对存档存储库启用机密扫描。 有关详细信息，请参阅 REST API 文档中的“关于机密扫描”、“关于存档的存储库”和“存储库”。

机密扫描可防止 Web 编辑器中的机密泄漏。 有关详细信息，请参阅“使用机密扫描保护推送”。

代码扫描现在可以检测到更多 CWE，并且 CodeQL 代码扫描完全支持以下语言版本中的标准语言功能。

• C# 10 / .NET 6
• Python 3.10
• Java 17
• TypeScript 4.5

有关详细信息，请参阅 GitHub 博客。

组织所有者和安全管理员可以在组织的“安全”选项卡中查看代码扫描警报。有关详细信息，请参阅“关于安全概述”。

代码扫描警报页面现在总是显示默认分支的警报状态和信息。 在侧边栏中有一个新的“受影响的分支”面板，在那里你可以看到其他分支中的警报状态。 如果警报在默认分支中不存在，警报页面将为最后一次看到警报的位置显示状态为“在分支中”或“在拉取请求中”。 此改进使我们更易于理解引入到代码库中的警报状态。 有关详细信息，请参阅“关于代码扫描警报”。 警报列表页面没有变化，可以按 branch 进行筛选。 可以使用代码扫描 API 为警报检索更详细的分支信息。 有关详细信息，请参阅 REST API 文档中的“代码扫描”。

代码扫描现在显示警报分析源的详细信息。 如果一个警报有多个分析源，它将显示在“受影响的分支”边栏和警报时间线中。 用户可以将鼠标悬停在“受影响的分支”边栏中的分析源图标上，以查看每个分析源中的警报状态。 如果警报只有一个分析源，则警报页上不会显示任何有关分析源的信息。 这些改进将使理解警报变得更加容易。 特别是，它将帮助用户理解那些具有多个分析源的内容。 这对于具有多个分析配置的设置尤其有用，例如单存储库。 有关详细信息，请参阅“关于代码扫描警报”。

用户可以在检索机密扫描警报时使用 REST API 中的 sort 和 direction 参数，并根据警报的 created 或 updated 字段进行排序。 新参数可用于所有 GitHub AE 部署，也可用于单个组织或存储库。 有关详细信息，请参阅以下文档。

• “列出企业的机密扫描警报”
• “列出组织的机密扫描警报”
• “列出存储库的机密扫描警报”
• REST API 文档中的“机密扫描”

用户可以选择接收在新位置检测到机密时触发的 Webhook。 secret_scanning_alert_location Webhook 事件包括位置详细信息，例如提交 SHA 和相关的检测警报。 为包含检测到的机密的每个新文件路径创建一个位置。 有关详细信息，请参阅“Webhook 事件和有效负载”。

用户可以选择在 Web UI 中或通过 REST API 关闭代码扫描警报时添加注释。 消除注释出现在事件时间线中。 用户还可以通过 REST API 添加或检索消除注释。 有关详细信息，请参阅 REST API 文档中的“在拉取请求中对代码扫描警报进行分类”和“代码扫描”。

用户现在可以使用 REST API 检索组织的代码扫描警报。 这个新 API 终结点补充了现有存储库终结点。 有关详细信息，请参阅 REST API 文档中的“代码扫描”。

github/codeql-go 存储库的内容已移至 github/codeql 存储库，与 CodeQL 支持的所有其他编程语言的类似库一起存在。 现在，可以在新位置找到用于使用 GitHub 的 CodeQL 代码分析工具分析以 Go 编程语言编写的代码库的开源 CodeQL 查询、库和提取器。 有关详细信息，包括有关迁移现有工作流的指南，请参阅 github/codeql-go#741。

企业所有者可以在 GitHub AE 部署中查看 Dependabot 警报概述，包括以存储库为中心的应用程序安全风险视图，以及以警报为中心的所有机密扫描和 Dependabot 警报视图。 视图为 beta 版本，可能会更改。 有关详细信息，请参阅“查看安全概述”。

组织所有者和安全管理员可以在组织的“安全”选项卡中查看 Dependabot 警报。有关详细信息，请参阅“关于安全概述”。

用户可以使用 Web UI 重新打开已关闭的 Dependabot 警报。 这不会影响 Dependabot 的拉取请求或 GraphQL API。 有关详细信息，请参阅“关于 Dependabot 警报”。

用户可以使用 GraphQL API 从 Dependabot 查看固定警报。 用户还可以按状态和唯一数字标识符进行访问和筛选，并且可以按漏洞警报对象上的状态进行筛选。 对于 RepositoryVulnerabilityAlert，现在存在以下字段。

• number
• fixed_at
• fix_reason
• state

有关详细信息，请参阅 GraphQL API 文档中的“对象”。

组织所有者和安全管理员可以使用组织的安全概述查看以存储库为中心的应用程序安全风险视图，或者以警报为中心的所有代码扫描、Dependabot 以及组织中所有存储库的机密扫描警报视图。 有关详细信息，请参阅“关于安全概述”。

GitHub Actions 可以通过扫描依赖项来对用户的拉取请求执行依赖项审查，并警告用户相关的安全漏洞。 dependency-review-action 操作由一个新的 API 终结点支持，该终结点区分任意两个修订版之间的依赖项。 有关详细信息，请参阅“关于依赖项审查”。

依赖项关系图检测 GitHub Actions 工作流的 YAML 文件。 GitHub AE 将在“见解”选项卡的依赖项关系图部分中显示工作流文件。 发布操作的存储库还可以从存储库主页上的“使用者”控件中查看依赖于该操作的存储库数量。 有关详细信息，请参阅“关于依赖项关系图”。

依赖项关系图检测 Rust 的 Cargo.toml 和 Cargo.lock 文件。 这些文件将显示在“见解”选项卡的“依赖项关系图”部分中。用户将收到 Dependabot 警报和更新，以获取与其 Rust 依赖项关联的漏洞 。 今后会添加包元数据，包括将包映射到存储库。 有关详细信息，请参阅“关于依赖项关系图”。

如果为 GitHub AE 启用 GitHub Connect，用户可以为 GitHub Advisory Database 中的安全公告做出改进。 若要做出贡献，请在查看公告详细信息时单击“此漏洞的建议改进”。 有关详细信息，请参阅以下文章。

• “管理 GitHub Connect”
• GitHub Enterprise Cloud 文档中的“浏览 GitHub 顾问数据库中的安全漏洞”
• GitHub Enterprise Cloud 文档中的“关于存储库的 GitHub 安全公告”
• GitHub Enterprise Cloud 文档中的“编辑 GitHub 顾问数据库中的安全通告”

维护自托管运行器的人员现在可以更好地控制运行器何时执行软件更新。 如果为运行器指定 --disableupdate 标志，当运行器软件的新版本可用时，运行器将不会尝试执行自动软件更新。 这允许按照自定义计划更新自托管运行器，如果自托管运行器位于容器中，就会特别方便。 为了与 GitHub Actions 服务兼容，需要在新运行器版本可用的 30 天内更新运行器软件。 有关安装最新运行器版本的详细信息，请参阅 actions/runner 中最新版本的安装说明。

使用 GitHub Actions 时，为了降低将未经他人审核的更改合并到受保护分支的风险，企业所有者和存储库管理员可以阻止 Actions 创建拉取请求。 组织所有者以前可以启用此限制。 有关详细信息，请参阅以下文章。

• “在企业中为 GitHub Actions 实施策略”
• “禁用或限制组织的 GitHub Actions”
• “管理存储库的 GitHub Actions 设置”

组织所有者可以通过选择可访问运行器组的工作流来增加自托管运行器上 CI/CD 工作流的安全性。 以前，存储库中的任何工作流（如问题标记工具）都可以访问组织可用的自承载运行器。 有关详细信息，请参阅“使用组管理对自托管运行器的访问权限”和“GitHub 博客”。

组织所有者可以控制 GitHub Actions 是否可以批准拉取请求。 该功能可以防止用户使用 GitHub Actions 来满足“需要审批”分支保护需求，并合并未经其他用户审查的更改。 为了防止中断现有工作流，默认启用“允许 GitHub Actions 审核计入所需审批”。 组织所有者可以在组织的 GitHub Actions 设置中禁用此功能。 有关详细信息，请参阅“禁用或限制组织的 GitHub Actions”。

用户可以编写由 workflow_dispatch 和 workflow_call 触发的单个工作流，并使用 inputs 上下文访问输入值。 以前，workflow_dispatch 输入位于事件有效负载中，这增加了想要编写一个可重用和手动触发的工作流的工作流作者的难度。 对于 workflow_dispatch 触发的工作流，输入在 github.event.inputs 上下文中仍可用，以保持兼容性。 有关详细信息，请参阅“上下文”。

用户现在可以在 GitHub Actions 工作流运行中仅重新运行失败作业或单个作业。 有关详细信息，请参阅“重新运行工作流和作业”。

为了总结作业的结果，用户可以生成 Markdown 并将内容发布为作业摘要。 例如，在使用 GitHub Actions 运行测试后，摘要可以提供通过、失败或跳过的测试的概述，从而可能减少查看完整日志输出的需要。 有关详细信息，请参阅“GitHub Actions 的工作流命令”。

为了在工作流重新运行期间更轻松地诊断作业执行失败，用户可以启用调试日志记录，它会输出有关作业执行和环境的信息。 有关详细信息，请参阅“重新运行工作流和作业”和“使用工作流运行日志”。

如果你管理 GitHub Actions 的自承载运行器，则可以通过定义要执行的脚本来确保运行器本身在工作流运行之前和之后的状态一致。 通过使用脚本，你不再需要用户手动将这些步骤合并到工作流中。 作业前和作业后脚本为 beta 版本，可能会发生更改。 有关详细信息，请参阅“在作业之前或之后运行脚本”。

企业所有者可以配置策略来控制人员的用户名或全名是否显示在内部存储库中。 有关详细信息，请参阅“在企业中实施存储库管理策略”。

组织所有者可以通过新的“固定存储库”下拉菜单直接从存储库将存储库固定到组织的配置文件。

创建分支时，用户可以自定义分支的名称。 有关详细信息，请参阅“为存储库创建分支”。

用户可以删除与打开的拉取请求关联的分支。 有关详细信息，请参阅“在存储库中创建和删除分支”。

CODEOWNERS 已得到以下改进。

• 从 Web UI 查看 CODEOWNERS 文件时，现在会显示语法错误。 以前，当 CODEOWNERS 文件中的某一行存在语法错误时，该错误将被忽略，或者在某些情况下导致整个 CODEOWNERS 文件无法加载。 GitHub Apps 和 Actions 可以使用新的 REST 和 GraphQL API 访问相同的错误列表。 有关详细信息，请参阅 REST API 文档中的“存储库”或 GraphQL API 文档中的“对象”。
• 当有人创建了新的拉取请求或将新更改推送到草稿拉取请求后，任何将被要求审查的代码所有者现在都在拉取请求的“审阅者”下列出。 此功能使你可以尽早了解，一旦拉取请求标记为准备审查，将要求谁进行审查。
• CODEOWNERS 文件中的注释现在可以显示在行尾，而不是只显示在专用行上。

有关详细信息，请参阅“关于代码所有者”。

当用户重命名文件或将文件移动到新目录时，如果文件的内容至少一半是相同的，则提交历史记录表明文件已重命名，类似于 git log --follow。 有关详细信息，请参阅 GitHub 博客。

在任何人可以合并与分支关联的拉取请求之前，用户可能需要成功部署分支。 有关详细信息，请参阅“关于受保护的分支”和“管理分支保护规则”。

存储库管理员现在可以配置标记保护规则来保护存储库的标记。 一旦受到标记保护规则的保护，匹配指定名称模式的标记只能由对存储库具有维护或管理访问权限的用户创建和删除。 有关详细信息，请参阅“配置标记保护规则”。

用户可以通过在存储库的根目录中创建 .git-blame-ignore-revs 文件来忽略意见视图中的修订。 有关详细信息，请参阅“查看文件”。

用户可以针对任何支持例外的分支保护规则授予 GitHub 应用例外。 有关详细信息，请参阅“关于应用”和“管理分支保护规则”。

对于过期或撤销的公共 GPG 签名密钥，GitHub AE 会验证 Git 提交签名，如果用户在密钥仍然有效时进行了提交，提交会显示为已验证。 用户还可以上传过期或撤销的 GPG 密钥。 有关详细信息，请参阅“关于提交签名验证”。

为了确认提交符合管理存储库的规则和许可，组织所有者和存储库管理员现在可以要求开发人员通过 Web 界面提交时进行签核。 有关详细信息，请参阅“管理组织的提交签核策略”和“管理存储库的提交签核策略”。

使用位于拉取请求的“已更改的文件”选项卡中的文件树，用户可以导航已修改的文件，了解更改的大小和范围，并集中审查。 如果拉取请求修改了至少两个文件，并且浏览器窗口足够宽，则会出现文件树。 有关详细信息，请参阅“查看拉取请求中的建议更改”和“筛选拉取请求中的文件”。

用户可以默认使用拉取请求标题作为所有 Squash 合并的提交消息。 有关详细信息，请参阅“为拉取请求配置提交压缩”。

通过拉取请求页面上的“更新分支”按钮，用户可以使用来自基础分支的最新更改来更新拉取请求的分支。 这对于在合并之前验证拉取请求的更改是否与基础分支的当前版本兼容很有用。 两个增强功能提供了保持分支更新的更多方法。

• 当拉取请求主题分支的基础分支过时时，用户可以对基础分支的最新版本进行变基来对其进行更新。 变基将主题分支中的更改应用到基础分支的最新版本，这会生成一个具有线性历史记录的分支，因为没有创建合并提交。 若要通过变基更新，单击“更新分支”按钮旁的下拉菜单，单击“使用变基更新”，然后单击“变基分支” 。 在此之前，“更新分支”执行的是传统合并，它总是导致拉取请求分支中的合并提交。 此选项仍然可用，但现在用户有更多选择。 有关详细信息，请参阅“使拉取请求与基本分支保持同步”。
• 新的存储库设置允许在拉取请求主题分支的基础分支不是最新时“更新分支”按钮始终可用。 在此之前，此按钮仅在“要求分支在合并之前更新”分支保护设置启用时可用。 具有管理员或维护员访问权限的人员可以在存储库设置的“拉取请求”部分管理“始终建议更新拉取请求分支”设置 。 有关详细信息，请参阅“管理更新拉取请求分支的建议”。

查看特定版本的详细信息时，用户可以看到每个版本资产的创建日期。 有关详细信息，请参阅“查看存储库的发行版和标记”。

在使用自动生成的发行说明创建版本时，用户可以看到标识为先前版本的标记，然后选择不同的标记以指定为先前版本。 有关详细信息，请参阅“自动生成的发行说明”。

第一次显示时，Gist 现在只显示最近 30 条评论。 用户可以单击“加载之前的评论…”查看详细信息。 这使得有很多评论的 Gist 可以更快地出现。 有关详细信息，请参阅“使用 Gist 编辑和共享内容”。

在 Web 界面中编辑 Markdown 已得到改进。

• 用户选择文本并粘贴 URL 后，所选文本将成为粘贴 URL 的 Markdown 链接。
• 当用户粘贴电子表格单元格或 HTML 表格时，生成的文本将呈现为表格。
• 当用户复制包含链接的文本时，粘贴的文本将包含该链接作为 Markdown 链接。

有关详细信息，请参阅“基本编写和格式设置语法”。

在 Web 界面中编辑 Markdown 文件时，单击“预览”选项卡将自动滚动到你正在编辑的预览中的位置。 滚动位置基于单击“预览”选项卡之前光标的位置。

一个在前景和背景元素之间有更大对比度的光高对比度主题现在可用。 有关详细信息，请参阅“管理主题设置”。

由用户或组织拥有的存储库列表现在有一个额外的筛选选项，即“模板”，可以更轻松地找到模板存储库。

GitHub AE 可以显示几种常见的图像格式，包括 PNG、JPG、GIF、PSD 和 SVG，并提供了几种方法来比较版本之间的差异。 当查看拉取请求中添加或更改的图像时，现在默认会显示这些图像的预览形式。 以前，用户会看到一条消息，指示无法显示二进制文件，需要切换“显示多差异”选项。 有关详细信息，请参阅“使用非代码文件”。

对用户、组织、存储库和团队的设置页面进行了重新设计，将类似的设置页面分组为小节，以改进信息体系结构并提高可发现性。 有关详细信息，请参阅 GitHub 更改日志。

Web 界面中的交互元素（例如链接和按钮）在使用键盘聚焦时会显示可见的轮廓，以帮助用户找到页面上的当前位置。 此外，当聚焦时，表单域具有更高对比度的轮廓。

聚焦或悬停在标签上现在会显示带有标签说明的工具提示。

如果用户在创建新问题或拉取请求时刷新页面，将保留代理人、审阅者、标签和项目。

若要使用 OAuth 和 GitHub 应用的设备授权流，应用作者需要手动启用该功能。 通过确保集成者意识到风险，并有意识地选择支持这种形式的身份验证，这一更改降低了应用被用于针对 GitHub AE 用户的钓鱼攻击的可能性。 拥有或管理 OAuth 应用或 GitHub 应用，并且希望使用设备流的用户可以通过应用的设置页面为应用启用它。 设备流 API 终结点将以状态代码 400 响应未启用此功能的应用。 有关详细信息，请参阅“授权 OAuth 应用”。

具有存储库管理员权限的用户可以更好地了解谁有权访问存储库、了解每位用户具有的访问级别，并更轻松地管理对存储库的访问。 例如，用户可以完成以下任务。

• 搜索有权访问存储库的所有成员、团队和协作者。
• 查看成员何时具有混合角色分配（以个人身份直接授予或通过团队间接授予他们）：如果用户的访问权限高于分配给他们的角色，则新“混合角色”警告将显示授予他们的最高级别角色。

有关详细信息，请参阅“管理有权访问存储库的团队和人员”。

企业所有者现在可以在自定义页脚中向企业成员和协作者展示其他链接。 有关详细信息，请参阅“配置自定义页脚”。

用户可以通过单行配置重复使用工作流。 使用可重用工作流，无需跨存储库复制和粘贴工作流定义，从而节省时间并减少维护。 可重用工作流处于 beta 版本阶段，可能会更改。 有关详细信息，请参阅“重用工作流”。

自托管运行器的最新管理体验简化了运行器组的管理，并改进了运行器的概述。 有关详细信息，请参阅“关于自托管运行器”和“使用组管理对自托管运行器的访问权限”。

当 Dependabot 触发工作流运行时，Dependabot 现在将与 GitHub Actions 共享机密，因此用户现在可以使用 Dependabot 的机密从 CI 管道中的专用包注册表中拉取。 有关详细信息，请参阅“管理 Dependabot 的加密机密”。

用户可以使用 if 条件来阻止执行复合操作中的特定步骤（除非满足条件）。 与工作流中定义的步骤一样，你可以使用任何受支持的上下文和表达式来创建条件。 有关复合操作的详细信息，请参阅“创建复合操作”。

用户可以通过为手动触发的工作流指定输入类型来为工作流用户提供更好的体验。 工作流现在支持 choice、boolean 和 environment。 有关详细信息，请参阅“GitHub Actions 的工作流语法”。

存储库、组织或企业级别的第一个可用匹配运行器将在所有情况下运行每个作业，这意味着作业将更快地发送给自托管运行器，尤其是对于具有许多自托管运行器的组织和企业。 以前，在运行需要自托管运行器的作业时，GitHub Actions 将按该顺序在存储库、组织和企业中查找自托管运行器。 有关详细信息，请参阅“在工作流中使用自托管运行器”。

用户可以通过将 runs.using 指定为 node16 来指定 JavaScript 操作应在 Node.js 16 中运行。 Node.js 16 支持补充了对 Node.js 12 的现有支持。 运行器必须安装版本 2.285.0 或更高版本的 GitHub Actions 运行器。 有关详细信息，请参阅“GitHub Actions 的元数据语法”和 actions/runner 存储库。

用户可以使用 REST API 添加、列出和删除自托管运行器的标签。 有关详细信息，请参阅 REST API 文档中的“自托管运行器”。

用户可以使用 CodeQL 代码扫描提高使用 Ruby 创建的服务和工具的安全性。 对于 3.02 及更早版本的所有常见 Ruby 版本，CodeQL 可以检测常见问题，例如 SQL 注入、ReDoS、OS 命令和参数注入、XML 实体扩展、反射型跨站点脚本 (XSS)、存储的 XSS、不安全的反序列化和硬编码凭据。 若要启用 Ruby 分析，用户必须更新现有的 CodeQL 代码扫描工作流文件。 CodeQL 的 Ruby 支持处于 beta 状态，可能会发生更改。 有关详细信息，请参阅“配置代码扫描”和 CodeQL 文档。 有关使用 CodeQL 进行代码扫描的详细信息，请参阅“关于使用 CodeQL 进行代码扫描”。

CodeQL 的 Python 分析支持其他框架，可以检测不受信任的用户数据的更多潜在来源、该数据流经的步骤，以及该数据可能最终流入的潜在危险接收器。 有关详细信息，请参阅 CodeQL 文档中的“支持的语言和框架”。

用户可以使用 REST API 检索在专用存储库扫描中检测到的机密的提交详细信息。 新终结点将显示文件中首次检测到机密的详细信息，包括机密的位置和提交 SHA。 有关详细信息，请参阅 REST API 文档中的“关于机密扫描”和“机密扫描”。

代码扫描 API 包括以下改进。

• 警报包括 fixed_at 时间戳，这是首次在分析中未检测到警报的时间。 用户可以使用此数据更好地了解何时修复代码扫描警报。
• 用户可以使用 created、updated 或 number 上的 sort 和 direction 对最重要的警报结果进行排序。 有关详细信息，请参阅 REST API 文档中的代码扫描。
• 警报和警报终结点响应包括 Last-Modified 标头。 有关详细信息，请参阅 Mozilla 文档中的 Last-Modified。
• 代码扫描分析的 SARIF 响应包括 relatedLocations，其中可能包含不是警报主要位置的位置。 有关示例，请参阅 SARIF 规范。有关详细信息，请参阅 REST API 文档中的代码扫描。
• Webhook 响应警报规则对象包括 help 和 tags 数据。 有关详细信息，请参阅“Webhook 事件和有效负载”。

组织所有者和安全管理员可以使用 REST API 在企业级别检索专用存储库的机密扫描结果。 有关详细信息，请参阅 REST API 文档中的“关于机密扫描”和“机密扫描”。

用户可以通过 GraphQL API 消除 Dependabot 警报。 有关详细信息，请参阅 GraphQL API 文档中的“变化”。

依赖项关系图可在使用 Poetry 包管理器的存储库中检测 Python 依赖项。 将从 pyproject.toml 和 poetry.lock 清单文件中检测依赖项。 有关详细信息，请参阅“关于依赖关系图”。

开发人员和安全研究人员可以使用 CodeQL 在由 Apple silicon 芯片（如 M1）提供支持的计算机上生成数据库和分析代码。 CodeQL CLI 和 VS Code 扩展都支持 Apple silicon。 若要在 Apple silicon 上使用 CodeQL CLI 或 VS Code 扩展，用户必须安装 Xcode 命令行开发人员工具和 Rosetta 2。 Apple silicon 的 CodeQL 支持处于 beta 状态，可能会发生更改。

• 有关在受支持的平台上配置 CodeQL CLI 的详细信息，请参阅 CodeQL 文档中的“使用 CodeQL CLI”。
• 有关 CodeQL 的详细信息，请参阅 CodeQL 文档中的“关于 CodeQL”和“关于代码扫描”。

CodeQL CLI 版本 2.7.1 及更高版本的用户可以将查询帮助作为 Markdown 包含在 SARIF 文件中，帮助文本将显示在 GitHub AE 的代码扫描 UI 中。 用户可以将查询帮助包含为与相应查询文件同名的 Markdown 文件。 例如，如果查询文件为 MyCustomQuery.ql，则查询帮助文件的名称将为 MyCustomQuery.md。 有关自定义 CodeQL 查询的查询帮助作者的详细信息，请参阅查询帮助样式指南。

• 不使用 GitHub Actions 进行 CI/CD 和代码扫描的用户必须在运行 codeql database analyze 命令时通过包括 --sarif-add-query-help 标志来指定添加查询帮助。 有关详细信息，请参阅 CodeQL 文档中的“使用 CodeQL CLI 分析数据库”。

用户可以取消订阅某一给定用户或组织拥有的所有存储库。 有关详细信息，请参阅“管理订阅”。

组织所有者可在将新的部署密钥添加到属于其组织的存储库时取消订阅电子邮件通知。 有关详细信息，请参阅“配置通知”。

问题和拉取请求的电子邮件通知的主题行包括“(Issue #NUMBER)”或“(PR #NUMBER)”，以帮助用户轻松区分这两种通知类型 。

默认情况下，Gmail 中不再隐藏电子邮件通知底部的“在 GitHub 上查看”链接。

组织成员现在可以查看企业所有者的列表。 每当组织成员遇到联系企业所有者的提示时，都有一个链接可将用户定向到该列表。 还可以使用 enterpriseOwners 终结点上的 GraphQL API 的 Organization 对象访问该列表。 有关详细信息，请参阅“查看组织中人员的角色”。

具有存储库管理员权限的用户可以重命名受分支保护规则保护的分支。 有关详细信息，请参阅“重命名分支”和“管理分支保护规则”。

具有存储库管理员权限的人员可以选择谁可以强制推送到存储库，而不是允许所有用户或不允许任何用户强制推送。 有关详细信息，请参阅“关于受保护的分支”和“管理分支保护规则”。

具有存储库管理员权限的用户可以要求使用拉取请求对受保护的分支进行所有更改，但不需要评审。 有关详细信息，请参阅“关于受保护的分支”和“管理分支保护规则”。

具有存储库管理员权限的用户可以允许特定用户和团队绕过拉取请求要求。 有关详细信息，请参阅“管理分支保护规则”。

用户可将单字符前缀用于自定义自动链接。 自动链接前缀还允许使用 .、-、_、+、=、:、/ 和 # 字符以及字母数字。 有关详细信息，请参阅“配置自动链接以引用外部资源”。

用户可以在团队的代码评审设置中独立于“启用自动分配”启用“仅通知请求的团队成员”，从而允许用户要求团队进行评审，但无需不必要地始终通知整个团队 。 有关详细信息，请参阅“管理团队的代码评审设置”。

改进了版本 UI，使人们能够清楚地了解给定版本中包含的内容，并清楚地看到对版本贡献者的承认。 改进了分页功能，并提供了新的搜索功能。

用户可以自动生成发行说明，其中包含给定版本的所有拉取请求的摘要。 有关详细信息，请参阅“自动生成的发行说明”。

用户可以在 gist 中预览 Markdown 文件的呈现。 创建或编辑具有 Markdown 文件扩展名 .md 的 gist 文件时，“预览”或“预览更改”选项卡将显示文件内容的 Markdown 呈现 。 有关 Gist 的详细信息，请参阅“使用 Gist 编辑和共享内容”。

用户可以选择在 Markdown 字段（如问题和拉取请求注释）中使用固定宽度的字体。 有关详细信息，请参阅“关于在 GitHub 上编写和设置格式”。

用户可以在 Markdown 中指定图像显示的主题。 有关详细信息，请参阅“基本编写和格式设置语法”。

用户可以选择文本然后粘贴 URL，从而在编辑已启用 Markdown 的字段（如问题或拉取请求注释）中的文本时快速创建 Markdown 链接。

用户粘贴到 Markdown 字段中的 HTML 链接会自动转换为 Markdown 链接。 若要将 HTML 链接粘贴为纯文本，请按 ⌘/ctrl + shift + v。

Markdown 文件、问题注释、拉取请求和讨论中对从右向左书写的语言提供原生支持。

用户可以设置首选选项卡大小。 GitHub AE 上带选项卡的所有代码都将使用首选选项卡大小呈现。 有关详细信息，请参阅“管理选项卡大小呈现首选项”。

用户可以使用 GitHub AE 的新辅助功能设置管理键盘快捷方式，并且可以选择禁用仅使用单个字符的字符键快捷方式，例如 s、g c 和 . （句点键）。 有关详细信息，请参阅“管理辅助功能设置”。

为了确保所有更改都由预期应用验证，用户现在可以控制提供所需状态检查的 GitHub 应用。 如果状态随后由其他应用提供，或者由用户通过提交状态提供，则将阻止合并。 现有所需状态检查将继续接受来自任何应用的状态，但可以更新为仅接受来自特定应用的状态。 新添加的所需状态检查将默认为最近报告状态的应用，但你可以选择其他应用或允许任何应用提供状态。 有关详细信息，请参阅“关于受保护的分支”和“编辑分支保护规则”。

组织所有者和对存储库具有管理员访问权限的用户可以触发 Webhook 来侦听对分支保护规则的更改。 有关详细信息，请参阅“Webhook 事件和有效负载”。

代码扫描和机密扫描现针对 GitHub AE 正式发布。 有关详细信息，请参阅“关于代码扫描”和“关于机密扫描”。

机密扫描的自定义模式现正式发布。 有关详细信息，请参阅“为机密扫描定义自定义模式”。

现在，你可以在代码扫描警报页面上通过新的拉取请求筛选器找到与你的拉取请求相关的所有代码扫描警报。 拉取请求检查页面显示拉取请求中引入的警报，但不显示拉取请求分支上的现有警报。 “检查”页面上的“查看所有分支警报”新链接可以转到代码扫描警报页面，其中已经应用了特定拉取请求筛选器，因此你可以看到与拉取请求相关的所有警报。 这对于管理大量警报和查看单个警报的更详细信息非常有用。 有关详细信息，请参阅“管理存储库的代码扫描警报”。

GitHub Advanced Security 现提供通过代码扫描、Dependabot 和机密扫描检测到的应用程序安全风险的组织级别视图。 安全概览显示每个存储库上安全功能的启用状态以及检测到的警报数量。

此外，安全概览将列出组织级别的所有机密扫描警报。 Dependabot 和代码扫描警报的类似视图将在未来的版本中发布。 有关详细信息，请参阅“关于安全概述”。

依赖项关系图现已在 GitHub AE 上提供。 依赖项关系图通过解析签入存储库的依赖项清单，帮助你了解所依赖的开源软件。 有关详细信息，请参阅“关于依赖项关系图”。

Dependabot 警报现在会就 GitHub AE 上的依赖项漏洞通知你。 可以通过启用依赖项关系图、启用 GitHub Connect 和从 GitHub 顾问数据库同步漏洞来启用 Dependabot 警报。 此功能为 beta 版本，可能会有变动。 有关详细信息，请参阅“关于 Dependabot 警报”。

启用 Dependabot 警报后，当影响组织成员依赖项的新漏洞被添加到 GitHub 顾问数据库或易受攻击的依赖项被添加到其清单中时，他们将收到通知。 成员可以自定义通知设置。 有关详细信息，请参阅“配置 % data variables.product.prodname_dependabot_alerts %} 的通知”。

组织现在可以授权团队管理其所有存储库上的安全警报和设置。 “安全管理员”角色可以应用到任何团队，并授予团队成员以下权限。

• 对组织中所有存储库的读取访问
• 对组织中所有安全警报的写入访问
• 对组织级“安全性”选项卡的访问
• 在组织级别对安全设置的写入访问
• 在存储库级别对安全设置的写入访问

有关详细信息，请参阅“管理组织中的安全管理员”。

GitHub AE 现在支持临时（单作业）自托管运行器和使自动缩放运行器更加轻松的新 workflow_job Webhook。

临时运行器适合自托管环境，其中每个作业都需要在干净的映像上运行。 作业运行后，GitHub AE 会自动注销临时运行器，允许你执行任何作业后管理。

可以将临时运行器与新的 workflow_job Webhook 组合在一起来自动缩放自托管运行器，以响应来自 GitHub Actions 的作业请求。

有关详细信息，请参阅“使用自托管运行器自动缩放”和“Webhook 事件和有效负载”。

通过使用复合来引用其他操作，可以减少工作流中的重复工作量。 以前，用 YAML 编写的操作只能使用脚本。 有关详细信息，请参阅“创建复合操作”。

在企业级别管理自托管运行器不再需要使用具有 admin:enterprise 范围的个人访问令牌。 可以改用 new manage_runners:enterprise 范围来限制令牌上的权限。 具有此范围的令牌可以对许多 REST API 终结点进行身份验证，以管理企业的自承载运行器。

现在可以使用 REST API 以编程方式与审核日志连接。 虽然审核日志转发使你能够使用自己的工具包保留和分析数据并随时间的推移确定模式，但新的 REST API 将帮助你对最近历史记录中发生的值得注意的事件执行有限的分析。 有关详细信息，请参阅“审查组织的审核日志”。

现在可以为新的和现有的个人访问令牌设置到期日期。 当需要续订即将到期的令牌时，GitHub AE 会向你发送电子邮件。 可以重新生成已到期的令牌，为你提供具有与原始令牌相同属性的副本令牌。 当使用带有 GitHub AE API 的令牌时，你会看到一个新标头 GitHub-Authentication-Token-Expiration，指示令牌的到期日期。 你可以在脚本中使用它，例如，在到期日期临近时记录警告消息。 有关详细信息，请参阅“创建个人访问令牌”和“REST API 入门”。

组织所有者现在可以 CSV 格式导出具有存储库访问权限的人员列表。 有关详细信息，请参阅“查看有权访问存储库的人员”。

管理代码评审分配的新设置有助于在团队成员之间分配团队的拉取请求评审，这样评审就不只是一两个团队成员的责任了。

• 子团队成员：只分配给团队的直接成员。 以前，团队评审请求可以分配给团队的直接成员或子团队的成员。
• 现有请求计数：即使已请求一个或多个团队成员，也会继续自动分配。 在此之前，已请求的团队成员将被计为团队自动评审请求中的一个。
• 团队评审请求：指定一个团队负责评审，即使新指定了一个或多个成员。

有关详细信息，请参阅“管理团队的代码评审设置”。

两个新主题可用于 GitHub AE Web UI。

• 一个在前景和背景元素之间有更大对比度的深色高对比度主题
• 浅色和深色色盲，将红色和绿色之类的颜色转换为橙色和蓝色

有关详细信息，请参阅“管理主题设置”。

现在，你可以在任何 Markdown 字段中使用脚注语法来引用相关信息，而不会中断散文流。 脚注显示为上标链接。 单击脚注可跳转到引用，该引用显示在文档底部的新建部分中。 有关详细信息，请参阅“基本编写和格式设置语法”。

现在可以通过 Web UI 在源视图和呈现的 Markdown 视图之间进行切换，方法是单击 按钮，以在任何 Markdown 文件顶部“显示源差异”。 以前，你需要使用意见视图链接到 Markdown 文件源中的特定行号。

GitHub AE 现在根据标题自动为 Wikis 生成一个目录。

GitHub Actions 是一种用于 CI/CD 和工作流程自动化的强大而灵活的解决方案。 有关详细信息，请参阅“了解 GitHub Actions”。

请注意，在此升级期间启用 GitHub Actions 时，名为“GitHub Actions”的两个组织（@actions 和 @github）将出现在 你的企业 中。 这些组织是 GitHub Actions 所必需的。 名为 @ghost 和 @actions 的用户在审核日志中作为创建这些组织的参与者出现。

GitHub Packages 是一种与 GitHub Actions、API 和 Webhook 原生集成的包托管服务。 创建一个包含你的代码、持续集成和部署解决方案的[端到端 DevOps 工作流程]。 在此 Beta 版本期间，GitHub Packages 免费提供给 GitHub AE 客户。

GitHub Advanced Security 以 Beta 版本提供，其中包括代码扫描和机密扫描。 在此 Beta 版本期间，GitHub Advanced Security 功能免费提供给 GitHub AE 客户。 存储库和组织管理员可以在“设置”下的“安全性和分析”选项卡中选择使用 GitHub Advanced Security。

详细了解 GitHub AE 上的 GitHub Advanced Security 代码扫描和机密扫描。

使用 SCIM（跨域身份管理系统）的客户现可与 GitHub 团队同步 Azure Active Directory 中的安全组。 团队链接到安全组后，如果从其指定的安全组添加或移除用户，系统将在 GitHub AE 中自动更新成员身份。

GitHub IP 允许列表可用于从以 CIDR 表示法定义的管理员指定 IP 范围筛选流量。 通过“安全”>“设置”在企业或组织帐户级定义允许列表。 所有尝试在企业帐户和组织内访问资源的流量均由 IP 允许列表进行筛选。 除了能够请求网络安全组更改以将流量筛选到整个 GHAE 租户外，还提供此功能。

组织所有者现在可以禁止从组织中的存储库发布 GitHub Pages 站点。 这不会取消发布现有站点。

使用 GitHub Pages 的存储库现在可以从任何分支构建和部署。

在编写问题或拉取请求时，按 return 或 enter 后，项目符号、数字和任务的列表语法现在会自动补全。

现可从存储库页面删除存储库中的目录。 导航到目录时，“添加文件”按钮旁边的新烤肉串按钮会提供删除目录的选项。

现可通过在“#”之后搜索多个单词，更便捷地引用问题或拉取请求。

企业所有者现可发布强制性消息。 该消息显示给所有用户，他们必须予以确认。 这可用于显示重要信息、服务条款或政策。

GitHub App 单个文件路径权限现可支持多达 10 个文件。

在配置 GitHub App 时，授权回叫 URL 是必填字段。 现在，我们将允许集成商指定多个回叫 URL。 如果未列出请求中的 URL，GitHub AE 拒绝授权。

新的 API 终结点支持为特定存储库范围内的用户到服务器令牌交换用户到服务器令牌。

以下事件现在记录在审核日志中：将团队成员提升为团队维护者，以及将团队维护者降级为团队成员。

现在支持 OAuth 设备授权流程。 这可让任何 CLI 客户端或开发者工具使用辅助系统进行身份验证。

如果启用了 SCIM 预配，用户将不能再删除他们的帐户。

企业和组织所有者现可为新存储库设置默认分支名称。 企业所有者还可在所有组织中强制使用所选的默认分支名称，或者允许各个组织选择他们自己的分支名称。

现有存储库不受这些设置的影响，并且它们的默认分支名称不会更改。

此更改是 GitHub 为支持项目和希望重命名其默认分支的维护者所做的众多更改之一。 要了解详细信息，请参阅 github/重命名。

用户不能再在其个人资料上设置备份电子邮件地址。 他们的电子邮件地址仅通过 IdP 设置。

在通过 IdP 配置身份验证后，不能再启用双因素身份验证。

GitHub AE 现可连接到 Azure Boards。

API 缺少版本标头，现已设置为“GitHub AE”。

文档链接已修复。

企业设置内的审核日志转发配置失败。

导航到 gists 可能导致 500 错误。

支持电子邮件或 URL 无法保存。 现在它会在几分钟后保存。

组织级拉取请求模板未应用到组织中的所有拉取请求。