误推分支到GitHub工作仓库后手动删除，是否已永久清除避免同事查看？

问题1：删除误推分支后是否完全清除了隐私内容？ #

• 你在GitHub页面删除误推分支的操作，已经阻断了普通用户通过分支列表直接访问这些内容的路径，正常情况下同事在仓库前台是找不到这些分支和关联文件的。
• 但注意这不是「永久彻底删除」：GitHub后台会将悬空的提交对象保留至少90天的回收周期，这段时间内如果有人知道具体的提交哈希值，还是可以直接访问对应内容。如果你的隐私内容敏感度极高，可以联系公司GitHub仓库的管理员，让他们在后台手动触发垃圾回收，提前彻底清除这些悬空对象。
• 目前没有其他人拉取过这些分支的话，基本不会出现内容扩散的情况。

问题2：两个日志相关疑问解答 #

疑问1：为什么只改了少量文件却写入122个对象？ #

Git推送的对象不止包含你修改的文件本身，还包括：

• 你本地这个旧分支所有和远程仓库现有提交不同的历史提交记录、提交元信息（提交人、时间、备注等）
• 这些提交对应的目录树对象、文件 blob 对象，哪怕部分文件已经在其他分支存在，只要当前分支的提交链里有和远程现存提交不一致的对象，都会被推送。
  122个对象是包含了整个旧分支的提交链相关内容，不是你想象的只推了你修改的几个文件，属于正常情况。

疑问2：main分支被拒是不是相关内容没入库？ #

不是。你执行的是git push --all origin，这个命令会尝试推送你本地所有分支到远程：

• 日志里的[new branch] branch name --> branch name已经明确提示你误操作的那个旧分支已经成功推送到远程仓库了
• 只有main分支因为远程的main比你本地的main版本新，需要你先拉取最新代码再推送，所以被拒绝，和你误推的旧分支没有关系，误推的分支内容已经进入了远程仓库。

后续建议操作 #

• 如果你还保留本地的误推分支，可以执行git log查看该分支的所有提交哈希，确认确实没有你意料之外的敏感内容被推送
• 如果你有仓库管理员权限，可以直接在GitHub仓库的「设置」→「危险操作」里触发垃圾回收，或者联系管理员处理，提前清除悬空对象
• 后续推送前建议先执行git push --dry-run预览要推送的分支和内容，确认无误后再执行实际推送操作，避免类似误操作。

内容的提问来源于stack exchange，提问作者addicted2coding