git push --all origin 不能用于分钟级备份，因它会推送所有本地分支（含临时分支），浪费带宽、污染仓库，且不校验提交存在性、无法增量传输，易导致空分支创建和hash不一致。
git push --all origin 为什么不能直接用作分钟级备份
它会把所有本地分支一股脑推上去，但你真正关心的可能只有 main、develop 和几个保护分支。推错分支（比如临时调试分支）不仅浪费带宽，还可能污染备份仓库；更关键的是，git push --all 不检查远程是否已有该提交，每次都是全量传输对象，无法利用 Git 的 delta 压缩机制做真正增量。
常见错误现象：git push --all origin 成功返回，但远程 feature/xxx 分支实际没更新——因为本地该分支只是空壳（没 commit 过），--all 仍会创建空远程分支，后续 diff 验证时 hash 对不上。
- 只推送关键分支：用
git push origin main develop显式列出目标分支 - 加
--follow-tags同步关联标签（如 v1.2.3） - 禁用自动创建远程分支：设
git config push.default upstream，避免误推未跟踪分支
bare 仓库接收端必须配置 receive.denyCurrentBranch
如果你用 git init --bare /backup/myapp.git 创建了备份仓库，但没改配置，git push 会直接失败并报错：refusing to update checked out branch: refs/heads/main。这是因为 bare 仓库默认禁止 push 到当前分支（即使它没工作区）。
必须在 bare 仓库内执行：
cd /backup/myapp.git git config receive.denyCurrentBranch ignore
注意：ignore 是最安全选项；updateInstead 虽能自动更新工作区，但 bare 仓库本就不该有工作区，用了反而破坏设计意图。
- 别用
updateInstead—— bare 仓库不该有文件系统视图 - 如果备份目标是 NFS 或百度网盘挂载点，这个配置无效且会导致写入失败（原子性不保证）
- 配置后需验证：
git config --get receive.denyCurrentBranch应输出ignore
如何验证一次“分钟级”备份是否真生效
光看 git push 返回 Everything up-to-date 不代表同步完成——它只说明引用（ref）已更新，不保证对象（blob/tree/commit）已落盘。尤其在弱网络或高延迟异地场景下，Git 可能只传了 ref，对象还在本地 .git/objects 里没发出去。
验证必须分三步跑：
- 查远程分支数：
git ls-remote --heads origin | wc -l，应与本地git branch | wc -l一致 - 比提交 hash：
git rev-parse main（本地）和git ls-remote origin main（远程）输出必须完全相同 - 确认对象存在：
git ls-remote origin | head -n 5看前几行是否有非空 hash，空行或0000000000000000000000000000000000000000表示对象未上传
建议把这三步写进备份脚本末尾，任一失败即 exit 1，触发告警。
分钟级备份的真正瓶颈不在 Git，而在传输协议和路径
用 file:// 协议推送到本地另一块硬盘？快，但不是异地；用 ssh:// 推送到云服务器？稳定，但首次建立连接慢；用 https://？可能被代理或防火墙拦截；而很多人忽略的一点：路径中含中文、空格或符号（如 my-app_v2.1），在 Windows + Git for Windows 组合下，git push 会静默失败或只传部分分支。
实操建议：
- 异地目标一律用
ssh://user@host:/absolute/path/to/repo.git，绝对路径避坑 - 禁用 Windows 风格路径（如
D:\backup\），统一转为/d/backup/（Git Bash 下）或用 WSL - 若走 HTTPS，确保远程服务启用
git-http-backend并配置好 auth，否则 push 会卡在 credential 提示
复杂点在于：分钟级意味着每 60 秒就要触发一次校验+推送+验证闭环，任何环节超时（比如 SSH 连接 >5s）都会导致堆积。真正落地时，得把 timeout 10 git push 和重试逻辑写死在脚本里，而不是依赖 Git 自身重试。
