DEV Community: Wen Ping

从 GitLab 迁到 AngusGit：迁移清单、双跑和回滚

Wen Ping — Sat, 31 Oct 2026 04:11:14 +0000

这篇讲团队从 GitLab 整体切到 AngusGit 时，怎么保证切换那天不丢代码、出了问题能退回去。看完你可以按准备、首次同步、双跑、切换日、回滚五个阶段逐项验收，并给 GitLab 留两周只归档、不删除的回滚窗口。

先登录 AngusGit。GitLab 路径 platform/backend/order-service 只有两级可放：拿不准，或不同子组下有同名项目时，把子组并进仓库名，写成 platform/backend-order-service。仓库名里的点号改成连字符，例如 docs.site 改成 docs-site。在 设置 → 团队 点 新建团队，团队标识 沿用 GitLab 组的英文名。侧栏 仓库 → 新建仓库，添加 README 文件、添加 .gitignore、选择许可证 都不要勾，否则推送会被拒绝。

到 我的 → 访问令牌 点 生成新令牌，密码验证 填当前登录密码。同步脚本用一把勾了 git:write、仓库权限 WRITE 的令牌。Jenkins 只读拉代码另生成一把，只勾 git:read、仓库权限 READ。用户名都是 AngusGit 登录名，密码填令牌，生成后马上复制。先手动成功推一个仓库，在系统凭据窗口里保存，再跑脚本。

把对应关系写成 repos.txt，每行两列，先 GitLab 路径，再「所有者/仓库名」：

platform/backend/order-service platform/backend-order-service

然后执行（域名换成你的）：

while read -r src dst; do
  git clone --bare "https://gitlab.example.com/${src}.git" tmp.git || continue
  git -C tmp.git branch -m master main 2>/dev/null
  git -C tmp.git push "https://git.anguskit.com/${dst}.git" --all
  git -C tmp.git push "https://git.anguskit.com/${dst}.git" --tags
  rm -rf tmp.git
done < repos.txt

每个仓库用下面的命令对比，没有意外输出才算一致。master 改成 main 时，这一对名字不同是预期的：

diff \
  <(git ls-remote --heads --tags https://gitlab.example.com/platform/backend/order-service.git | sort) \
  <(git ls-remote --heads --tags https://git.anguskit.com/platform/backend-order-service.git | sort)

分支保护要等切换日最后一次同步之后再开。进入仓库 设置 → 分支保护，点 添加规则，分支名称 选盘点表里的分支（通常是 main）。打开 需要代码评审，必需的评审人数 填 GitLab 上记下的人数；打开 对管理员同样生效；允许强制推送 和 允许删除 保持关闭。同步期间不要开，否则脚本推 main 会被拒绝。

1. 这一轮只迁仓库

GitLab 上不只有代码，还有合并请求、议题、CI 流水线和各种集成。一次全部切走，任何一块出问题都会拖住整个迁移。建议分期：

期次	内容	说明
本轮	Git 仓库、成员权限、分支保护、Webhook	切换完成后，团队在 AngusGit 上提交、评审和合并
下一轮	CI	本轮先让现有构建能被 AngusGit 触发，下一轮再决定是否改写流水线
另行安排	议题、Wiki	这些在 GitLab 的数据库里，不在 Git 仓库中，推送带不过来

CI 虽然放到下一轮，切换日之前也必须有着落。GitLab 不再收到推送之后，GitLab CI 也就不会再触发。本轮最稳妥的过渡做法，是让现有的 Jenkins 任务改从 AngusGit 拉代码，并用 Jenkins 的 轮询 SCM（Poll SCM）定时检查 main 有没有新提交，例如每两分钟一次。不管代码是命令行推送进来的，还是在拉取请求页点合并进来的，轮询都能发现。Jenkins 拉代码用开头那把只读令牌：只勾 git:read，仓库权限 READ，用户名填登录名，密码填令牌。

2. 准备：先盘点

迁移前把下面每一项都查一遍，结果写进一张表。切换日的每一步都要用到它。

盘点项	在 GitLab 上怎么查	记下什么
仓库清单	各群组的项目列表	路径、可见性（谁能看到仓库）、默认分支名、大致大小，以及在 AngusGit 上对应的「团队/仓库名」
成员和角色	群组和项目的成员页	每个人在每个仓库要读还是要写，谁是维护者
受保护分支	项目设置 → 仓库 → 受保护分支	哪些分支禁止直接推送、合并前要几个人批准
CI	项目里的 `.gitlab-ci.yml` 和 Runner	哪些仓库有构建；切换后用什么触发
Webhook 和集成	项目设置 → Webhooks	每个 Webhook 的地址和用途，切换后要在 AngusGit 上重建
写死 Git 地址的地方	在代码里搜索 GitLab 域名	`.gitmodules`、CI 和部署脚本、依赖声明里的 Git 地址、文档里的克隆命令
进行中的合并请求	每个项目的合并请求列表	切换日之前要合并或关闭，评审记录带不过来
Git LFS	项目里有没有 `.gitattributes` 中的 `filter=lfs`	AngusGit 不支持 LFS，用到的仓库要先处理大文件

盘点表里「写死 Git 地址的地方」最容易漏。部署脚本、子模块、依赖声明里还写着 GitLab 地址，切换之后不会马上报错，要等 GitLab 下线那天才一起出问题。

3. 首次同步

在 AngusGit 建团队和空仓库 按盘点表的对应关系，建好团队和空仓库。新建仓库时三个初始化选项都不勾。
成员先只给读权限 把成员加进团队或仓库，这个阶段一律只给读取权限。双跑期间，AngusGit 上的代码只能从 GitLab 同步过来，不能有人直接往 AngusGit 推送；只给读权限，就从权限上保证了这一点。
分支保护先不开 同步脚本会直接把分支推到 AngusGit，包括 main。这时如果已经给 main 开了分支保护，同步推送会被拒绝。分支保护规则可以先整理好，等到切换日最后一次同步之后再建。
跑一次同步脚本，然后验收 执行同步脚本，把 repos.txt 里的仓库全部推过去。每个仓库都用开头的 git ls-remote --heads --tags 对比 GitLab 和 AngusGit，没有意外输出才算同步成功。master 改成 main 时，这一对名字不同是预期的。

4. 双跑：GitLab 写，AngusGit 读

双跑期间，团队照常在 GitLab 上提交、评审、合并。AngusGit 每天从 GitLab 同步一次，让团队提前熟悉新地址和新界面。

双跑只有一条规则：任何时候只有一边能写。两边都能写，代码就会分叉。分叉之后，同步推送会被拒绝，最后只能手工合并，这正是迁移最怕的情况。

这段时间可以做这些事：

用定时任务每天执行一次同步脚本，每次跑完都用 git ls-remote 对比一遍。
请几位成员从 AngusGit clone 仓库，确认 SSH 或 HTTPS 访问都没问题，访问令牌都已备好。
在一个测试仓库里，让大家把拉取请求、评审、合并完整走一遍。
新建一个测试用的 Jenkins 任务，从 AngusGit 拉代码、打开轮询 SCM，确认它能发现同步过来的新提交并开始构建。

5. 切换日

切换日按下面的顺序做，每一步做完再做下一步。

提前通知冻结时间 至少提前一天通知全员：几点开始停止向 GitLab 推送，几点之后改用 AngusGit。进行中的合并请求，要在冻结之前合并或关闭。
冻结 GitLab 到点后，把每个项目在 GitLab 上归档（项目 设置 → 通用 → 高级 → 归档项目）。归档后项目变成只读，任何人都推不上去，代码和合并请求记录都还在。
最后一次同步并对比 执行同步脚本，然后对每个仓库跑一遍 git ls-remote 对比。全部一致才往下走；有不一致的，先查清楚是哪个分支、为什么。
打开 AngusGit 的写权限和分支保护 按盘点表把成员的权限从只读改成读写，再在每个仓库的 设置 → 分支保护 里按开头添加规则：打开 需要代码评审 并填上盘点的人数，打开 对管理员同样生效，允许强制推送 和 允许删除 保持关闭。
切换 CI 和集成 把 Jenkins 任务的源码地址改成 AngusGit，打开轮询 SCM，再推一个测试提交，确认构建被触发。盘点表里的其他 Webhook，在 AngusGit 仓库的 设置 → Webhooks 里重建。
通知全员改地址 每个人在自己的本地仓库里执行一次 git remote set-url origin <AngusGit 地址>，然后 git fetch 确认能拉取。双跑期间直接从 AngusGit clone 的人，不需要改。

切换日结束前，还要按盘点表把写死 GitLab 地址的地方，逐个改成 AngusGit 地址并提交。

6. 回滚

GitLab 上的项目只归档，不删除。从切换日起留一个回滚窗口，例如两周。窗口内如果遇到无法马上解决的问题，例如权限大面积出错、构建全部断掉，可以退回 GitLab。

回滚时，AngusGit 上已经有了切换后的新提交，要先把它们带回 GitLab：

冻结 AngusGit 通知全员停止向 AngusGit 推送，把成员权限改回只读。
取消 GitLab 归档 GitLab 上归档的项目拒绝推送，先在项目 设置 → 通用 → 高级 里取消归档。
把新提交推回 GitLab 迁移时把 master 改成了 main 的，先把它改回 master；GitLab 在冻结之后没有新提交，这次推送是普通的追加，不需要强制推送。
对比后通知全员改回地址 用 git ls-remote 对比两边一致后，通知全员把 origin 改回 GitLab 地址，CI 也切回 GitLab。

回滚时用 git clone --bare 得到一份只存 Git 数据、没有可编辑工作区的副本，再推回 GitLab：

git clone --bare https://git.anguskit.com/platform/backend-order-service.git
cd backend-order-service.git
git branch -m main master
git push https://gitlab.example.com/platform/backend/order-service.git --all
git push https://gitlab.example.com/platform/backend/order-service.git --tags

回滚窗口结束、确认不再需要 GitLab 之后，再按公司的数据保留要求处理 GitLab 上的项目。

7. 出错时

你看到的	原因	怎么处理
双跑期间同步推送 `main` 被拒绝	AngusGit 上已经给 `main` 开了分支保护	先删掉这条保护规则，等切换日最后一次同步之后再建
同步推送 `! [rejected] … (non-fast-forward)`	有人在双跑期间直接往 AngusGit 推了代码，两边分叉	找到这条提交，确认是否需要保留。要保留的，在 GitLab 上重新提交一次；然后把 AngusGit 上的分支重置成 GitLab 的版本。同时检查成员权限是否真的只读
切换日对比有差异	冻结之前有推送没赶上同步，或者同步中途断开	再执行一次同步脚本，直到对比一致
切换后部分构建不再触发	Jenkins 任务的源码地址还是 GitLab，或者没打开轮询 SCM；构建脚本里还写着 GitLab 地址	对照盘点表逐个改 Jenkins 任务和脚本里的地址
切换后有人推送报 `repository '…' not found`	本地 `origin` 改错了，团队名或仓库名和对应规则不一致	从 AngusGit 仓库页的代码按钮复制地址，重新 `git remote set-url`

常见问题

能不能让 GitLab 和 AngusGit 一直双向同步，慢慢切？

不建议。两边都能写，就一定会在某个时候分叉。分叉后由谁来合并、以哪边为准，都很难说清。双跑期间只保留一个写入方，切换就是一个明确的时间点。

几十个仓库要一天切完吗？

不必。可以按团队或业务线分批，每批走一遍第 5 节。但同一批里互相依赖的仓库，例如主仓库和它的子模块，要放在同一天切。

合并请求的讨论记录怎么办？

带不过来。重要的设计讨论，在 GitLab 归档前导出或整理成文档，放进仓库的 docs 目录；进行中的合并请求，冻结前合并或关闭。

切换后，CI 什么时候迁？

本轮先让 Jenkins 改从 AngusGit 拉代码，现有构建继续工作，等团队适应了新的仓库和评审流程，再单独安排一轮评估。AngusGit 团队版和企业版自带流水线，新建流水线时可以选 导入 GitLab CI，从 .gitlab-ci.yml 生成初稿。社区版没有 CI/CD 菜单。

小结

从 GitLab 迁到 AngusGit，本轮只迁仓库，CI 和议题另排。先盘点仓库、成员、受保护分支、CI、Webhook 和写死 Git 地址的地方。首次同步之后进入双跑：GitLab 是唯一能写的一边，AngusGit 只读、每日同步。切换日按顺序做：冻结 GitLab，最后同步，对比一致，然后打开写权限和分支保护，切换 CI，通知全员改地址。GitLab 项目只归档不删除，回滚窗口内需要退回时，把 AngusGit 的新提交推回 GitLab，再取消归档。

结论： 批量迁移期间必须保持「单边可写」：双跑期只写 GitLab、每日单向同步到只读的 AngusGit；切换日先归档冻结 GitLab 并用 git ls-remote 对齐全部引用后，再开启 AngusGit 的写权限与分支保护。

参考文章

GitLab CI 迁到内置流水线：YAML 怎么改写

Wen Ping — Sat, 31 Oct 2026 04:10:38 +0000

这篇讲怎么把 .gitlab-ci.yml 用 导入 GitLab CI 转成 AngusGit 流水线，以及保存前要改什么。看完你可以对照未映射清单和注意清单，处理转不过去的 artifacts、rules 和 when，补上分支限制，避免部署在没人点击时就自动跑；导入不会替你新建凭证。

AngusGit 的流水线在团队版和企业版中提供，社区版没有 CI/CD 菜单。如果你还没写过 AngusGit 的流水线，建议先看文末参考里的 YAML 入门一文，了解 Job（流水线里的一组步骤）、运行器（Runner，真正执行任务的那台机器）这些基本概念。

1. 一份用来转换的 .gitlab-ci.yml

下面这份配置专门用来演示转换，并不是哪个线上仓库正在使用的文件。它分三个阶段：先构建，再测试，最后在 main 分支上手动触发部署。

stages:
  - build
  - test
  - deploy

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2"

build:
  stage: build
  image: maven:3.9-eclipse-temurin-21
  tags: [docker]
  script:
    - mvn -B -DskipTests package
  artifacts:
    paths: [target/*.jar]

test:
  stage: test
  image: maven:3.9-eclipse-temurin-21
  tags: [docker]
  script:
    - mvn -B test
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH == "main"'

deploy:
  stage: deploy
  tags: [deploy]
  script:
    - ./deploy.sh $CI_COMMIT_SHORT_SHA
  when: manual
  only: [main]

2. 用控制台导入，先拿到初稿

打开导入对话框 进入 CI/CD → 流水线，点 新建流水线。菜单里有 空白创建、根据仓库生成、导入 GitHub Actions、导入 GitLab CI 四项，后两项下面都有一行小字「部分语法自动转换，导入后请校验」。这里选 导入 GitLab CI。
粘贴内容并转换 对话框标题是 导入 GitLab CI，说明文字是「子集映射为 AngusCICD YAML。include / 完整 rules / child pipeline 不会展开，请看未映射清单。」也就是说，只有一部分语法会被转换。默认页签是 粘贴 YAML（旁边还有 扫描仓库），输入框的名称是 GitLab CI，提示文字是「粘贴 .gitlab-ci.yml 内容」。把第 1 节的整段 YAML 贴进去，点转换。
看两份清单 转换结果显示在输入框下方，从上到下依次是 未映射（需人工改）、注意、流水线名称，最后是 YAML 编辑器。流水线名称会自动填成 imported-from-gitlab（输入框占位文字是「输入流水线名称」）。
核对清单后再创建 从流水线列表打开时，对话框右下角的按钮是 创建流水线；从空白创建页打开同一个对话框时，这个位置是 填入编辑器。如果清单里的问题还没改完，点取消即可，仓库里不会留下流水线。

转换完成后，对话框中间会滚到两份清单（更上方的粘贴框可能被滚出视野），标题、说明和右下角的取消、创建流水线 仍在。清单内容如下，四条未映射是：

jobs.build.artifacts
jobs.test rules/only/except（仅用于推断触发器；完整条件未映射）
jobs.deploy rules/only/except（仅用于推断触发器；完整条件未映射）
jobs.deploy.when

三条注意是：

jobs.deploy 无 image，映射为 NATIVE
CI_COMMIT_SHORT_SHA → commitSha（完整 SHA，不是短 SHA）
GitLab CI_* 预定义变量已近似改写；其余 CI_* 运行时不会注入

第一条注意里的 NATIVE，和下面初稿里的 DOCKER，是 AngusGit 的两种执行模式：DOCKER 在指定镜像启动的容器里执行命令，NATIVE 直接在运行器所在的机器（宿主机）上执行。转换成功的项不会逐条列出，编辑器里生成的初稿如下：

version: '1'
name: imported-from-gitlab
triggers:
- 'on': push
- 'on': pull_request
env:
  MAVEN_OPTS: -Dmaven.repo.local=.m2
pipeline:
  build:
    runner:
      mode: DOCKER
      image: maven:3.9-eclipse-temurin-21
      labels:
      - docker
    steps:
    - name: script
      run: mvn -B -DskipTests package
  test:
    runner:
      mode: DOCKER
      image: maven:3.9-eclipse-temurin-21
      labels:
      - docker
    steps:
    - name: script
      run: mvn -B test
    needs:
    - build
  deploy:
    runner:
      mode: NATIVE
      labels:
      - deploy
    steps:
    - name: script
      run: ./deploy.sh ${{ commitSha }}
    needs:
    - test

初稿里的 'on' 带引号，是因为 YAML 会把不加引号的 on 当成布尔值，导出时特意加了引号来避开。这是转换后的初稿，保存前还必须处理未映射项。

3. 对照表：哪些转了，哪些没转

先看能自动转换的部分。其中最需要理解的是 stages：GitLab CI 用阶段来排先后，AngusGit 没有阶段，改为让后一个 Job 用 needs 声明它要等哪个 Job 完成。

导入会自动转过去的：

GitLab CI	初稿里的样子	说明
`script`	步骤名 `script`，命令在 `run`	单行脚本的步骤名就是 `script`
`image`	`runner.mode: DOCKER` 加 `runner.image`	镜像名原样保留，仍是 `maven:3.9-eclipse-temurin-21`
没写 `image`	`runner.mode: NATIVE`	例如 `deploy`，注意里写了「jobs.deploy 无 image，映射为 NATIVE」
`tags`	`runner.labels`	`docker`、`deploy` 原样变成标签
`variables`	流水线级 `env`	`MAVEN_OPTS` 写在了顶层 `env`
`stages`	后一个阶段的 Job 写 `needs`	`test` 依赖 `build`，`deploy` 依赖 `test`。`stages` 本身不保留
`rules` 里的合并请求	触发器多了一条 `pull_request`	完整的 `if` 没有写进 Job
`allow_failure`	`continue-on-error`	这份示例里没有
`environment`	只保留环境名称	这份示例里没有。有的话，注意会写「只保留名称，无 GitLab environment 保护规则」

接下来是没转过去的部分。下表先列出要点，表后再逐条展开。

这份示例没转过去、保存前要处理的：

你在清单里看到的	初稿实际做了什么	保存前怎么改
`jobs.build.artifacts`	`target/*.jar` 不会传给后面的 Job	本例可先不改
`jobs.test` 和 `jobs.deploy` 的 `rules` / `only`	只用来推断触发器，`main` 没变成 `branches`	给触发器补上 `branches: [main]`
`jobs.deploy.when`	丢掉了 `when: manual`，`deploy` 仍在且 `needs: [test]`	删掉 `deploy` 另建一条，或加 `approval`
`include`、`retry`、`timeout`、`dependencies`、`trigger`	本例没有，出现时会进未映射清单	见表后说明

artifacts（构建产物）：这份示例的 test 自己会再跑一遍 mvn test，不读那个 jar，所以两个 Job 可以先保持原样。如果下游脚本要读上一个 Job 生成的文件，就把相关步骤并进同一个 Job，或者先上传到制品库再下载。
rules / only：初稿里的 push 和 pull_request 都没有 branches: [main]。不改的话，其他分支也会触发这条流水线，而且 deploy 会跟着运行。
when：when: manual 被丢掉后，部署会在每次触发时自动执行。不想自动部署，就把 deploy 从这条流水线里删掉，另建一条用 workflow_dispatch（只能手动运行）触发的流水线，或者给这个 Job 加 approval（审批）。
其他字段：用了 include 的，要先把被引用的片段合并进一份 YAML 再导入；Job 级的 retry、timeout 要改写到步骤上，单位是秒；用 trigger 触发的下游流水线要拆开单独处理。

定时任务也能导入，但 cron 要自己补。 cron 是描述定时规则的表达式。GitLab 的定时规则配置在页面上，不写在 YAML 里。所以，YAML 里如果有 only: schedules，或者 rules 的条件里写了 schedule，导入会加上 on: schedule，同时在未映射里写明「schedule cron 未映射（GitLab 定时在 UI，不在 YAML）」。这时 cron 要你自己补上，格式是五段式，例如 0 2 * * *。第 1 节的示例没有定时，所以初稿里也没有 on: schedule。

4. CI_* 变量要特别检查

GitLab 运行时会自动提供一批以 CI_ 开头的预定义变量，AngusGit 不会注入它们。导入时只会把下表这几个改写成 ${{ }} 表达式，并不会改成环境变量 GIT_COMMIT_SHA：

GitLab 变量	导入后	这份示例
`$CI_COMMIT_SHA`	`${{ commitSha }}`	示例脚本里没有
`$CI_COMMIT_SHORT_SHA`	同样是 `${{ commitSha }}`，完整 SHA	`deploy` 命令变成 `./deploy.sh ${{ commitSha }}`
`$CI_COMMIT_BRANCH`	`${{ branch }}`	只在 `test` 的 `rules` 里，那条 `if` 没写进 Job
`$CI_PIPELINE_SOURCE`	`${{ event }}`	同样只用来推断出 `pull_request`
`$CI_COMMIT_TAG`	`${{ ref }}`	本例没有，出现时注意写「CI_COMMIT_TAG → ref（近似）」

其中 $CI_COMMIT_SHORT_SHA 最容易出错。注意原文是 CI_COMMIT_SHORT_SHA → commitSha（完整 SHA，不是短 SHA），也就是说，改写后拿到的是完整的提交号。如果你要 8 位短 SHA，就在 shell 里自己截取 $GIT_COMMIT_SHA，不要以为 ${{ commitSha }} 已经是短的。

表外的其他 CI_ 变量，例如 CI_PROJECT_DIR、CI_PIPELINE_ID、CI_REGISTRY，运行时都不会注入。只要原文有变量被改写过、又还留着 CI_ 变量，注意里就会有这一句：「GitLab CI_* 预定义变量已近似改写；其余 CI_* 运行时不会注入」。自己写的脚本可以改用平台提供的环境变量 GIT_REPO_URL、GIT_BRANCH、GIT_COMMIT_SHA。

还有一类变量要留意：名字以 TOKEN、SECRET、PASSWORD、PASSWD、PRIVATE_KEY、ACCESS_KEY 或 API_KEY 结尾时，导入会把这个名字写进 Job 的 secrets 名单，并在注意里写「$名字 → env.名字，并写入 Job secrets 名单」。这时 AngusGit 里必须先有同名凭证，否则 Job 会失败并提示 Credential not visible or expired。导入不会替你创建凭证，要自己在 CI/CD → 配置 → 凭证 里新建。第 1 节没有这类变量，所以初稿里没有 secrets。

5. 保存前建议改成什么样

这份初稿不能直接保存，因为有两处和原配置的意思相反：一是 only: [main] 没有变成 branches: [main]，其他分支也会触发；二是 when: manual 丢了，deploy 仍会在 test 之后自动运行。

建议把它拆成两条流水线。第一条保留构建和测试，并补上分支限制。镜像先沿用转换结果；如果内网拉不到 Docker Hub，再把 maven:3.9-eclipse-temurin-21 换成平台镜像 repo.anguskit.com/docker-public/angus-ci-maven:21。下面是手动改完后的写法，并非导入器直接给出的初稿：

version: "1"
name: imported-from-gitlab
triggers:
  - "on": push
    branches: [main]
  - "on": pull_request
    branches: [main]
env:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2"
pipeline:
  build:
    runner:
      mode: DOCKER
      image: maven:3.9-eclipse-temurin-21
      labels: [docker]
    steps:
      - name: script
        run: mvn -B -DskipTests package
  test:
    needs: [build]
    runner:
      mode: DOCKER
      image: maven:3.9-eclipse-temurin-21
      labels: [docker]
    steps:
      - name: script
        run: mvn -B test

注意 needs 只决定先后顺序，不会把 target/*.jar 传给 test。这里之所以还能分成两个 Job，是因为 test 自己执行 mvn test，用不到那个 jar。如果部署脚本要读这个 jar，就把打包和部署写成同一个 Job 里的两个步骤。

第二条流水线只放部署，并且只允许手动运行。脚本参数里的 ${{ commitSha }} 仍然是完整 SHA。建议写成：

version: "1"
name: deploy
triggers:
  - "on": workflow_dispatch
pipeline:
  deploy:
    runner:
      mode: NATIVE
      labels: [deploy]
    steps:
      - name: script
        run: ./deploy.sh "${{ commitSha }}"

如果希望部署仍然跟在构建后面，但要由指定的人批准后才继续，就给这个 Job 加 approval；已经被丢掉的 when: manual 起不到这个作用。具体做法见文末参考里的流水线审批一文。

6. 真要保存时先验证一次

改完之后，按下面三步把流水线建起来并验证：

通过运行前检查 如果对话框是从列表打开的，点 创建流水线；如果是从空白创建页打开的，先点 填入编辑器，再在创建页保存。保存前平台会做运行前检查：通过时页面显示「检查通过，可以保存。」；提示「请先修复错误」时，按提示修改。最常见的原因是 YAML 里还留着 stages、variables 这类 GitLab 字段。
手动跑一次 在流水线详情页点触发，分支 / 标签 填一个测试分支，然后确认 Job 被带 docker 标签的运行器接走。要小心：如果 deploy 还留在同一条流水线里，这次运行就会真的执行部署命令。
再看自动触发 手动运行通过后，再发起一个拉取请求，确认 pull_request 能正常触发，并且结果写回了拉取请求页的状态检查（页面上标明流水线是否通过的那一项）。

迁移期间，.gitlab-ci.yml 可以先留在仓库里，AngusGit 不会执行它。等新的流水线稳定运行之后再删除。

常见问题

迁移后最常遇到的情况如下：

你看到的	原因	怎么处理
Job 一直排队	没有在线的运行器同时满足 `mode` 和 `labels`	运行器要带 `docker` 标签，并能跑对应的执行模式
Job 没在容器里，直接跑在宿主机上	原 Job 没有写 `image`，变成了 `NATIVE`	补上 `runner.mode: DOCKER` 和 `runner.image`
后面的 Job 找不到 `target/*.jar`	`artifacts` 在未映射里，`needs` 不传文件	合成一个 Job，或经制品库中转
部署在没人点击时就跑了	`when: manual` 未映射，Job 仍在流水线里	删掉这个 Job，或改成 `workflow_dispatch` / `approval`
非 `main` 的分支也跑了部署	`only: [main]` 没有写成 `branches`	给 `push` 和 `pull_request` 加上 `branches: [main]`
脚本里某个路径或编号是空的	用了没有注入的 `CI_*` 变量	按第 4 节替换，短 SHA 用 `$GIT_COMMIT_SHA` 自己截
合并进 `main` 后没有自动构建	拉取请求页的合并不会触发 `on: push`，只有 `git push` 会	用 `pull_request` 在合并前跑构建和测试

能不能一次导入多个文件？

不能，对话框一次只处理一份 YAML。如果项目用了 include（在一份 YAML 里引用其他 YAML 片段），要先把被引用的文件合并成一份再导入，否则未映射里会写「include（不拉取远程/本地片段，须先展开再导入）」。

转换结果能不能直接用？

这份示例的初稿不能直接用，因为 deploy 会自动运行，分支限制也丢了。先按第 5 节改好这两处，再保存。

小结

把 .gitlab-ci.yml 贴进 导入 GitLab CI 再点转换，得到的是一份需要人工核对的初稿，本例名为 imported-from-gitlab，其中 script、image、tags、variables、stages 分别转成了步骤、DOCKER 模式、标签、env 和 needs。以第 1 节为例，未映射的是 jobs.build.artifacts、两处 rules/only/except 和 jobs.deploy.when；注意清单则提醒 deploy 变成了 NATIVE，$CI_COMMIT_SHORT_SHA 变成了完整的 ${{ commitSha }}。最要紧的是，when: manual 不会变成手动 Job，only: [main] 也不会变成分支限制，不改的话部署会在其他分支上自动运行。所以要逐项核对、改完再创建流水线，并自己建好需要的凭证，因为导入不会新建凭证。

结论： 导入 GitLab CI 给出的只是转换后的初稿，保存前要处理未映射的 artifacts 和 when，把丢掉的 only: [main] 补成触发器上的 branches: [main]，并记住 ${{ commitSha }} 拿到的是完整 SHA，不是短 SHA。

参考文章

Issue 怎么关联合并请求：写上 Closes #编号，合并后自动关闭

Wen Ping — Sat, 31 Oct 2026 04:10:01 +0000

这篇讲怎么让问题和拉取请求连上，并在合并后自动关闭问题。看完你可以在拉取请求的标题或描述里写 Closes #编号，刷新后确认两边页面互相列出对方；关键字要用英文，写在评论里或只写 #编号 不会生效。

下文用线上仓库 xlliu/test-pr-example。问题 #4 标题是「折扣示例没有说明空购物车」，类型是功能。拉取请求 #9 从 feature/link-empty-cart 合向 main，描述里写了 Closes #4。两条都还开着，页面上是合并前的样子。

1. 先认清编号

AngusGit 界面上把 Issue 叫作问题，侧栏里的入口和仓库代码页的页签都叫这个名字。

问题按仓库单独编号，从 #1 开始递增。拉取请求也按仓库单独编号，两套编号互不相干，所以同一个仓库里可以同时有问题 #1 和拉取请求 #1。下文写的 Closes #4，指的都是问题的编号，不是拉取请求 #4。

2. 建一条问题，记下编号

已经有问题的话，打开它，记下标题旁边的编号，跳到第 3 节。

打开新建表单 侧栏点问题，在右上角点 新建问题。页面标题是 创建新问题。
填写仓库选 xlliu/test-pr-example。类型选 Bug、功能、问题或增强中的一个，创建后不能修改。这条示例选的是功能，标题是「折扣示例没有说明空购物车」。描述写清缺了什么。标签、指派人可以先不填。
创建点 创建问题，提示 问题创建成功。打开这条问题，标题旁边的 # 加数字就是它的编号。这条示例是 #4。

3. 在拉取请求里写上关键字

修好代码、推到一个新分支之后，按平常的方式发起拉取请求。在标题或描述里，写上关键字加问题编号：

docs: 说明空购物车不计算折扣

Closes #4

#9 的描述就是这两行。关键字和编号之间要有一个空格。下面九个关键字都可以，大小写不限，效果完全一样：

词根	可用的英文写法	示例
close	`close`、`closes`、`closed`	`Closes #4`
fix	`fix`、`fixes`、`fixed`	`Fixes #4`
resolve	`resolve`、`resolves`、`resolved`	`Resolves #4`

一次关闭多个问题时，每个编号前面都要写关键字，例如 Fixes #4, fixes #5。写成 Fixes #4, #5 的话，只有 #4 会被关闭。#5 在这里只说明写法，这个仓库里没有问题 #5。

写在不同地方，效果不一样：

写在哪里	两边页面会互相列出	合并后自动关闭
拉取请求的标题或描述	会	会
拉取请求里某个提交的提交说明	不会	会
拉取请求或问题下面的评论	不会	不会
只写 `#4`，前面没有关键字	不会	不会
中文「关闭 #4」「修复 #4」	不会	不会
写成 `owner/other-repo#4` 这种带仓库名的引用	不会	不会

最稳的做法是写在拉取请求的描述里：合并前就能在页面上确认两边已经连上，不用等到合并那一刻才知道。

4. 合并之前，确认两边已经连上

关联是页面打开时根据标题和描述实时算出来的，保存描述之后刷新页面就能看到。

拉取请求页 会出现 关联的 Issue 一栏，列出 #4 和它的标题，旁边标着 合并后将关闭。

问题页 会出现 关联的 Pull Request 一栏，列出这条拉取请求，状态是打开。

两边都没出现时，回到描述里检查关键字是不是拼对了、和 # 之间有没有空格、编号是不是这个仓库的问题。把描述里的关键字删掉，关联也会随之消失，不用另外解除。

5. 合并之后，问题自动关闭

拉取请求满足合并条件后，点 合并拉取请求。确认框里会多出一行 合并该 PR 后将自动关闭以下 1 个 Issue：，下面列着 #4。点 确认合并。

这条示例没有合并，所以问题 #4 和拉取请求 #9 现在都还是打开。合并完成后打开问题 #4，页面会变成：

状态变成 已关闭，关闭原因是 已完成。
时间线里多出一条「某某关闭了此问题」，「某某」是点合并的那个人。
关联的 Pull Request 里，那条请求的状态变成 已合并。

有两点要提前知道：

合并到任何分支都会关闭。 拉取请求的目标分支是 release 之类的非默认分支时，合并后问题同样会被关闭。如果你希望代码进了 main 才算修好，就只在合进 main 的那条拉取请求里写关键字。
合并的人不需要有关闭问题的权限。 能合并这条拉取请求，就能通过它关闭问题。

6. 没有自动关闭时

你看到的	原因	怎么处理
拉取请求页没有关联的 Issue 这一栏	标题和描述里没有能识别的关键字，例如只写了 `#4`、写了中文「关闭」，或者关键字和 `#` 连在一起	改成 `Closes #4` 这样的写法，保存后刷新页面
关键字写在提交说明里，合并前页面上看不到关联	提交说明只在合并时检查，页面上的关联只看标题和描述	这是正常的，合并后照样会关闭。想提前确认，就把关键字也写进描述
合并了，问题仍然打开	关键字写在了评论里；写的是另一个仓库的问题；或者代码是直接推送到分支的，没有经过拉取请求	只有通过拉取请求合并，并且关键字写在标题、描述或提交说明里，才会自动关闭。需要的话在问题页手动关闭
一次写了多个编号，只关了第一个	写成了 `Fixes #4, #5`，第二个编号前面没有关键字	每个编号前都写关键字。漏关的那个手动关闭
问题被提前关掉了	关键字写在了合进非默认分支的拉取请求里	在问题页点重新打开，以后只在合进 `main` 的那条请求里写关键字

常见问题

有没有手动把问题和拉取请求连起来的按钮？

没有。关联完全由拉取请求标题和描述里的关键字决定。要建立关联就写上关键字，要解除就删掉它。

只想在拉取请求里提一下某个问题，不想合并后关掉它，怎么写？

不要用关键字，写成「相关问题：#4」这样的普通文字即可。它不会出现在关联列表里，合并后也不会关闭问题。

问题自动关错了，怎么恢复？

打开问题，点 重新打开。状态回到打开，原来的评论和时间线都还在。

直接推送到 main 的提交里写 Fixes #4，会关闭问题吗？

不会。自动关闭只在拉取请求合并时发生。直接推送的提交不会触发。

手动关闭问题时可以选原因吗？

可以。在问题页点关闭，在 请选择关闭原因 里选 已完成 或 不计划实施，再点 确认关闭。自动关闭的原因固定是 已完成。

小结

让问题和拉取请求连上，只需要在拉取请求的标题或描述里写一句英文关键字加编号，例如 Closes #4。写好之后先刷新页面，确认拉取请求页的 关联的 Issue 里标着 合并后将关闭。合并之后，问题自动关闭，原因记为 已完成，时间线写明是谁合并的。中文关键字、只写编号、写在评论里，或者直接推送代码，都不会触发关联和自动关闭。

结论： 在拉取请求的标题或描述里写 Closes #编号（或 Fixes #编号、Resolves #编号），两边页面就会互相列出关联，并在拉取请求合并后自动把问题置为 已关闭（已完成）。

参考文章

导入 Git 仓库：填一个源地址，拿到默认分支的代码

Wen Ping — Sat, 31 Oct 2026 04:09:24 +0000

这篇讲只用一个源地址把公开仓库导入 AngusGit 时，会得到什么，以及什么时候该改用推送。看完你可以填写 导入仓库 完成导入，并知道结果只有默认分支当时的文件和一条新提交；源仓库是私有的，或要保留完整历史、其他分支和标签，就先建空仓库，再用 git clone --bare 推送。

先登录 AngusGit。导入在侧栏仓库右上角的 导入仓库。要克隆导入后的私有仓库，或改用推送保留历史，先准备凭据。走 SSH：本机没有 ~/.ssh/id_ed25519.pub 时执行 ssh-keygen -t ed25519 -C "you@example.com"，路径直接回车，再 cat ~/.ssh/id_ed25519.pub，把以 ssh-ed25519 开头的一整行贴到 我的 → SSH密钥 的 添加SSH密钥。地址用 ssh://git@主机:2222/所有者/仓库.git，用户名是 git。走 HTTPS：到 我的 → 访问令牌 点 生成新令牌，密码验证 填登录密码。只克隆勾 git:read、仓库权限 READ；要推送则勾 git:write、权限 WRITE。生成后马上复制。用户名填 AngusGit 登录名，密码填令牌。

文中以 git.anguskit.com 上的一次真实导入对照：源地址是 https://github.com/octocat/Hello-World.git，所有者是当前账号 Angus / xlliu，仓库名是 hello-world-import，并打开了 设为私有仓库，导入完成后代码页地址是 https://git.anguskit.com/code/xlliu/hello-world-import。

这台实例上已有的 anguskit/AngusRepo 是制品库产品自己的仓库，并不是从 GitHub 导入的快照，不要用它的名字再导入一次，否则会提示 仓库「anguskit/AngusRepo」已存在。

1. 导入会带过来什么

动手之前，先弄清导入会得到什么，再决定用导入还是推送。下表前两列是导入的规则，最后一列是 Hello-World 导入后的实际表现，可以对照着看。

内容	是否带过来	Hello-World 的表现
源仓库默认分支当前的全部文件	带过来	只有 `README`，13 B，内容是 `Hello World!`
原来的提交历史	不带	只有 1 条提交，说明是 `Initial commit from https://github.com/octocat/Hello-World.git`，短哈希 `25861fe`
默认分支以外的分支	不带	页签是分支 1，名字是 `main`
标签（Tag）	不带	标签 0，发布 0
子模块（Submodule）	不带	Hello-World 没有子模块
Issue、合并请求、Wiki、CI、成员权限	不带	问题 0，Wiki 0
导入之后源仓库的新提交	不自动同步	导入是一次性操作

还有一处细节：Hello-World 在 GitHub 上的默认分支叫 master，导入后文件都在，但 AngusGit 上的分支名是平台默认的 main，不会沿用 master 这个名字。

所以，导入适合只需要代码当前版本的场景，例如拿一个开源项目做内部二次开发，或者旧仓库的历史本来就不重要。如果要保留每一次提交，或者要带上其他分支和标签，请直接看第 5 节。

2. 导入之前确认两件事

第一，源仓库要不登录就能读。 可见性决定谁能看到仓库，导入表单里没有填写源站账号或令牌的地方，AngusGit 只能以匿名身份去拉代码。因此公开仓库没有问题，私有仓库则会在提交表单时报 源仓库URL「…」无效或无法正常访问。也不要把账号或令牌拼进 URL 来绕过这个限制，因为这个地址会原样写进导入生成的提交说明，留在新仓库的历史里，所有能看到仓库的人都看得到。源仓库是私有的，请用第 5 节的推送方式。

第二，AngusGit 所在的服务器要能连上源站。 真正去拉代码的是 AngusGit 服务器，跟你自己的电脑能不能上外网无关，所以内网服务器访问不了 github.com 时，导入同样会失败。想提前确认，可以在那台服务器上执行一次 git ls-remote <源地址>，这条命令会列出源仓库的分支，能打印出来就说明网络是通的。以 Hello-World 为例，它能导进来，就说明那台服务器当时访问得到 github.com。

3. 导入一个仓库

打开导入页 在侧栏点仓库，再点右上角的 导入仓库。打开的是一整页表单，标题是 导入仓库，下方说明是「从其他版本控制系统导入现有仓库」。
填写源地址 仓库 URL 填源仓库的 HTTPS 克隆地址，以 Hello-World 为例就是 https://github.com/octocat/Hello-World.git。表单提示写着支持 Github、Gitlab、Gitee、SourceForge；如果地址不是以 https://、http:// 或 git@ 开头，输入框下方会提示 请输入正确的仓库URL。
选所有者，填仓库名称 所有者 默认是当前登录账号，下拉里还能选你担任维护者的团队；示例保留了默认的 Angus / xlliu。仓库名称 不会根据地址自动填写，需要手动输入，示例填的是 hello-world-import，输入框前面会显示命名空间前缀 xlliu /。名称只能用中文、字母、数字、连字符和下划线，输入的点号会被直接去掉。描述可以留空，示例就没有填；框里灰色的「从 GitHub 导入的仓库」只是占位文字，并不是已经填好的内容。
决定是否私有 设为私有仓库 默认是关闭的。代码只给团队内部看时，记得把它打开；示例打开了这个开关，所以导入得到的是私有仓库。
开始导入 仓库 URL、所有者 和 仓库名称 都填好之后，开始导入 按钮才能点击。点击后按钮会变成禁用状态，一直等到代码拉完；仓库较大时耗时更长，这期间不要关闭页面。导入完成后表单会自动关闭，新仓库出现在仓库列表里。Hello-World 很小，很快就回到了列表。

上图是点击 开始导入 之前的表单：描述留空，私有开关已经打开。

4. 验收：在代码页确认只有一条提交

导入完成后，打开仓库的代码页，以示例为例就是 https://git.anguskit.com/code/xlliu/hello-world-import，然后按下面几处核对。页头标着私有，统计栏依次是 分支 1、标签 0、发布 0、问题 0、Wiki 0。分支选择器显示 main，旁边写着 1 提交；这条提交的作者是 Angus，说明是 Initial commit from https://github.com/octocat/Hello-World.git，短哈希（提交号的前几位）是 25861fe。文件列表里只有一个 README，大小 13 B。

需要克隆时，点右上角橙色的代码按钮打开克隆面板，面板说明是「使用 Web URL 克隆。」其中 HTTPS 页签里的地址是：

https://git.anguskit.com/xlliu/hello-world-import.git

SSH 页签里的地址是：

ssh://git@git.anguskit.com:2222/xlliu/hello-world-import.git

因为仓库是私有的，克隆时会要求输入用户名和访问令牌。用户名填 AngusGit 登录名，密码填开头生成的令牌：只克隆用 git:read，要推送用 git:write。不要把令牌写进页面或截图。到这里验收就完成了：代码页上有一条初始提交、一个文件，就说明导入成功。

导入之后，团队应当改从 AngusGit 拉代码。原来指向 GitHub 的本地仓库，执行一次 git remote set-url origin <新地址> 就能把远程地址换成 AngusGit。不过新仓库的历史和源仓库对不上，在旧的本地副本里直接 git push 会被拒绝，所以最稳妥的做法是每个人重新 clone 一份。

5. 要保留完整历史，或者源仓库是私有的

遇到这两种情况，导入仓库 就不够用了，要改走推送：先在自己的电脑上把源仓库完整克隆下来，再推到 AngusGit 上一个新建的空仓库。这样所有分支、标签和提交历史都会一起过去。

下面命令里的目标仓库 hello-world-history 只是示意名称，推送前要先在 AngusGit 上把它建成空仓库。不要推到已经导入的 xlliu/hello-world-import：两边的历史对不上，推送会被拒绝。

在 AngusGit 建一个空仓库 按「新建仓库」的步骤建一个仓库，添加 README 文件、添加 .gitignore、选择许可证 三项都不要勾选，这样建出来的才是空仓库。勾选任何一项，推送都会因为两边历史对不上而被拒绝。建好后复制这个空仓库的地址。
把源仓库完整克隆到本地 git clone --bare 得到的是一个裸仓库：它只保存 Git 的数据，也就是全部分支、标签和提交历史，不生成可以直接编辑的工作区文件，正适合原样转推。源仓库是私有的，这一步会要求你登录源站。
主分支不叫 main 时先改名 AngusGit 空仓库的默认分支是 main，而 Hello-World 的主分支叫 master，所以先在裸仓库里执行 git branch -m master main 改名。源仓库的主分支已经叫 main 时，跳过这一步。
推送所有分支和标签 --all 推送所有分支，--tags 推送所有标签。示例用的是 SSH 地址；改用 HTTPS 地址也可以，这时密码一栏填 AngusGit 的访问令牌。令牌只保存在你自己的密码管理器里。

git clone --bare https://github.com/octocat/Hello-World.git hello-world-history.git
cd hello-world-history.git
git branch -m master main
git push ssh://git@git.anguskit.com:2222/xlliu/hello-world-history.git --all
git push ssh://git@git.anguskit.com:2222/xlliu/hello-world-history.git --tags

推送完成后，打开 AngusGit 仓库的分支页签，应该能看到源仓库的全部分支，提交记录也和源仓库一致。SSH 公钥和访问令牌按开头准备。

6. 一次导入很多个仓库

要搬的仓库较多时，可以用仓库页右上角的 批量导入。打开后页面标题是 批量导入仓库，有 手动输入、待导入、已导入 三个页签。

在 手动输入 页签的 仓库地址列表 里每行填一个地址，选好 所有者，再点 添加到待导入列表，一次最多 100 个。批量导入和单个导入相比有三点不同：

仓库名称自动取地址的最后一段，例如 https://github.com/octocat/Hello-World.git 会导入成 Hello-World，列表里不能逐个改名。
页面上没有 设为私有仓库 开关，批量导入的仓库全部是公开的。需要私有时有两种办法：导入后到每个仓库的 设置 → 访问，在 可见性 里改成私有并点 保存可见性设置；或者改用第 3 节的单个导入，hello-world-import 就是单个导入时打开私有开关得到的。
导入在后台排队进行，提交之后可以离开页面。进度在 待导入 页签查看，每一项会依次显示 等待中、处理中，结束时显示成功或失败。成功的项目出现在 已导入 里；失败的不会自动重试，展开任务能看到原因，改好地址后重新添加即可。

除了这三点，批量导入的规则和单个导入一样：只带默认分支的文件，源仓库也必须不登录就能读。已经存在的 anguskit/AngusRepo 不要再放进列表。

7. 导入失败时

你看到的	原因	怎么处理
输入框下方请输入正确的仓库URL，开始导入点不了	地址不是 `https://`、`http://` 或 `git@` 开头，或者缺了路径	从源站仓库页重新复制 HTTPS 克隆地址
源仓库URL「…」无效或无法正常访问	地址拼错；源仓库是私有的；或 AngusGit 服务器连不上源站	先不登录在浏览器打开源仓库页，确认它是公开的；再在 AngusGit 服务器上执行 `git ls-remote <源地址>`。私有源仓库按第 5 节推送
仓库「xlliu/hello-world-import」已存在	同一个所有者下已有同名仓库，例如这个仓库已经导入过一次	换一个仓库名称。`anguskit/AngusRepo` 同样已存在，不要用它当导入目标
克隆仓库异常：…	拉取过程中出错，例如网络中途断开	看冒号后面的原因。网络问题先重试一次；仓库很大、反复中断时改用第 5 节
批量导入里某一项失败	和单个导入的原因相同	展开任务看这一项的错误信息，改好后重新添加到待导入列表

常见问题

导入之后，源仓库的新提交会同步过来吗？

不会。导入只在你点击 开始导入 的那一刻拉一次代码，之后源仓库的新提交不会自动过来。想拿到这些新提交，可以用一个新名字重新导入一次；或者改用第 5 节的推送方式，把源仓库连同新提交一起推到一个新建的空仓库。

为什么导入后只剩一条提交？

因为导入拿的是源仓库默认分支当时的文件，用这些文件在 AngusGit 上新建一个仓库并生成一条提交，原来的提交历史、其他分支和标签都不会带过来。以 Hello-World 为例，导入后只有这一条 Initial commit from https://github.com/octocat/Hello-World.git。要保留历史，请用第 5 节。

GitLab 和 Gitee 的仓库也是这样导入吗？

是的。仓库 URL 填 GitLab 或 Gitee 仓库页上的 HTTPS 克隆地址即可，步骤和规则完全一样。表单提示里列出的就是 Github、Gitlab、Gitee、SourceForge 这几家，GitBucket 等能用 Git 地址访问的平台也可以导入。

Issue 和合并请求能一起迁过来吗？

不能。导入和推送都只搬 Git 仓库里的内容，Issue 和合并请求不在其中。进行中的合并请求，建议先在源站合并或关闭再迁移；还没解决的 Issue，到 AngusGit 的问题里重新创建。

源仓库用了 Git LFS 怎么办？

Git LFS 是 Git 的大文件存储扩展，AngusGit 不支持它。导入或推送之后，LFS 管理的大文件只剩下指针文件（一小段记录文件位置的文本），原来的内容不会过来。这类文件需要改成普通文件提交，或者放到制品库里。

小结

导入仓库 适合只要代码当前版本的场景：源仓库必须公开，结果只有默认分支的文件和一条 Initial commit from …，不带历史、其他分支和标签，也不包括 Issue、合并请求和 CI。以 Hello-World 为例，它被导入成私有的 xlliu/hello-world-import，main 上只有一个 README。如果源仓库是私有的，或者要保留每一次提交、每一个分支和标签，就改走推送：先建一个空仓库，再用 git clone --bare 加 git push --all 和 --tags。推送目标必须是这个新建的空仓库，不要推到已经导入的仓库上。

结论： 导入仓库 只会把公开源仓库默认分支当时的文件做成一条 Initial commit from <源地址>（xlliu/hello-world-import 就是把 master 上的 README 落到了 main），要保留完整历史、全部分支和标签，就新建空仓库，再用 git clone --bare 加 git push --all / --tags 推送。

参考文章

GitLab 私有化部署太吃内存：只留仓库和合并请求

Wen Ping — Sat, 31 Oct 2026 04:08:48 +0000

这篇讲内网 GitLab 占着大内存、团队却只用仓库和评审时，怎么把这三件事放到更轻的 AngusGit 上。看完你可以按团队建好仓库并连同历史迁入，配好合并方式和分支保护，构建继续留在 Jenkins，制品继续留在制品仓库。

先登录 AngusGit。搬一个仓库时，在 设置 → 团队 点 新建团队，团队标识 沿用 GitLab 组的英文名。侧栏 仓库 → 新建仓库，所有者选这个团队，添加 README 文件、添加 .gitignore、选择许可证 都不要勾，否则推送会因为历史对不上被拒绝。本机没有公钥时执行 ssh-keygen -t ed25519 -C "you@example.com"，把 cat ~/.ssh/id_ed25519.pub 的那一行登记到 我的 → SSH密钥。然后执行（地址换成你的；主分支叫 master 时先在裸仓库里 git branch -m master main）：

git clone --bare https://gitlab.example.com/组/项目.git
cd 项目.git
git push ssh://git@git.example.com:2222/团队/仓库.git --all
git push ssh://git@git.example.com:2222/团队/仓库.git --tags

用户名是 git，端口是 2222。改用 HTTPS 时，到 我的 → 访问令牌 生成一把勾了 git:write、仓库权限为 WRITE 的令牌，用户名填登录名，密码填令牌。验收用下面的命令，没有意外输出就是两边一致：

diff \
  <(git ls-remote --heads --tags https://gitlab.example.com/组/项目.git | sort) \
  <(git ls-remote --heads --tags ssh://git@git.example.com:2222/团队/仓库.git | sort)

仓库多时，把 GitLab 路径和「团队/仓库名」每行一对写进 repos.txt，对每一行重复上面的克隆和推送。先手动成功推一个，并在系统凭据窗口里保存令牌，再跑循环。master 改成 main 时，这一对名字不同是预期的。

拉取请求在 GitLab 里叫合并请求（Merge Request），和 AngusGit 页面上的拉取请求是同一件事。

GitLab 占内存，是因为它的一体化安装包里带了数据库、缓存、后台任务、内置 CI、容器镜像仓库和监控等一整套组件，即使只用代码托管，这些进程也一直在后台运行。如果你们的流水线已经在 Jenkins 上跑、制品也有单独的仓库，那么用 2 核 4 GB 起步的 AngusGit 承接仓库、拉取请求和代码评审这三件事就够了。

1. 先确认：团队真的只用这三件事吗

动手之前，先花十分钟确认现有 GitLab 上哪些功能真的在用。可以对照下表逐项问一遍：

功能	在用吗	拆分后放在哪
仓库托管、推拉代码	几乎一定在用	AngusGit
合并请求、网页评审	几乎一定在用	AngusGit
Issue、里程碑	看团队习惯	AngusGit 也有，可以一起迁
GitLab CI	不一定	已经在 Jenkins 上的继续用 Jenkins
容器镜像仓库、软件包仓库	不一定	制品仓库，例如 AngusRepo
Git LFS	少数团队在用	AngusGit 不支持，这类仓库先留在原处

Git LFS 是把大文件存在仓库之外的 Git 扩展。如果 GitLab CI 和 Git LFS 这两行的答案都是「不用」，拆分会很顺利；如果团队重度依赖 GitLab CI，先看文末参考里的选型一文，评估流水线怎么处理。

2. 第一件：仓库

AngusGit 上的仓库都挂在团队下面，地址形如 ssh://git@git.example.com:2222/团队/仓库.git。所以搬仓库分三步：先建团队，再把仓库搬过来，最后让开发者改远程地址。

按现在的分组建团队 在 设置 → 团队 里 新建团队，一个团队对应 GitLab 上的一个组。团队标识 会出现在仓库地址里，建议沿用 GitLab 组的英文名，这样大家改远程地址时更好记。
把仓库连同历史搬过来 先在 AngusGit 上新建同名的空仓库，然后用 git clone --bare 从 GitLab 克隆一份完整副本（裸仓库只存 Git 数据，没有可编辑的工作区），再用 git push --all 和 git push --tags 推到 AngusGit。这样提交历史、全部分支和标签都会带过来。
让开发者改远程地址 每个人在本地仓库里执行 git remote set-url origin，把远程地址换成新地址。用 SSH 的，先在 我的 → SSH密钥 登记公钥；用 HTTPS 的，密码一栏填 我的 → 访问令牌 里生成的令牌。

命令、凭据和两边对比见开头。先手动成功推一个仓库，再对 repos.txt 里的每一行重复同样的克隆和推送。

3. 第二件：合并请求

在 AngusGit 上，合并请求叫 拉取请求，用法和 GitLab 的 Merge Request 一样：从功能分支发起，合进 main。

需要提前定下来的是合并方式。打开仓库的 设置 → 拉取请求，这里有三个开关：合并提交、压缩合并、变基合并。只打开团队约定的那一种，合并框里就只会出现这一种，避免每个人按自己的习惯选。如果还没想好选哪种：想保留每个提交，选合并提交；希望一个拉取请求在 main 上只留下一条提交，选压缩合并。三种方式的详细区别见文末参考里的合并方式一文。

4. 第三件：人工评审

评审在侧栏的评审里完成。评审人打开 待评审 里的一条拉取请求，在 文件变更 里逐个文件看差异，在需要讨论的行上留言，最后点 提交评审，选择批准、请求更改 或评论。

以还开着的 xlliu/test-cicd-example #1 为例，它的标题是「SC-02/SC-04 PR trigger verification」，状态是 待评审。页面左侧是文件树，两个文件都还没有标记为已查看；右侧展开的是 apps/service-a/src/index.js，新增了两行，目前还没有行评。点右上角的 提交评审 会弹出一个对话框，标题同样是「提交评审」，说明文字是「选择你的评审决定并添加评论」，下面有批准、请求更改、评论三个选项。选好结论、再点对话框里的 提交评审，评审才算提交；只打开对话框，状态仍然是 待评审。

到这一步，评审人批不批准还只能靠自觉。要把评审变成必须遵守的规定，需要打开分支保护，也就是给分支加上「禁止直接推送、合并前必须满足条件」的规则：

保护主分支 打开仓库的 设置 → 分支保护，给 main 添加一条规则：打开 需要代码评审，必需的评审人数 填 1，并打开 对管理员同样生效。保存之后，直接推送 main 会被拒绝，改动必须通过拉取请求、拿到批准后才能合并。
按目录指定评审人（可选） 如果不同目录由不同的人负责，就在仓库里加一个 CODEOWNERS 文件，写明每个目录的负责人。之后创建拉取请求时，系统会自动把对应的人加为评审人。

配好之后，团队每天的流程就固定为：开分支、推送、发起拉取请求、评审人批准、合并。每一项的具体设置见文末参考里的分支保护和 CODEOWNERS 两篇。

5. 不放进来的功能，交给谁

仓库、拉取请求和评审之外的功能，继续交给各自的专职系统，对应关系如下：

功能	原有系统归属	拆分后怎么处理
构建和测试	Jenkins	继续用 Jenkins，触发方式见表后说明
镜像、软件包	制品仓库	放在制品仓库里，例如 AngusRepo
大文件	Git LFS / 存储	AngusGit 不支持 Git LFS，大文件放到制品仓库或 Release 附件
统一登录	用户中心	用户和登录由 GM 管理；对接 LDAP 在 GM 企业版上配置

构建这一行要注意触发方式。Webhook 是代码有变动时自动通知外部系统的机制，而 AngusGit 的推送 Webhook 只在 git push 时发出，所以在网页上合并拉取请求之后，建议让 Jenkins 配合 Poll SCM（轮询 SCM，定时检查分支有没有新提交）来发现新代码。

这样拆分之后，每个系统各管一件事，出了问题也更容易定位是哪一边。

常见问题

拆出来之后，原来的 GitLab 怎么办？

先不要删。把 GitLab 改为只读，保留一段时间，方便回查旧的合并请求和讨论记录；确认没有遗漏后再归档。迁移期间怎么双跑（新旧平台并行一段时间，期间只让一边可写）、出了问题怎么回滚，见文末参考里的迁移清单一文。

以后又需要内置流水线了怎么办？

AngusGit 的团队版和企业版带内置流水线，换用对应的安装包即可，已有的仓库和拉取请求数据不受影响。

社区版人数不够怎么办？

社区版最多 10 个用户，超过时换用团队版或企业版，仓库、拉取请求和评审的用法都不变。

小结

GitLab 私有化部署吃内存，很多时候是因为一整套组件都在运行，而团队只用其中三件事。把仓库、拉取请求和人工评审搬到 AngusGit 上：仓库按团队建好，连同历史一起搬过来；合并方式在 设置 → 拉取请求 里统一；评审在评审里完成，再用分支保护和 CODEOWNERS 把它变成规定。构建继续交给 Jenkins，镜像和软件包放到制品仓库；以后需要内置流水线时，换用团队版或企业版即可。

结论： 只保留仓库、拉取请求和代码评审三件事时，用 2 核 4 GB 起步的 AngusGit 加 GM 就能替代重型 GitLab，构建和制品分别留给 Jenkins 和制品仓库。

参考文章

内网 Git 要留哪些操作记录：在 AngusGit 里查成员、保护和合并

Wen Ping — Sat, 31 Oct 2026 04:08:12 +0000

这篇讲安全检查或出问题后，怎么查谁加了成员、谁改了分支保护、谁合并了代码。看完你可以在侧栏动态里按活动类型筛出「谁、什么时候、做了什么」；合并方式和代码作者要回到 Git 历史里看，动态里没有的操作则去查数据库备份和服务器日志。

1. 常被问到的问题，各在哪里查

动态里的记录按活动类型分类。筛选器里的类型名称是提交、拉取请求、合并、团队、配置、分支；其中推送代码这一类，在页面上方的统计卡上写作「代码提交」。下表列出常见问题该选哪种活动类型，以及记录的文案：

问题	在动态里选的活动类型	记录长什么样
谁把某人加进了团队	团队	「添加了团队成员」；邀请还没被接受时是「邀请了成员名字」
谁把某人加进了某个仓库	团队	「添加了协作者用户名」，例如「添加了协作者 xlliu」
谁改了权限或角色	团队	仓库协作者：「更新了协作者用户名的权限」；团队：「更新了团队成员角色」
谁移除了成员或协作者	团队	「移除了团队成员」「移除了成员」「移除了协作者用户名」
谁改了或删了分支保护	配置	「设置了分支保护」或「删除了分支保护」，后面紧跟分支名
谁改了仓库设置或可见性	配置	「更新了仓库设置」「更新了仓库可见性」
谁加了、改了或删了 Webhook	配置	「创建了Webhook」「更新了Webhook」「删除了Webhook」
谁合并了某个拉取请求	拉取请求（拉取请求页本身也能查）	「合并了 Pull Request #编号」
谁往仓库推了代码	提交	一个提交是「推送了提交到」，多个是「推送了 N 个提交到」
谁删了某个分支	分支	「删除了分支」
某人最近从哪登录过	不在动态里	AngusGM 用户详情 → 登录历史，最近 10 次登录

读这张表时有几点要注意：

筛选器里的合并只记直接把一个分支合并到另一个分支的操作，文案是「将分支 A 合并到 B」，目前是 0 条。通过拉取请求合并的记录，要到 拉取请求 类型下找。
分支保护的文案和分支名之间没有空格，例如已有的一条记录是「设置了分支保护mcp-round1-locked」。
有的推送记录没有用户名，页面上显示「未知用户」。
有些文案在系统里存在，但示例实例里还没出现过：26 条团队记录里没有邀请和移除，70 条配置记录里没有删除分支保护，也没有 Webhook 相关的记录。分支类型下目前看到的是「创建了分支」后面接分支名。

2. 在「动态」里查一条记录

打开动态 在侧栏点动态，页面说明是「查看提交、评审、议题和流水线等操作记录。」，列表按时间倒序排列，最新的在最上面。
用筛选器缩小范围 用顶部的筛选器缩小范围：活动类型 按上表选对应的一类；仓库选要查的那个；用户选怀疑的操作人，不确定就留空；时间范围 可选本周、本月、本季度、本年和全部。仓库下拉一次只列出 20 个名字，要找的仓库不在里面时，先在下拉里搜索仓库名再选。也可以直接在搜索框里输入用户、仓库、分支或描述里的关键字。
看记录 配置、团队、拉取请求这几类记录，都写明了是谁、在哪个仓库、做了什么、什么时候做的。以查分支保护为例：活动类型选配置，在搜索框里输入 分支保护，时间范围选本月，结果如下图。

图中这条记录的意思是：Angus 在仓库 e2e-git01-defaults 上给分支 mcp-round1-locked 设置了保护。记录正文是「设置了分支保护mcp-round1-locked」，后面的链接文字是 branch_protection，状态是成功，时间显示为「4 天前」，对应 2026-10-22 16:36:09。如果有人删除了分支保护，文案会是「删除了分支保护」紧跟分支名；在这个筛选条件下，本月没有删除记录。

3. Git 历史能补上的信息

动态只告诉你谁合并了拉取请求，不说明用的是哪种合并方式。这时可以回到代码本身来查：Git 历史里每条提交都记录了作者（写代码的人）和提交者（把这条提交写进仓库的人），而不同的合并方式，会在 main 的历史里留下不同的痕迹：

合并方式	提交数量变化	在 `main` 的历史里看到的
合并提交	新增一条双父提交（快进除外）	说明是 `Merge pull request #N from …`
压缩合并	多条压成一条普通提交	作者是拉取请求的作者，提交者是点合并的人
变基合并	逐条重放	每条提交被重新应用到 `main` 上，提交哈希与原来不同

表里的「双父提交」是指有两个父提交的合并提交，它把 main 和源分支连在一起。「快进」是例外情况：可以快进时，Git 直接把源分支的提交接在 main 后面，不会新增这条合并提交。「逐条重放」是指把源分支上的提交一条一条重新应用到 main 上，所以提交哈希会变。

要查某个文件里的代码是谁写的、从哪个拉取请求进来的，可以运行：

git log --format='%h %an %cn %cd %s' --date=iso -- path/to/file

输出里 %an 是作者，%cn 是提交者，%cd 是提交时间。如果用的是压缩合并，作者就是写代码的人，提交者就是点合并的人；提交说明里通常带着拉取请求的标题，拿这个标题回到 AngusGit 就能找到对应的拉取请求，再去看评审记录。

拉取请求页本身也是一份记录：谁发起、谁评审、评审结论是什么、讨论过什么，都保存在那条拉取请求里。

4. 目前没有记录的地方

下面这些情况在动态里查不到。安全检查前要先弄清楚，并准备好替代材料：

情况	现状	建议
改了分支保护的哪一项	只记「设置了分支保护」，不记改前改后的具体规则	分支保护规则变更走内部审批单，写清改了什么
操作来源 IP	动态记录里没有 IP	登录看 AngusGM 登录历史；其他访问看代理日志（见表后）
强制推送	和普通推送一样记为「推送了提交到」或「推送了 N 个提交到」，不单独标出	在分支保护里关闭允许强制推送，从源头上禁止
被拒绝的推送	被分支保护拒绝的推送不进动态，只在 AngusGit 服务器日志里	需要时保留服务器日志
导出	动态不能导出	定期备份 AngusGit 的数据库
保留时长	动态目前没有自动清理设置	按公司要求定期备份；需要清理时由运维按备份策略处理
合并人和合并时间的展示	拉取请求页上不显示合并人和合并时间	看动态拉取请求类型里的「合并了 Pull Request #编号」，或看 Git 历史

关于来源 IP：登录相关的来源可以看 AngusGM 的 登录历史；如果需要更细的访问来源，要保留反向代理或负载均衡的访问日志。查合并人和合并时间时，Git 历史里的提交者和提交时间也能作为依据。

还有一处容易混淆：AngusGM 的 管理 → 日志 里也有 审计日志，但它记录的是 AngusGM 平台自己的用户操作和系统日志，不包含 Git 仓库里的操作。查 Git 相关的问题，要看 AngusGit 的动态。

5. 平时就做好这几件事

事后追查最怕的是记录本来就不存在。下面几件事建议在仓库上线时就做好：

分支保护里打开对管理员同样生效，关闭允许强制推送和允许删除。 这样历史不会被改写，主分支不会被删除，管理员也不能绕过评审。
权限尽量给到团队，少给个人协作者。 团队成员的加入和移除都记在团队类型下，比逐个翻查每个仓库的协作者清楚得多。
定期备份数据库，保留服务器日志。 动态存在数据库里且不能导出；被拒绝的推送只出现在服务器日志里。
重要的设置变更走审批单。 动态只记录「谁在什么时候改了」，审批单能补上「为什么改、改成了什么」。

常见问题

装了 AngusGit，就满足等保对代码仓库的要求了吗？

不能这么说。AngusGit 的动态只能提供一部分操作记录，而等保（网络安全等级保护）还关心身份鉴别、访问控制、日志留存期限、备份恢复等很多方面，需要结合你们的整体方案和测评机构的要求来判断。本文第 4 节列出的缺口，就是准备材料时要重点补上的地方。

拉取请求被合并后又被回退，能查到吗？

能。回退本身就是一次新的提交或拉取请求，会以推送或合并的形式出现在动态里；Git 历史里也能看到那条 Revert … 提交。

小结

查 Git 上的操作记录，先去 AngusGit 的动态：成员和权限看团队，分支保护、仓库设置、可见性和 Webhook 看配置，拉取请求的合并看 拉取请求，推送看提交；筛选器上的合并只记直接把一个分支合并到另一个分支的操作，目前没有这类记录。合并方式、作者和提交者要回到 Git 历史里查，评审结论在拉取请求页里。动态不记改前改后的规则、不记 IP、不能导出，被拒绝的推送也不在里面，这些缺口要靠变更审批单、数据库备份、服务器日志和反向代理日志补上；登录记录则看 AngusGM 的 登录历史。

结论： 成员变更看团队，分支保护看配置，拉取请求的合并看 拉取请求；改前改后的具体规则、来源 IP 和被拒绝的推送，需要用审批单、反向代理日志和服务器日志另外留存。

参考文章

流水线运行器怎么接到构建机：在那台机器上执行接入命令

Wen Ping — Sat, 31 Oct 2026 04:07:35 +0000

这篇讲流水线 YAML 写好了、任务却没人执行时，怎么把运行器接到构建机上。看完你可以在控制台新增 Runner（装在构建机上、替 AngusGit 执行任务的程序），生成 1 小时有效的注册令牌，按 Docker 或 Zip 把接入命令复制到构建机上执行，并确认它心跳上线。

流水线和运行器在团队版和企业版中提供；社区版没有 CI/CD 菜单，本文的操作不适用。

1. 准备一台构建机

接入之前，先确认网络、容器环境和宿主机环境这三件事。Docker 方式会在这台机器上为每个任务拉起容器（按镜像临时启动的隔离环境）；Zip 方式则让任务直接在宿主机（运行器进程所在的那台机器）上执行。

检查项	适用方式	要求
网络连通	全部方式	构建机主动连 AngusGit（HTTPS / WebSocket 长连接），AngusGit 不需要反连构建机
容器环境	Docker 方式	机器装好 Docker，当前用户有权限执行 `docker` 并挂载 `/var/run/docker.sock`
宿主机环境	Zip 方式	机器装好 JDK 21、`curl` 和 `unzip`，当前用户有 `sudo` 权限（安装到 `/opt/AngusRunnerAgent`）

在构建机上用 curl -I https://<你的 AngusGit 地址> 试一下，能返回 HTTP 状态码，说明网络是通的。

2. 在控制台新增运行器

打开接入页 侧栏进入 CI/CD → 运行器，点右上角 新增 Runner，页面切到 接入新 Runner。
确认控制面地址 控制面地址 默认取当前浏览器打开的站点地址。页面提示「若 Runner 所在网络访问不到，请改为控制面对外可达的 URL」。例如你在办公网用域名访问 AngusGit，而构建机在机房只能用内网 IP 访问，这里就要改成构建机能访问的那个地址。
填名称和标签 Runner 名称（可选） 写清是哪台机器，例如 build-linux-01。标签（可选） 用逗号分隔，例如 linux,docker。流水线里的任务会按标签挑运行器，这里的标签要和任务里写的对得上。不确定时先留空，用每种接入方式的默认标签。最大并发 Job 数 是这台机器同时最多跑几个任务（Job 就是流水线里的一组步骤），默认 4，可填 1 到 64，按机器的 CPU 和内存决定。
生成注册令牌 点 注册令牌 旁的 生成令牌。页面提示「已签发短期注册令牌（明文仅显示一次）」，下方显示「令牌有效期至 …」，有效期 1 小时。令牌会自动填进下面的命令里。没有令牌时点 复制命令，会提示「请先生成或粘贴注册令牌后再复制命令」。

下面这张是还没点 生成令牌 时的页面。控制面地址是 https://git.anguskit.com，名称 build-linux-01，标签 linux,docker，最大并发 Job 数 4。黄色提示是「尚未填写令牌」，复制命令 是灰的。三个页签是 Zip 安装、Docker 一键拉起、一键安装脚本，默认停在 Docker 一键拉起。页签上没有「推荐」两个字，推荐用 Docker 是本文的建议。

3. 选一种接入方式，复制命令

三个页签生成的命令，都已经带上了你填的地址、名称、标签、并发数和令牌。

Docker 一键拉起（推荐）

页签提示「从 AngusRepo 公开仓库拉取 repo.anguskit.com/docker-public/angus-runner-agent」。命令形如：

docker run -d --restart=always --name build-linux-01 \
  -v /opt/AngusRunnerAgent/logs:/opt/AngusRunnerAgent/logs \
  -v /opt/AngusRunnerAgent/data:/opt/AngusRunnerAgent/data \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e RUNNER_SERVER_URL=wss://git.anguskit.com/ws/runner \
  -e RUNNER_REGISTER_TOKEN=<注册令牌> \
  -e RUNNER_NAME=build-linux-01 \
  -e RUNNER_LABELS=linux,docker \
  -e RUNNER_MAX_CONCURRENCY=4 \
  repo.anguskit.com/docker-public/angus-runner-agent:1.0.0

几个要点：--restart=always 让运行器在机器重启后自动恢复；挂载 /var/run/docker.sock 是为了让运行器能在这台机器上为每个任务启动容器；标签留空时默认是 linux,docker。

Zip 安装

页签提示「从 AngusRepo 下载 Zip，安装到 /opt/AngusRunnerAgent」。命令会依次下载并解压 AngusRunnerAgent-1.0.0.zip，复制到 /opt/AngusRunnerAgent，设置 RUNNER_SERVER_URL、RUNNER_REGISTER_TOKEN 等环境变量，然后执行 ./doctor-native.sh 检查本机环境，最后执行 ./startup-agent.sh 启动。

这种方式下，任务直接在宿主机上执行，用的是机器上装好的 JDK、Node.js 等工具。页签提示「NATIVE 流水线不要加 docker 标签」：带了 docker 标签的运行器会被当作 Docker 运行器，领不到宿主机任务。

一键安装脚本

命令形如：

curl -fsSL https://git.anguskit.com/runner/install.sh | bash -s -- \
  --url https://git.anguskit.com --token <注册令牌> \
  --name build-linux-01 --labels linux,docker --max-concurrency 4

页签提示「从控制面下载 /runner/install.sh，在目标机用 Docker 拉起公开镜像」。效果和 Docker 方式相同，适合不想手动拼 docker run 参数的情况。

两种 Docker 方式和 Zip 方式分别适合什么任务，见文末参考里的「Docker 还是宿主机」一文。

4. 在构建机上执行，等它上线

把复制的命令粘贴到构建机的终端里执行。然后回到控制台，点 完成并等待上线。

页面显示「正在等待 “build-linux-01” 心跳上线…」，每隔几秒检查一次。运行器连上之后，提示「Runner “build-linux-01” 已上线」，列表里出现这台机器，状态是在线或空闲。

接入成功后，可以到 CI/CD → 运行器对照列表。当前实例已经有两台空闲的运行器：dev-1 运行模式 NATIVE，执行器 SHELL，标签 linux、native、dev，并发 0/2；priv-1 运行模式 DOCKER，执行器 SHELL，标签 linux、docker，并发 0/2。按上面命令接入的 build-linux-01 也会出现在这张表里，状态是空闲，最近心跳是「刚刚」。

等了 90 秒还没上线，页面会提示「等待心跳超时，请稍后刷新列表确认」。这不一定是失败，运行器可能还在拉镜像。过一两分钟刷新列表；仍然没有，按第 6 节排查。

5. 接好之后

上线之后，日常只要盯状态、改标签或暂时停用，一般不用重装。

运行器的状态。 列表里有在线、空闲、忙碌、离线、已禁用 几种。运行器每 15 秒发一次心跳；超过 90 秒没有心跳、连接也断了，就会变成离线。
改名称、标签和并发。 在列表里打开 编辑运行器 修改，不用重新安装。
重装或换机器。 打开运行器详情的 安装运行器 页签，在 安装 / 重装命令 里重新生成命令。页面提示「重装到新主机时请重新生成或粘贴注册令牌」，因为原来那把注册令牌已经在第一次接入时用掉了。
暂时不用这台机器。 点禁用，它就不再领取新任务；要恢复时点启用。

私有化部署时，运维也可以在服务端配置一把共享注册令牌（CICD_RUNNER_REGISTER_TOKEN），接入时直接粘贴。这把令牌的默认值是 change-me-runner-register-token，上线前一定要改掉；否则任何知道默认值、又能访问 AngusGit 的机器，都能把自己注册成运行器来领取任务。

6. 接入失败时

你看到的	原因	怎么处理
「等待心跳超时，请稍后刷新列表确认」，刷新后仍没有	构建机访问不到控制面地址；或者注册令牌已过期	在构建机上 `curl -I <控制面地址>` 检查网络；超过 1 小时的令牌重新生成，再复制一次命令
Docker 方式执行后，容器很快退出	令牌不对，或者连不上控制面	执行 `docker logs build-linux-01` 看最后几行报错
Docker 方式拉镜像失败	构建机访问不到 `repo.anguskit.com`	让构建机能访问外网，或者把镜像提前导入到内网镜像仓库，再把命令里的镜像地址改成内网地址
Zip 方式 `doctor-native.sh` 报错	缺 JDK 21 或其他依赖	按它打印的提示补装，再执行 `./startup-agent.sh`
运行器上线了，但任务一直等待中	任务要求的执行方式或标签和这台运行器对不上	看运行详情里任务的等待原因，排查方法见文末参考里的「运行器不接任务」一文

运行器进程自己的日志，在运行器详情的 运行日志 页签里能看到，页面说明是「Runner 进程日志，包含注册、心跳、接单、拉镜像和步骤执行记录」。旧版本运行器不上报这部分日志时，显示「暂无进程日志（需 Runner 升级到支持上报的版本）」，这时到构建机上看 /opt/AngusRunnerAgent/logs 目录。

常见问题

一台机器能装几个运行器？

通常一个就够了，用 最大并发 Job 数 控制同时跑几个任务。需要在同一台机器上同时提供 Docker 和宿主机两种执行方式时，可以装两个：一个用 Docker 方式、带 docker 标签，一个用 Zip 方式、不带 docker 标签，名称要区分开。

注册令牌过期了，已经接入的运行器会掉线吗？

不会。控制台生成的注册令牌是一次性的，只在第一次接入时使用。接入成功后，AngusGit 会给这台运行器下发一把长期身份令牌，运行器把它保存在本机，以后重启、断线重连都用这把。要再接入一台新机器时，重新生成一把注册令牌即可。

运行器要开放端口吗？

不需要。是运行器主动连 AngusGit，构建机上不需要对外开放任何端口。

小结

运行器是装在构建机上、替 AngusGit 执行流水线任务的程序。在 CI/CD → 运行器 → 新增 Runner 里确认构建机能访问的 控制面地址，填名称、标签和并发数，点 生成令牌，选一种接入方式复制命令，到构建机上执行，再点 完成并等待上线。有 Docker 的机器优先用 Docker 方式，要在宿主机上直接构建就用 Zip 方式并装好 JDK 21。私有化部署时，共享注册令牌的默认值必须改掉。

结论： 在 CI/CD → 运行器 → 新增 Runner 填好构建机可达的 控制面地址、标签并点 生成令牌，复制命令到构建机执行后，列表出现 在线 / 空闲 状态即接入完成。

参考文章

谁来审这段代码：用 CODEOWNERS 按目录自动指派评审人

Wen Ping — Sat, 31 Oct 2026 04:06:59 +0000

这篇讲怎么按目录自动指定谁来评审。看完你可以写一份 CODEOWNERS 文件，按路径写明每段代码由谁负责，打开 启用 CODEOWNERS 之后，新建拉取请求就会按改动路径把这些人加为评审人。

下文以仓库 xlliu/test-pr-example 对照。这个仓库已经打开 需要代码评审 和 需要所有评审人通过（被指派的人都批准才能合并），但 启用 CODEOWNERS 还是关的。它设置了两位默认评审人，也就是在仓库设置里固定指定、每条新拉取请求都会带上的人：一位显示名是 Angus、登录名是 xlliu，另一位是 admin。

1. 现在这条拉取请求是怎么来的

还开着的 #9 标题是 docs: 说明空购物车不计算折扣，从 feature/link-empty-cart 合向 main，作者是 Angus，正文写了 Closes #4，只改了 1 个文件：docs/empty-cart-note.md（+3 -0）。

评审人是 Angus 和 admin，两人都是 待评审。合并卡片写着「此拉取请求尚未准备好合并」，下面是「暂无状态检查」和「仍有评审未完成，需等待评审通过后才能合并」，所以 合并拉取请求 是灰的。

所以这两位来自仓库设置里的默认评审人，不是按文件路径算出来的；main 上目前也没有 .github/CODEOWNERS、根目录 CODEOWNERS 或 docs/CODEOWNERS。

2. CODEOWNERS 实际会做什么

CODEOWNERS 只在新建拉取请求时算一次，而且仓库要先打开 需要代码评审；创建之后再往源分支推提交，不会按新文件补评审人。

指派时会做两件事，再去重：

放上设置里的默认评审人。
启用 CODEOWNERS 开着时，再读目标分支上的文件，按这次改动的路径追加人。

所以默认名单里已经有的人，文件里再写一次也不会变成两行评审。这个仓库的默认名单已经是 xlliu 和 admin 两个人。文件里如果也只写这两位，打开开关后新建的拉取请求，评审人还是这两位。

能做	做不到
创建拉取请求时，把默认评审人和路径匹配到的人并在一起	拉取请求创建后再推送，不会重新算、也不会补人
只认 `@登录名`	团队名（中间有 `/`）和邮箱会被跳过
配合需要所有评审人通过，被指派的人都批准才能合并	只开 CODEOWNERS、不开这一项时，CODEOWNERS 自己不拦合并

作者自己被指派时，不再给自己发「请求评审」通知。其他评审人会收到。

3. 文件怎么写

CODEOWNERS 文件可以放在三个位置，按下面的顺序找，用找到的第一个：

.github/CODEOWNERS
仓库根目录的 CODEOWNERS
docs/CODEOWNERS

读的是拉取请求目标分支上的文件。要合进 main，就得先把文件合进 main。只改在自己的分支上，对这条拉取请求不起作用。

下面这份是给这个仓库准备的示例，还没有提交。登录名用 @xlliu，不要写显示名 @Angus。

# 没被后面规则盖住的文件
*                  @xlliu

# 根目录下的 service 目录
/service/          @admin

# 任意目录的 SQL，写在后面，盖住前面的规则
*.sql              @xlliu @admin

# 开头和行尾的注释会被拿掉，空行忽略。路径和人之间用空格分开。

写法	匹配
`*`	所有文件。单独一行时做兜底
`/service/`	从仓库根目录算的 `service` 目录，以及里面的文件。开头的 `/` 表示锚定到根
`*.sql`	任意一层目录里、以 `.sql` 结尾的文件
`/docs/*/.md`	`docs` 下任意层级的 `.md`
`?`	一个不是斜杠的字符。`v?.txt` 能对上 `v1.txt`

同一个文件命中多行时，用最后一行。

docs/empty-cart-note.md 只命中 *，人是 @xlliu。
service/Foo.java 先命中 *，再命中 /service/，留下 @admin。
service/db/init.sql 三行都命中，最后一行是 *.sql，留下 @xlliu 和 @admin。

以 ! 开头不会当成排除。方括号不会当成字符集，只按字面量里的括号去匹配。

4. 开关在哪

入口是 仓库设置 → 拉取请求，地址带 ?tab=settings&section=pullrequests。

这次看到的是：

项	状态
需要代码评审	开。说明是「合并前必须经过代码评审，开启后针对所有分支都生效。」
需要的评审人数	`1`
评审人	已选择 2 个：Angus、admin
需要解决所有评论	关
需要所有评审人通过	开。说明是「合并前所有指派的评审人都必须通过评审。」
启用 CODEOWNERS	关。说明是「根据 .github/CODEOWNERS 文件按代码路径自动指派评审人。」
评审通过后自动合并	开。还要这条拉取请求自己也打开自动合并才会合。#9 的合并按钮仍是灰的
自动指派评审人（负载均衡）	关
评审超时提醒（小时）	`0`，表示关闭

打开 需要代码评审 时，人数至少为 1，并且至少选一位评审人，否则保存会提示「启用代码评审时，必须设置评审人数并选择至少一个评审人」。保存成功的提示是「拉取请求设置已保存」。页面上已经是这些值时，打开设置只是查看，不必再保存。

负载均衡开着、而且候选人数多于 需要的评审人数 时，只留下未完成评审最少的那几位，人数等于所需人数。代码所有者可能被挑掉。这个仓库它是关的，两位默认评审人都会留下。

需要所有评审人通过 看的是已经指派的每一个人，包括默认评审人和 CODEOWNERS 追加的人。人数设成 1 时，如果没开「所有人通过」，一位批准就够人数。这个仓库开了「所有人通过」，所以 #9 要等 Angus 和 admin 都批准。页面上现在的红字是「仍有评审未完成，需等待评审通过后才能合并」。合并请求若仍然发出去，接口返回的是「需要所有评审人通过后才能合并，当前仍有「1」个评审人未通过」。#9 还开着，等两位评审人都通过再合并。

5. 和分支保护

仓库设置里的 需要代码评审 管的是拉取请求能不能合，并不阻止直接往 main 推。这个仓库的 设置 → 分支保护 写着「尚未设置分支保护规则」；要拦住直接推送、让改动必须走拉取请求，再点 添加规则，给 main 打开需要评审，并对管理员同样生效。做法见文末的分支保护一文。

合并时如果目标分支的保护规则里填了评审人数，用保护规则上的人数；没填才用仓库设置里的 需要的评审人数。需要所有评审人通过 仍看仓库设置。

6. 没有按路径指派时

你看到的	原因	怎么处理
只有默认评审人	启用 CODEOWNERS 关着，或目标分支上三个位置都没有文件。#9 就是前一种	把文件合进目标分支，打开开关，保存后再新建一条拉取请求
文件里写了人，评审列表里没有	`@` 后面不是登录名，或写了团队名、邮箱	改成 `@xlliu` 这种登录名。显示名 Angus 对不上
指派的不是预想的那一行	同一个文件命中了多行，生效的是最后一行	把更具体的规则放到后面，或把几个人写在同一行
创建后又改了别的目录，新人没出现	只在创建时算一次	由作者或管理员手工把这个人加为评审人
人还没批准就被合并了	需要所有评审人通过关着，而且批准人数已经达到所需人数	打开「所有人通过」。这个仓库已经开着

常见问题

CODEOWNERS 里的人没有仓库权限会怎样？

他仍会被加进评审人。要打开拉取请求并提交评审，需要这个仓库的读取权限。

社区版能用吗？

能。需要代码评审、启用 CODEOWNERS 和 需要所有评审人通过 都在仓库 设置 → 拉取请求 里。

两个人里任意一个批准就行，能做到吗？

把两个人写在同一行，关掉 需要所有评审人通过，需要的评审人数 填 1，并保持负载均衡关闭。这样一位批准就够人数。代价是：任何一位已指派的人批准都算数，不限是不是代码所有者。这个仓库现在开着「所有人通过」，所以不是这种算法。

小结

xlliu/test-pr-example 没有 CODEOWNERS 文件，启用 CODEOWNERS 是关的。#9 的评审人 Angus 和 admin 来自默认名单。两人都还是待评审，合并按钮不可用。

要按目录加人：把 .github/CODEOWNERS 合进目标分支，规则用 @登录名，同一文件以最后一行为准；然后打开 启用 CODEOWNERS 并保存。新建的拉取请求会把文件里匹配到的人和默认评审人并在一起。这个仓库已经打开 需要所有评审人通过，负载均衡是关的，被指派的人都要批准。

结论： 默认评审人在创建拉取请求时就会指派。CODEOWNERS 要文件先在目标分支上，并且打开启用开关，才会按路径把登录名并进去。需要所有评审人通过开着时，这些人都批准才能合并。

参考文章

在合并请求里做完代码评审：看 Diff、写行评、通过或打回

Wen Ping — Sat, 31 Oct 2026 04:06:22 +0000

这篇讲同事发来拉取请求、请你看代码时，从哪里下手。看完你可以在侧栏评审页打开差异（Diff，即改动前后的对比），对具体的行写意见，必要时用 suggestion 给出替换代码，再提交批准、请求更改 或评论。

拉取请求（Pull Request，也叫合并请求）是把一个分支上的改动申请合进另一个分支的请求。AngusGit 界面上叫它 拉取请求，和 GitLab 的 Merge Request、GitHub 的 Pull Request 是同一件事。要注意的是，行评和建议都在侧栏的评审页里写，拉取请求页本身不提供这个入口。如果想让仓库强制要求「必须评审才能合并」，可以看文末参考文章里的分支保护一文。

下文以还开着的 xlliu/test-cicd-example #1 为例，它的标题是「SC-02/SC-04 PR trigger verification」，从源分支 verify-pr-sc0204 合向目标分支 main。Angus 在这条请求上的评审仍是 待评审，在 文件变更 里可以展开差异。如果想回看一次完整的评审对话，可以打开两条已经合并的例子：xlliu/test-pr-example 的 #1 和 xlliu/test-review-example 的 #1。

1. 三种结论分别意味着什么

评审的最后一步，是在三种结论里选一个。先弄清它们的区别，看代码时就知道自己要找什么。

结论	意思	对合并的影响
批准	我看过了，同意合进去	计入批准人数，人数够了合并卡才放行
请求更改	这些问题要先改完	作者改完并重新获得批准前，合并卡显示还不能合并
评论	有疑问或建议，但不挡合并	不计入批准，也不阻止合并

拿不准时选评论，把疑问写清楚，等作者回答后再决定批准还是请求更改。如果发现某处问题会导致线上出错，就要选 请求更改，因为批准之后再补一句「记得改」，并不能拦住合并。

2. 打开要评审的那一条

进入评审列表 在侧栏点评审，进入页头为 代码评审 的页面。默认停在 待评审 页签，这里列的是还等你处理的请求，卡片上标着 已逾期 的可以优先处理。如果同一条拉取请求指派了多位评审人，列表里会按评审人各出现一行。
找到要评审的请求 请求多的时候，可以在「搜索评审...」框里按标题搜，或者把仓库筛选从 所有仓库 换成具体的仓库。
打开评审详情 点卡片进入评审详情。顶部的统计会显示这次改动包含几个提交、几个文件，以及新增和删除的行数。随时可以点 查看拉取请求 回到这条请求的原页面。

以 Angus 的评审列表为例：待评审 是 6，已评审 是 18，顶部有搜索框、所有仓库 和 选择评审人 三个筛选。列表里有三条请求，分别是 xlliu/test-pr-example 的「docs: 说明空购物车不计算折扣 #9」（描述里写的是 Closes #4）、anguskit/Markdown 的「docs: cross-repo review list count fixture (round 25) #2」和 xlliu/test-cicd-example 的「SC-02/SC-04 PR trigger verification #1」，后两条都标着 已逾期。因为每条请求都指派了两位评审人（例如 #9 是 Angus 和 admin），所以它们在列表里各占两行。

3. 先看作者想做什么

打开评审详情后，先别急着看代码，而是在讨论页签读作者写的描述：这次要解决什么问题、改动范围有多大、有没有特别希望你看的地方。不清楚改动目的就直接看差异，很容易只挑出格式问题，却漏掉真正的逻辑错误。

同一页上还有 状态检查，也就是流水线等自动检查写回来的结果，每一项显示为成功、失败或 进行中。如果有一项失败，先看失败的是哪一项：要是和你要评审的代码有关，例如编译不过或测试没通过，可以直接请求更改，请作者先让检查通过。

4. 逐个文件看差异，对具体的行写意见

弄清改动目的之后，切到 文件变更 页签开始看代码。

按文件树一个个看 左侧是 文件树。每看完一个文件，就在树上勾选它，标记为 已查看；文件多的时候，这样能避免漏掉被重命名或删除的文件。大文件默认只显示前面一部分，点 展开完整 Diff 可以看到全部内容。
选一种看得顺的视图 统一视图 把删除的行和新增的行上下排在一起，适合看小改动；分栏视图 左边是修改前、右边是修改后，适合看被大段重写的函数。
在要讨论的行上留言 把鼠标移到要讨论的那一行，点 对该行添加评论，写下意见后点评论。这时评论还是草稿，作者看不到，所以你可以继续看其他文件、写其他行评，最后一次性发出。如果需要和同事讨论某一行，可以点 复制行链接 发给他。

上图以 xlliu/test-cicd-example #1 的评审页为例：在 文件变更 的 统一视图 里，对 apps/service-a/src/index.js 新增的第 9 行写了一条评论。这条评论标着草稿，作者还看不到；左侧文件树上的两个文件也都还没有标记为已查看。

写行评时注意下面三点，作者能更快改对：

说清楚问题是什么，以及为什么是问题。「这里会空指针」比「这里有问题」有用得多。
分清必须改的和只是建议的。如果只是个人偏好的写法，可以在开头注明「可选」，作者不改也不影响你批准。
能给出代码时就直接给出，写法见下一节。

5. 直接给出替换代码

有些意见用文字很难说清，这时不如直接写出改好的代码。做法是在行评里放一个 suggestion 代码块，块里写的就是你希望这一行变成的样子：

这里没有处理 raw 为空的情况，建议先判断一下：

```suggestion
if (raw == null || raw.isBlank()) return false;
```

发出之后，这条评论会显示为 建议的变更。作者或有写权限的人点 应用建议 后，AngusGit 会用块里的内容替换你评论的那一行（块里可以写多行），并在源分支上生成一个新提交，成功后显示 已应用。

使用建议时注意三点：

建议是按行号替换的。如果你写完建议后作者又改过这个文件，行号可能已经错开，所以应用前先刷新差异，确认那一行还是你要改的那一行。
一条评论只识别第一个 suggestion 块。要改几处不相邻的代码，就分成几条行评来写。
应用建议会直接往作者的分支上加提交。即使评审人自己有写权限，也最好先和作者说一声再点，免得作者本地还有没推送的改动，之后推送时产生冲突。

另外，如果拉取请求的源分支在 Fork 仓库（从别人的仓库复制出来的个人副本）里，或者要改的是二进制文件，就不能应用建议。这时把代码写在普通评论里，请作者自己修改。

6. 提交结论

所有文件看完之后，点顶部的 提交评审，弹出的对话框说明是「选择你的评审决定并添加评论」。

选择决定 在批准、请求更改、评论中选一个，含义见第 1 节。
写一段总评 在评论框里写给作者的整体结论。批准时一句话就够，例如「逻辑没问题，可以合」；请求更改时，列出必须改的几处，这样作者不用自己从十几条行评里分辨哪些是必须改的。
发出按钮上的 +N 表示会把你之前写的 N 条草稿行评一起发出。确认无误后点 提交评审。

提交之后，你的结论会出现在拉取请求对话页的审查区，作者也能在文件差异上看到你的每一条行评。同时，这条请求会从你的 待评审 移到 已评审。

上图的对话框里选中了 请求更改，按钮上的 +1 就是前面那条草稿行评，点 提交评审 时会一起发出；总评可以留空。在点 提交评审 之前，这条评审的状态仍是 待评审。

7. 作者改完之后，再审一遍

作者收到 请求更改 后，在本地按意见修改，再推送到同一个源分支。不需要新建拉取请求，新提交会自动出现在原来这一条里。

某条讨论按意见改好之后，作者或评审人可以点 标记为已解决。如果仓库要求合并前解决所有评论，没有标记的讨论会一直卡在合并条件里。

作者推送之后，回到这条评审再看一遍：

在提交页签找到作者新推的几个提交，点 查看变更，只看这次新改的内容，不必把整个差异从头再看。
确认你提的问题都改好了；还有疑问的地方，继续写行评。
再次点 提交评审，这次通常选批准。

之前给过批准的人，在作者推送新提交后，会看到自己的批准被标成 需重新评审。如果目标分支开了分支保护（针对某个分支设置的合并与推送规则），这些旧批准就不再计入人数，必须有人对最新代码重新批准，合并卡才会放行。这样能保证被批准的始终是最新那一版代码。

8. 合并在拉取请求页完成，没空时可以委托

评审页只负责给出结论，不负责合并代码。等批准人数达到仓库要求、状态检查通过、也没有冲突时，由作者或维护者回到拉取请求的对话页点 合并拉取请求。

如果你暂时没空评审，可以在待评审状态下点委托，在 委托给 里选另一位成员，再点委托。这条请求就会从你的待评审列表移到对方那里。

9. 卡住时

评审过程中遇到下面这些情况，可以按表排查：

你看到的	原因	怎么处理
评审详情里没有提交评审按钮	你不是这条请求的评审人，或者这条请求已经合并	请作者或仓库管理员把你加为评审人。已经合并的请求不能再提交结论
作者说看不到你的行评	行评还是草稿，你还没点提交评审	打开提交评审，选一个结论发出。按钮上的 `+N` 就是还没发出的条数
在拉取请求的文件变更里找不到行评入口	那一页只用来浏览，页顶写着「行级评论与建议请在评审页完成」	点前往评审页评论，到评审页写
你已经批准，合并卡仍写着还不能合并	批准人数不够；或你批准后作者又推了提交，批准变成需重新评审；或有冲突、状态检查没过、讨论没解决	对照合并卡上写出的那一条原因处理。是需重新评审就对最新的代码再批准一次
点应用建议提示应用建议失败	评论里没有 `suggestion` 块，评论不在某一行上，文件不是文本文件，或者这条请求的源分支在 Fork 里	确认建议写在行评里、块的开头是三个反引号加 `suggestion`。Fork 来的请求和二进制文件，请作者手动修改

常见问题

一条请求要几个人评审？

由仓库决定。设置 → 拉取请求 里的 需要的评审人数，或者分支保护里的 必需的评审人数，填的就是合并前需要的批准数，达到之后合并卡才会放行。

选了「评论」，作者还能合并吗？

能。评论不计入批准，也不会挡住合并。如果你担心的问题必须先改，就要选 请求更改。

评审意见写错了怎么办？

在那条讨论下面点回复，写清楚更正的内容，作者会按最新的回复修改。如果是结论本身选错了，就再提交一次评审，换成正确的结论。

一次改动太大，看不完怎么办？

在描述或总评里请作者拆成几条小的拉取请求，每条只做一件事。改动控制在几百行以内，评审人才能真正看仔细。

小结

一次完整的评审分四步：先在评审里打开待办；再读描述和状态检查，弄清作者想做什么；然后在 文件变更 里逐个文件看，对具体的行写意见，能直接给代码时就用 suggestion 块；最后用 提交评审 一次发出结论。作者推送新提交之后，你只需回来看新增的改动，再提交一次结论。真正的合并，由作者或维护者在拉取请求页完成。

结论： 代码评审在侧栏评审页完成：逐文件写下的行评会先存为草稿，点 提交评审 选择批准、请求更改 或评论后才会一并公开并计入合并条件。

参考文章

HTTPS 克隆私有仓库：密码填访问令牌

Wen Ping — Sat, 31 Oct 2026 04:05:46 +0000

这篇讲用 HTTPS 地址克隆 AngusGit 私有仓库时，用户名和密码分别填什么。看完你可以生成一把只读、只对当前仓库有效的访问令牌，用它完成克隆，并在本机或 CI 里保存这把令牌，避免写进克隆地址。

下文用 AngusGit 线上实例上的真实私有仓库 https://git.anguskit.com/anguskit/AngusKit.git 做示例。照着做时，换成你自己的仓库地址。要用 SSH 密钥，或者要第一次往空仓库推代码，见文末参考里的第一次推送一文。

1. 用户名和密码各填什么

终端问的	填什么	说明
`Username for 'https://git.anguskit.com':`	你的 AngusGit 登录名	不是团队名，也不是仓库所有者。示例里的所有者是团队 `anguskit`，用户名仍填你自己的登录名
`Password for 'https://<登录名>@git.anguskit.com':`	访问令牌	登录密码也能用，但令牌更安全，原因见下

推荐令牌而不用登录密码，有三个原因：

登录密码能登录整个控制台。它一旦被存进凭据缓存或脚本又泄露出去，别人能做的远不止克隆代码。令牌只用于 Git 克隆和推送，不能用来登录控制台。
令牌可以只给 git:read，只给某几个仓库。即使泄露，别人也只能读这几个仓库。
令牌有过期时间，也能单独吊销。吊销一把令牌，不影响你的登录密码和其他令牌。

2. 生成一把只读令牌

打开令牌页 侧栏点我的，切到 访问令牌 页签，点 生成新令牌。
名称、期限和身份确认 令牌名称 写清用途，例如「笔记本克隆 AngusKit」，以后在列表里一眼能认出来。过期时间 和下一步的权限，生成之后都不能再改，要一次选对。过期时间 可选 30天、60天、90天 或 365天。密码验证 里输入你当前的登录密码，确认是你本人在操作。
只给需要的权限 权限范围 勾选 git:read，页面说明是「允许 clone / fetch」。仓库作用域 选 指定仓库，在列表里勾选 anguskit/AngusKit，权限设为 READ。以后这把令牌只能读这一个仓库。
马上保存 点 生成令牌。页面提示「请立即复制此令牌。出于安全考虑，它将不会再次显示。」点复制，存进你的密码管理器，再点 我已保存此令牌。之后列表里只显示令牌名称，看不到原文；丢了就只能重新生成。

以后还要用这把令牌推送时，权限范围 要勾 git:write，仓库权限设为 WRITE。只设 WRITE 而不勾 git:write，页面会提示「仓库授予 WRITE 时必须同时勾选 git:write」。

3. 克隆

git clone https://git.anguskit.com/anguskit/AngusKit.git

终端先打印 Cloning into 'AngusKit'...，然后依次出现两个提示：

Username for 'https://git.anguskit.com':
Password for 'https://<登录名>@git.anguskit.com':

第一个填登录名，第二个粘贴刚才保存的令牌。粘贴时屏幕上不显示任何字符，这是正常的，粘贴完直接回车。接着出现 Receiving objects 的进度，就说明认证已经通过、正在下载。命令结束后当前目录下多出一个 AngusKit 文件夹，克隆就完成了。

4. 让 Git 记住令牌

不想每次拉取都粘贴一遍令牌，就交给系统的凭据管理器保存：

macOS： Git 默认使用钥匙串，第一次输入之后自动保存。
Windows： Git for Windows 自带凭据管理器，第一次输入之后自动保存。
Linux： 下面这一行让 Git 把凭据在内存里保留一段时间（默认 15 分钟），不写入磁盘：

git config --global credential.helper cache

也可以用 credential.helper store 长期保存，但它会把令牌以明文写进 ~/.git-credentials，只适合你一个人用的电脑。

5. 在脚本和 CI 里克隆

CI 机器上没有人来输入密码。这时常见的写法是把令牌拼进地址，例如 https://<登录名>:<令牌>@git.anguskit.com/...。不要这样做：这个地址会被写进克隆出来的 .git/config，还容易出现在构建日志里。

改用请求头传令牌。先把令牌放进 CI 的密钥变量，例如 ANGUSGIT_TOKEN，然后：

git -c http.extraHeader="Authorization: Bearer ${ANGUSGIT_TOKEN}" \
  clone https://git.anguskit.com/anguskit/AngusKit.git

-c 只对这一条命令生效，令牌不会写进 .git/config。之后在这个目录里再执行 git fetch 或 git pull 时，同样要带上这段 -c。

给 CI 用的令牌，单独生成一把：名称写明是哪条流水线，权限范围 只给 git:read，仓库作用域 只选它要拉的仓库。这样流水线出问题时，吊销这一把就行，不影响其他人。

6. 令牌过期了，或者要换一把

访问令牌 列表里，每把令牌都显示状态（活跃、已过期 或 已吊销）、最后使用 时间、使用次数 和 过期于 的日期。

令牌过期或被吊销后，用它克隆或拉取会认证失败。按下面三步换一把：

按第 2 节重新生成一把令牌。

清掉 Git 缓存的旧令牌，否则 Git 会一直拿旧的去试：

printf "protocol=https\nhost=git.anguskit.com\n\n" | git credential reject

再执行一次 git pull，在提示里填登录名和新令牌。

怀疑令牌泄露时，在列表里点那一把的吊销，它会立即失效。吊销全部 会让你所有未过期的令牌同时失效，用到这些令牌的脚本和 CI 也会一起停止工作，点之前先想清楚有哪些地方在用。

7. 克隆失败时

你看到的	原因	怎么处理
`fatal: Authentication failed for 'https://git.anguskit.com/anguskit/AngusKit.git/'`	令牌已过期或已吊销；令牌复制时少了字符；用户名填的不是令牌主人的登录名；令牌的指定仓库里没有这个仓库；或者 Git 缓存的还是旧令牌	到访问令牌列表看这把令牌的状态和仓库作用域。用户名填你自己的登录名。缓存过旧令牌时，按第 6 节执行 `git credential reject` 后重试
`fatal: could not read Username for 'https://git.anguskit.com': terminal prompts disabled`	在没有终端交互的环境里（CI、脚本）克隆，Git 想问用户名却问不了	按第 5 节用 `http.extraHeader` 传令牌
`fatal: repository 'https://git.anguskit.com/anguskit/AngusKit.git/' not found`	地址里的所有者或仓库名写错了	打开仓库代码页，点绿色的代码按钮，从 Clone 面板重新复制地址
克隆正常，推送被拒绝	令牌的权限范围只有 `git:read`，或者仓库权限只有 READ	推送需要 `git:write` 加 WRITE。令牌的编辑只能改名称和描述，不能改权限，所以要另外生成一把用于推送

常见问题

改了登录密码，令牌要跟着换吗？

不用。令牌和登录密码互相独立。改密码之后，令牌在有效期内照样能用。

访问令牌能用来调用控制台的接口吗？

不能。访问令牌只用于 Git 的 HTTPS 克隆、拉取和推送。控制台和它的接口仍然通过登录会话访问。

同一台电脑要用两个账号克隆不同的仓库，怎么办？

让凭据按完整路径区分。执行 git config --global credential.useHttpPath true 之后，Git 会按每个仓库的完整地址分别保存凭据，两个账号的令牌不会互相覆盖。

不想管令牌，有别的办法吗？

可以改用 SSH。在 我的 → SSH密钥 登记一次公钥，之后用 SSH 地址克隆和推送都不再需要密码或令牌。做法见文末参考里的第一次推送一文。

小结

HTTPS 克隆私有仓库时，用户名填登录名，密码填访问令牌。只读的场景，生成一把只勾 git:read、只选目标仓库的令牌，生成后马上存好。日常使用交给系统凭据管理器记住；CI 里用 http.extraHeader 传令牌，不拼进地址。令牌过期就重新生成一把，再用 git credential reject 清掉旧缓存；怀疑泄露就单独吊销那一把。

结论： HTTPS 克隆私有仓库时，用户名填 AngusGit 登录名，密码填 我的 → 访问令牌 生成的 git:read 令牌；CI 中使用 http.extraHeader 传参，避免把令牌写进克隆 URL。

参考文章

合并前怎么拦住仓库里的漏洞

Wen Ping — Sat, 31 Oct 2026 04:05:10 +0000

这篇讲安全扫描已经发现高危漏洞、拉取请求却仍能合并时，怎么在合并前拦住。看完你可以打开 未通过时拒绝合并，设好 漏洞门禁阈值（达到这一级以及更严重的问题就拦），再用分支保护让管理员也绕不过去。

先登录 AngusGit，打开要设门禁的仓库。安全扫描在团队版、企业版和云服务中提供；社区版没有安全菜单。门禁只认已经扫描过的提交，所以先做下面两步：

系统管理员打开 管理 → 安全设置。页面标题是 AngusSecurity 集成。配置启用 要是 已启用，平台可达 要是正常。还没开通时点 开通集成。页面要求先设置 angus.git.external-security.enabled=true 时，把环境变量 ANGUS_GIT_EXTERNAL_SECURITY_ENABLED 设为 true，改完重启 AngusGit。
仓库管理员进入该仓库 设置 → 安全，打开 本仓自动安全扫描，并至少打开 代码安全、依赖/制品漏洞、密钥检查 中的一种，然后保存。保存成功的提示是「安全设置已保存」。页面说明是「默认关闭。关闭后推送不再自动检查」。

1. 打开门禁

打开仓库的安全设置 进入仓库 设置 → 安全，找到 合并门禁 一节。页面提示「只有仓库管理员能修改。」
打开「未通过时拒绝合并」 说明是「默认关闭。打开后按 PR 最新提交的检查结论判定：还没检查完时等待，漏洞门禁或许可证门禁未通过时拒绝合并。直接合并分支同样受限。代码质量不参与。」
选漏洞门禁阈值 留空表示沿用租户默认，显示为「沿用租户（…）」；租户也没有设置时，默认是高危。阈值怎么选见第 2 节。
确认自动扫描是打开的 门禁只认已经扫描过的提交。本仓自动安全扫描 关闭时，页面会提示「自动检查已关闭：新提交不会自动检查，PR 会一直等待。打开自动检查，或在代码页对分支手动检查。」看到这条提示，先把自动扫描打开。

2. 阈值选哪一级

阈值的意思是「达到这个级别就拦」。选某一级，就是这一级以及比它更严重的问题，只要有一个就拒绝合并。

阈值	什么情况会拦住合并	适合的情况
严重	有严重问题	刚开始推行，存量问题很多，先拦最危险的
高危	有严重或高危问题	大多数团队的默认选择
中危	有严重、高危或中危问题	安全要求高、存量问题已经清理干净的仓库
低危	有任何级别的问题	很少使用，容易频繁拦住正常合并

这里的「问题」包括代码安全、依赖/制品漏洞和密钥检查发现的问题，按严重级别计数。许可证问题单独由许可证门禁判断，代码质量问题不参与。

打开 未通过时拒绝合并 后，漏洞门禁总会参与判断，阈值没有「不启用」这一项，最宽松的设置是严重。

建议从高危开始。门禁刚打开时，存量的高危依赖漏洞可能会挡住很多拉取请求，先集中修一轮，再考虑收紧到中危。

修改阈值之后，已经检查过的提交不会按新阈值重新判定。页面提示「改了阈值后，需要重新检查才按新阈值判定。」要马上生效，对相关分支重新扫描一次。

3. 门禁到底拦住了什么

打开 未通过时拒绝合并 之后，拉取请求合并时会检查 源分支最新那一个提交 的安全检查结论：

最新提交的检查结论	能不能合并	页面提示
还没检查，或正在检查	不能	等待对提交 … 的安全检查
检查失败，或结果不完整	不能	请重新检查
漏洞数量达到或超过阈值	不能	`漏洞门禁未通过：严重 …、高危 …、中危 …、低危 …`
漏洞数量未达到阈值	能	`提交 … 的漏洞门禁已通过`

有三点要特别说明：

只看最新提交。 往源分支推了新提交，结论会回到等待，按新提交重新判定。不会沿用旧提交的通过结论，也不会因为旧提交失败而一直挡住修好的代码。
不依赖分支保护。 即使目标分支没有任何保护规则，这道门禁也生效，通过接口合并同样会被拒绝。
管理员例外。 目标分支有保护规则、规则没有打开 对管理员同样生效、并且操作人是仓库管理员时，可以绕过这道门禁。目标分支没有保护规则时，管理员也会被拦住。

所以，要做到谁都绕不过去，还要在 设置 → 分支保护 里给 main 打开 对管理员同样生效。分支保护里还有一个 要求安全检查通过 开关，说明是「按 PR 最新提交的安全检查结论判定，没检查完时等待（默认关闭）」，作用和 未通过时拒绝合并 相同，只在这条保护规则覆盖的分支上生效。已经打开 未通过时拒绝合并 的仓库，不需要再打开它。

4. 被拦住之后怎么修

开发者看到拉取请求上的 AngusSecurity 失败，按下面的步骤处理：

看是哪些问题 在拉取请求的 状态检查 里点 打开仓安全详情，进入仓库安全详情页。按严重级别筛选，先看严重和高危。
按类别修 依赖漏洞看 修复版本，把依赖升级到这个版本或更高；代码安全问题看 修复建议 改代码；密钥问题把密钥从代码里移除，并且一定要去对应的系统里作废这把密钥，因为它已经进入了提交历史。
推送修复 在源分支上提交修复并 git push。推送会触发新的扫描，拉取请求上的安全检查先回到 进行中，扫完更新。
确认通过后合并 状态变成成功，说明文字是「提交 … 的漏洞门禁已通过」，就可以合并了。

5. 常见的卡住情况

你看到的	原因	怎么处理
一直停在「等待对提交 … 的安全检查」，合并不了	这个提交没有被扫描。常见原因是自动扫描关了，或者提交是在网页上编辑的	打开自动扫描后重新推送；或者在仓库安全详情页立即扫描源分支
「提交 … 的安全检查失败，请重新检查」	扫描本身出错	重新扫描；仍然失败时到 AngusSecurity 查看扫描任务的错误
「提交 … 的检查结果不完整，请重新检查」	扫描完成但结果不可信，例如部分检查没有跑成功	重新扫描
改了阈值，拉取请求的结论没变	已检查的提交不会按新阈值重新判定	对源分支重新扫描一次
存量漏洞太多，几乎所有拉取请求都被拦	阈值相对当前代码太严	先把阈值放到严重，集中清理存量问题后再收紧
管理员能合并，其他人不能	分支保护没有打开对管理员同样生效	按团队规定决定是否打开

常见问题

只拦 main，其他分支不拦，可以吗？

未通过时拒绝合并 对这个仓库的所有拉取请求生效。只想拦特定分支时，不打开它，改为在那个分支的保护规则里打开 要求安全检查通过。

发现的漏洞确认不影响我们，能放行这一次吗？

门禁按数量判断，没有针对单个问题的豁免开关。可以在安全详情里把这个问题的 处置状态 改为 已知悉 或误报，记录判断结论；需要放行时，由仓库管理员按分支保护的规则合并，或者临时调整阈值后重新扫描。这类操作建议在团队里约定好由谁决定。

门禁和流水线的状态检查有冲突吗？

没有。两者都显示在拉取请求的 状态检查 里，合并时分别判断，都满足才能合并。

小结

让漏洞挡住合并，在仓库 设置 → 安全 打开 未通过时拒绝合并，漏洞门禁阈值 从高危开始。门禁按源分支最新提交的检查结论判断：没检查完就等待，达到阈值就拒绝，修好推送后重新判定。它不依赖分支保护，接口合并也受限；要让管理员也受限，在分支保护里打开 对管理员同样生效。前提是 本仓自动安全扫描 已打开，否则拉取请求会一直等待。安全扫描在团队版、企业版和云服务中提供；社区版没有安全菜单，需要时请使用团队版或企业版。

结论： 在仓库 设置 → 安全 打开 未通过时拒绝合并 并设好 漏洞门禁阈值（如高危），拉取请求源分支最新提交只要检出达到该级别的问题就会被拒绝合并。

参考文章

合并前怎么拦住不合规的开源许可证

Wen Ping — Sat, 31 Oct 2026 04:04:33 +0000

这篇讲依赖用了不合规的开源许可证时，怎么在合并前拦住。看完你可以在仓库 设置 → 安全 里打开许可证门禁和 未通过时拒绝合并，并到 AngusSecurity 策略里勾上 许可证合规，看允许名单和禁止名单在哪填。

先登录 AngusGit，再打开仓库 xlliu/e2e-license-gate；你自己的仓库也从登录后的仓库列表进入。安全扫描在团队版、企业版和云服务中提供；社区版没有安全菜单。开始前先让扫描跑起来：系统管理员打开 管理 → 安全设置，页面标题是 AngusSecurity 集成，配置启用 为 已启用、平台可达 为正常；还没开通时点 开通集成。页面要求 angus.git.external-security.enabled=true 时，把环境变量 ANGUS_GIT_EXTERNAL_SECURITY_ENABLED 设为 true 并重启 AngusGit。仓库管理员再到该仓库 设置 → 安全，打开 本仓自动安全扫描 和 许可证合规，保存后提示「安全设置已保存」。对照本文时按仓库里已经保存的设置来看即可，不必再点保存、立即扫描 或 立即执行。

1. 先弄清「不兼容」是怎么判断的

AngusGit 仓库设置里的许可证门禁有三项：不兼容时拒绝 和 无法判定也拒绝 会拦住合并，选 不启用 则不按许可证拦截。

勾上 AngusSecurity 策略里的 许可证合规 之后，允许名单、禁止名单和分发场景才会出现。判断顺序是：

禁止名单：依赖的许可证在禁止名单里，判为不合规。
允许名单：允许名单不为空时，名单以外的许可证都判为不合规。
分发场景：前两项都没有命中时，按软件怎么交付来判断。表单说明是：「GPL 在仅内部使用和 SaaS 下默认不算不兼容，分发二进制或容器镜像时算。AGPL 除了仅内部使用都算不兼容。」

分发场景没填时，按 分发二进制 判断：强互惠（GPL）在这种默认下算不兼容，宽松许可证（例如 MIT）算兼容。无法判定 指扫描没认出许可证；选 无法判定也拒绝 时，这类依赖也会挡住合并。

2. 策略里的名单要先打开许可证合规

AngusGit 投递的扫描默认走 AngusSecurity 策略 [System] GIT Inbound。策略详情编号是 378599664200187905。

详情页上能看到的是：

标题 [System] GIT Inbound，徽章 已启用，说明 Auto-created for GIT inbound scans。
门禁阈值 是高危，说明「出现高危及以上的发现即判定未通过」。
能力集 是 代码安全、密钥检查、依赖/制品漏洞。没有 许可证合规。
右侧概要：默认否，创建时间 2026/08/03 12:02:29。

编辑页里 许可证合规 是一个复选框，说明是「依赖许可证是否合规」。没勾上时，允许名单、禁止名单、分发场景都不显示。这条策略目前没勾 许可证合规；勾上之后才会出现名单和分发场景，表单里的标识只是占位示例，不是这条策略已经保存的内容。

打开策略 在 AngusSecurity 侧栏进入策略。列表说明是「配置检查门禁策略和默认阈值。」打开 [System] GIT Inbound，点 编辑策略。
勾上许可证合规 在 检测能力 里勾上 许可证合规。保存前先确认公司允许把许可证结论写进这条共用策略。
选分发场景 勾上之后才出现 分发场景：仅内部使用、SaaS、分发二进制、分发容器镜像。产品以安装包或容器镜像交付时，选后两项之一。不选则按分发二进制判断。
填名单（按需） 允许名单 和 禁止名单 填 SPDX 标识，逗号分隔。表单占位分别是 MIT, Apache-2.0, BSD-3-Clause 和 AGPL-3.0, SSPL-1.0。同一个许可证不能同时出现在两个名单里。允许名单一旦不为空，名单以外的许可证都判为不合规。
保存保存后对之后的检查生效。已经写在拉取请求上的状态检查不会自动重算。

内置目录没有收录的许可证，可以在策略页的 自定义许可证 页签里添加，标识用 SPDX 标识或 LicenseRef-*。内置目录已经能认出 GPL 时，不必先去这个页签。

3. 在 AngusGit 里打开检查和门禁

仓库自己的开关在 设置 → 安全，地址是 ?tab=settings&section=security。xlliu/e2e-license-gate 现在的表单是：

截图里能看到的开关：

代码安全、密钥检查、许可证合规 开着。依赖/制品漏洞、代码质量 关着。
未通过时拒绝合并 开着。
漏洞门禁阈值 是高危。许可证门禁 是 不兼容时拒绝。

详情页顶上的能力点只点亮了 密钥检查 和 许可证合规，设置页的 代码安全 开关却是开的：两处读的不是同一组字段。打开页面对照即可，不必为了让两处一致而立刻保存。

许可证合规 的说明是「识别依赖许可证，并按门禁决定是否拒绝合并。」如果设了许可证门禁、却没打开这项能力，页面会提示：「许可证门禁已启用，但没有打开「许可证合规」检查。打开拒绝合并后，PR 会因为缺少许可证结论而无法合并。」

只设许可证门禁、不打开 未通过时拒绝合并，结果会记下来，但不会拦住合并。许可证门禁选 不启用 时，策略里的名单只用于展示风险。

4. 这个仓库现在的结果

安全详情在 https://git.anguskit.com/security/repos/xlliu/e2e-license-gate。概览分数 95，严重、高危、中危、低危、信息、密钥、质量都是 0，许可风险 是 1。默认分支显示 main@d3ebc5a。

红字是「门禁建议: 未通过」，下面一行是「许可证门禁未通过，拒绝合并」。已有开放发现时，先看这些发现即可，不必马上点 立即扫描。

许可合规 页签、处置状态开放，共 2 条：

级别	标题	类别	位置
高危	`GPL-3.0-only in e2e-with-gpl`	强互惠	`package.json`，组件 `e2e-with-gpl@1.0.0`
低危	`MIT in e2e-with-gpl`	宽松	`LICENSE`

高危那条的分支是 e2e-git07 @591d671，处置状态开放，说明是 Declared by project manifest。抽屉里可以点 在代码中查看 或 在安全台打开；只是查看结论时，保持处置状态为开放即可。

页面上的许可证类别还有公有领域、弱互惠、网络互惠、专有、未识别、禁止使用。这条 GPL 显示的是 强互惠。

拉取请求上的状态检查认的是该提交最新一次扫描，文案有三种：

许可证没过：「许可证门禁未通过」。
漏洞和许可证都开着并且都过了：「提交 {提交号前 8 位} 的漏洞门禁与许可证门禁均已通过」。这个仓库已合并的 #1、#2 就是这句。
只记了漏洞门禁：「提交 {提交号前 8 位} 的漏洞门禁已通过」。

拉取请求 #4 e2e X-03 GPL merge gate（e2e-x03 → main，已合并）现在是第三种。链接是 https://git.anguskit.com/pulls/xlliu/e2e-license-gate/4。

同一提交 d3ebc5a 上，更早的推送扫描里许可证门禁是失败；后来一次手动扫描把许可证标成跳过，门禁按最新一次记成通过。所以 #4 这行没有写成「许可证门禁未通过」。概览仍写着拒绝合并，是因为开放的 GPL 发现还在，仓库设置里的许可证门禁也还开着。已经合并的检查行不会因为后来改设置而重算。要按新阈值重算，需要对分支重新扫描。

被拦住之后，常见处理是换成许可证合适的依赖。法务确认可以用的，再由管策略的人把它放进允许名单，或改分发场景，然后推送新提交。改名单只影响之后的检查。

5. 最容易配错的地方

你看到的	原因	怎么处理
「许可证门禁已启用，但这次检查没有包含许可证合规」	打开了许可证门禁，但没有打开许可证合规	在设置 → 安全打开许可证合规，再推送一次
几乎所有拉取请求都提示「许可证门禁未通过」	允许名单不为空，但漏写了常用许可证	补全允许名单，或者改用禁止名单
引入了 GPL 依赖却没有被拦	分发场景是仅内部使用或 SaaS。这两种场景下，强互惠默认不算不兼容	按实际交付方式选择分发场景，或者把该 GPL 标识加进禁止名单
策略详情里看不到允许名单	许可证合规没勾上，名单不会出现	编辑策略并勾上许可证合规。勾上之前先确认这条策略是仓库共用的
改了名单，已合并的拉取请求结论没变	新规则只对之后的检查生效，状态检查认最新一次扫描	推送新提交，或对源分支重新扫描
概览写拒绝合并，拉取请求却是成功	开放发现还在，但该提交最新一次扫描把许可证标成了跳过	看扫描历史里同一次提交的推送扫描和手动扫描，不要只看合并请求上的一行

常见问题

许可证门禁和漏洞门禁要分开配吗？

两者分开判断，都在 合并门禁 里，由 未通过时拒绝合并 决定是否拦截。打开拒绝合并之后，漏洞门禁一定会参与，阈值没有「不启用」。这个仓库的漏洞阈值是高危，当前严重到低危的数量都是 0。只想主要管许可证时，把漏洞阈值调到严重。

这和代码溯源有什么区别？

许可证检查看的是依赖声明了什么许可证。代码溯源看的是这段代码和别的仓库像不像。两件事分开做。

每个仓库的名单能不能不一样？

允许名单、禁止名单、分发场景在 AngusSecurity 的策略上。AngusGit 投递的扫描共用 [System] GIT Inbound 时，名单对走这条策略的仓库相同。每个仓库可以各自打开许可证合规、选择 不兼容时拒绝 或 无法判定也拒绝，并决定是否拒绝合并。这个仓库就是自己开了许可证门禁；系统策略的能力集里目前没有许可证合规。

小结

xlliu/e2e-license-gate 的仓库设置已经打开 许可证合规，许可证门禁是 不兼容时拒绝，并且打开了 未通过时拒绝合并。开放发现里的 GPL-3.0-only 是强互惠；分发场景没填时按二进制分发，这种许可证算不兼容。概览因此写着「许可证门禁未通过，拒绝合并」。

策略 [System] GIT Inbound 的能力集目前是代码安全、密钥检查、依赖/制品漏洞，门禁阈值是高危。允许名单和禁止名单要等勾上 许可证合规 才会出现。这条策略目前没勾、也没保存名单。已合并的 #4 状态检查是「提交 d3ebc5ab 的漏洞门禁已通过」，因为它认的是后来那次跳过许可证的扫描。

安全扫描在团队版、企业版和云服务中提供。社区版没有这条门禁。

结论： 仓库设置里同时打开许可证合规、不兼容时拒绝和未通过时拒绝合并，不合规的许可证会记进安全概览并建议拒绝合并。允许名单和分发场景在 AngusSecurity 策略里，要先勾上许可证合规再填写，保存后只对之后的扫描生效。