这篇讲安全检查或出问题后，怎么查谁加了成员、谁改了分支保护、谁合并了代码。看完你可以在侧栏 动态 里按活动类型筛出「谁、什么时候、做了什么」；合并方式和代码作者要回到 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 和被拒绝的推送，需要用审批单、反向代理日志和服务器日志另外留存。
Top comments (0)