Git仓库权限变更不产生提交日志，必须独立存档、可追溯、带GPG签名；gitolite.conf提交须-S签名、含结构化Reason/Requested-by/Expires字段；需auditd监控+独立加密归档日志，并触发POST_COMPILE刷新生效。
Git仓库权限变更本身不产生提交日志，所有变更记录必须独立存档、可追溯、带签名，否则无法审计。
gitolite.conf 提交必须带 GPG 签名
Gitolite 的权限配置靠 gitolite.conf 文件驱动，该文件通过 Git 仓库（gitolite-admin）管理。但默认提交不强制签名，容易被伪造或误操作覆盖。
- 必须在管理员本地执行
git config --local commit.gpgsign true，避免全局配置干扰其他项目 - 每次修改
gitolite.conf后，用git commit -S -m "add @backend group to repo/api"提交，-S不可省略 - 服务端应配置 pre-receive hook 拒绝未签名的
gitolite.conf提交（Gitolite v3.6+ 支持REPO_UMASK+ 自定义 hook 组合实现） - 若使用 CI/CD 自动化推送权限变更，需提前导入可信 GPG 密钥到构建环境，并在流水线中显式调用
git commit -S
权限变更必须附带变更说明字段
仅靠 Git 提交信息不足以支撑合规审计，gitolite.conf 本身不支持注释元数据，需在提交体中结构化声明。
- 每条权限变更提交的
body部分必须包含三行固定格式： Reason: access review Q3-2026Requested-by: alice@team.example-
Expires: 2027-02-15（如为临时权限） - 禁止将理由写在
subject行，因 Git 日志截断常见，subject只保留动作摘要（如grant RW+ to @devops on infra/*） - CI 流水线可校验 body 是否含
Reason:行，缺失则拒绝合并到main分支
权限日志不能只依赖 Git 历史
Gitolite 不记录谁在何时执行了 git push，也不记录 SSH 登录 IP、密钥指纹等上下文，纯 Git 日志无法满足 SOC2 或等保三级要求。
- 必须开启系统级审计：Ubuntu 上启用
auditd监控/home/gituser/.gitolite/logs/和/home/gituser/repository/gitolite-admin.git - 关键操作日志需额外落盘：在
gitolite-admin的hooks/post-receive中追加写入/var/log/gitolite-audit.log，内容含时间戳、pusher 公钥 hash、变更 diff 行数 - 禁止将权限变更日志与业务代码日志混存——权限日志须独立加密归档，保留至少 365 天
- 定期导出
git log --grep="Reason:" --pretty="%h %an %ad %s" --no-merges生成权限操作快照，供安全团队抽查
最常被忽略的是：权限变更生效 ≠ 提交合并。Gitolite 在收到 push 后会重载配置，但旧连接仍可能缓存旧规则；必须配合 gitolite trigger POST_COMPILE 强制刷新，否则日志里记了“已授权”，实际却没生效。
