本地 CI
推送—等待—红叉—修复—再推送的循环，每转一圈就浪费十分钟。有了 act，同样的工作流可以在你机器上的 Docker 容器里运行， 由 Gitcito 来驱动：选一个工作流，按下运行，看着 CI 本来会打印的那份日志—— 在任何东西离开你的机器之前。
是一项集成，不是内置运行时
Gitcito 刻意不捆绑 act 或 Docker——一个拖着容器运行时的应用，恰恰是 git
客户端的反面。这是一项需要主动开启的集成：在设置 → 集成（或对话框本身）里
启用它，Gitcito 会检测已安装的组件并引导你完成剩下的步骤——brew install act、
一个正在运行的 Docker 守护进程，就绪。三个条件全部满足之前什么都不会运行：
已启用、act 已安装、Docker 可连接。
它能做什么
- 按
name:列出.github/workflows下的每一个工作流。 - 运行用 act 针对你的工作区执行工作流——包括未提交的更改，而这正是 重点：在提交之前测试，而不是在推送之后。
- 输出实时流入对话框；停止会终止运行。退出码 0 显示通过，其余情况 显示失败并附上退出码。
图上的逐提交判定
一次运行结束后，会把结果钉在它所测试的那个提交上：图中对应的行会出现一个小
烧瓶，标成绿色或红色，让你一眼看出哪些提交已经在本地扛过了 CI。判定以
git 备注的形式存储在 refs/notes/gitcito-ci 下——只存在于你的机器上，默认
永远不会被推送。
诚实原则：只有当你的工作区是干净的时，判定才会被钉上。在未提交的更改上 跑的一次运行，测试的是任何提交都不包含的内容，所以它只在对话框里显示结果， 不做任何标记。
测试某个提交或范围——不用离开你的分支
对话框中的测试某个提交或范围一节，可以针对你当前不在的提交运行工作流。 每个提交都会以分离（detached）方式检出到一个一次性 worktree，位于系统 临时目录下；act 在那里运行，无论运行如何结束，worktree 都会被删除——你的 工作区和分支永远不会移动。由于这份检出天生就是干净的，判定总能钉在它所测试 的提交上。在图中右键点击某个提交，可以直接选择在此提交上运行本地 CI。
代价在任何东西运行之前就会说明，而不是事后才发现：输入一个修订或范围
（main..HEAD、HEAD~5..、某个 sha），按下预览，Gitcito 会显示该表达式
匹配多少个提交，以及实际会运行的最新 N 个——这是明确的预算，上限为 50。
批量运行会依次执行这些提交（act 加上 Docker 足够重，并行运行会争抢
机器资源），实时流式输出每次运行的日志，逐个实时标记每个提交的通过/失败，
而停止会在提交之间中止，同时终止正在进行的那一次。每个提交都要按实打实
的几分钟来预估。
还有一个值得了解的局限：一次性 worktree 里只有该提交的文件，没有你仓库的 子模块检出——依赖已初始化子模块的工作流，其表现会和在一个没有子模块的全新 克隆上一样。
局限
- act 是对 GitHub 运行器非常出色的模仿，但并不完美：需要 GitHub 托管服务、 密钥或特殊运行器镜像的 action 可能表现不同。本地的绿灯是有力的证据， 不是保证。
- 每个仓库同一时间只能有一次运行；启动新的运行会取消前一次。
- 只支持按工作流运行——挑选单个作业、矩阵或事件是 act 的地盘；需要传参数时， 请在集成终端里运行它。
- 首次运行会下载运行器镜像——第一次会慢一些。