注： GitHub 托管的运行器目前在 GitHub Enterprise Server 上不受支持。 您可以在 GitHub 公共路线图 上查看有关未来支持计划的更多信息。
关于持续集成
持续集成 (CI) 是一种需要频繁提交代� �到共享仓库的软件实践。 频繁提交代� �能较早检测到错误，减少在查找错误来源时开发者需要调试的代� �量。 频繁的代� �更新也更便于从软件开发团队的不同成员合并更改。 这对开发者非常有益，他们可以将更多时间用于编写代� �，而减少在调试错误或解决合并冲突上所花的时间。
提交代� �到仓库时，可以持续创建并测试代� �，以确保提交未引入错误。 您的测试可以包括代� �语法检查（检查� �式� �式）、安全性检查、代� �覆盖率、功能测试及其他自定义检查。
创建和测试代� �需要服务器。 您可以在推送代� �到仓库之前在本地创建并测试更新，也可以使用 CI 服务器检查仓库中的新代� �提交。
关于使用 GitHub Actions 的持续集成
使用 GitHub Actions 的 CI 提供可以在仓库中构建代� �并运行测试的工作流程。 工作流程可在 GitHub 托管的虚拟机或您自行托管的机器上运行。 更多信息请参阅“GitHub 托管的运行器的虚拟环境”和“关于自托管运行器”。
您可以配置 CI 工作流程在 GitHub 事件发生时运行（例如，当新代� �推送到您的仓库时）、按设定的时间表运行，或者在使用仓库分发 web 挂钩的外部事件发生时运行。
GitHub Enterprise Server 运行 CI 测试并在拉取请求中提供每次测试的结果，� 此您可以查看分支中的更改是否引入错误。 如果工作流程中的所有 CI 测试通过，您推送的更改可供团队成员审查或合并 如果测试失败，则是其中某项更改导致了失败。
如果在仓库中设置了 CI，GitHub Enterprise Server 会分析仓库中的代� �，并� �据仓库中的语言和框架推荐 CI 工作流程。 For example, if you use Node.js, GitHub Enterprise Server will suggest a starter workflow that installs your Node.js packages and runs your tests. You can use the CI starter workflow suggested by GitHub Enterprise Server, customize the suggested starter workflow, or create your own custom workflow file to run your CI tests.
除了帮助设置项目的 CI 工作流程之外，您还可以使用 GitHub Actions 创建跨整个软件开发生命周期的工作流程。 例如，您可以使用操作来部署、封装或发行项目。 更多信息请参阅“关于 GitHub Actions”。
有关常用术语的定义，请参阅“GitHub Actions 的� �心概念”。
Starter workflow
GitHub Enterprise Server offers CI starter workflow for a variety of languages and frameworks.
Browse the complete list of CI starter workflow offered by GitHub in the actions/starter-workflows repository on your GitHub Enterprise Server instance.