git本身不记录“谁删除了远程分支”，因删除操作本质是推送空引用，本地reflog和git log均不保存推送者身份；唯一可信来源是远程仓库服务端审计日志（如github的audit log、gitlab的admin audit events）。
Git 本身不记录“谁删除了远程分支”这一操作，因为删除远程分支本质是向远程仓库推送一个空引用（git push origin :branch-name 或 git push origin --delete branch-name），而 Git 的本地 reflog 和远程仓库日志都不默认保存推送者身份和操作意图。
远程仓库端才有删除记录，本地 Git 查不到操作人
本地 git reflog 只记录你本地仓库的 HEAD 和 ref 变更（比如 checkout、reset、merge），不包含任何远程推送行为；git log --remotes 或 git ls-remote 也只反映当前远程引用状态，无法回溯删除动作。真正能查到“谁删的”，必须登录远程仓库服务（如 GitHub、GitLab、Gitee 或自建 Git 服务器）查看其操作审计日志。
- Github：进入仓库 → Settings → Audit log（需管理员权限），筛选
delete_branch事件 - GitLab：进入 Admin Area → Audit Events，类型选
push或branch_destroy - 自建 Git 服务器（如 Gitea、Gitolite）：需检查服务端日志路径（如
/var/log/gitea/gitea.log），搜索DELETE或push.*:refs/heads/
git ls-remote 能确认分支是否已被删除，但不能说明何时/何人删的
这是最轻量的验证方式，适合快速判断分支现状：
git ls-remote --heads origin | grep 'feature/login'
如果无输出，说明 origin/feature/login 引用已不存在——但它可能是被删了，也可能是压根没推过。注意：git ls-remote 不走本地 fetch 缓存，直接连远程读取当前 refs，结果实时可靠。
- 别用
git branch -r判断：它显示的是你本地origin/xxx的缓存，可能已过期（需先git fetch --prune） - 加
--tags会混入 tag，干扰判断，明确用--heads - 输出格式为
<commit-hash><tab>refs/heads/branch-name</tab></commit-hash>，grep 时建议锚定/branch-name$避免匹配到子分支名
本地 reflog 里可能残留删除前的远程引用快照
如果你或同事在删除前执行过 git fetch，且未启用 gc.pruneExpire 过早清理，那么 origin/branch-name 的旧 commit hash 可能还在 git reflog origin 中：
git reflog show origin --format='%h %gd %gs' | grep 'feature/login'
但这只能告诉你“这个分支曾经指向哪个提交”，不能证明谁删的、也不能确认删除时间点。
-
git reflog origin实际查的是refs/remotes/origin/...的本地 reflog，不是远程仓库日志 - 默认保留 90 天，但频繁
git fetch --prune或git gc会提前清除 - 即使找到 hash，也无法反推操作人——除非你记得当时是谁 fetch 的
真正要追责或复盘，别在本地 Git 命令里死磕；远程服务端的日志才是唯一可信来源。而日常协作中，更值得做的是：用保护分支（protected branches）禁止直接删除，或通过 PR/MR 流程控制分支生命周期——毕竟，查日志永远比防误删慢两拍。
