git fetch 是同步远程分支动态的第一步，不可跳过；它只更新远程跟踪分支（如origin/main），不修改工作区，安全可逆，而 git pull 依赖已有上游配置且仅作用于当前分支。
想看到远程新增的分支、拿到别人刚 push 的提交，但 git pull 没反应？不是 Git 坏了，是你还没执行 git fetch —— 它才是同步远程分支动态的第一步，且不可跳过。
git fetch origin 为什么比 git pull 更值得先跑
远程分支列表（比如 origin/feat/payment）存在本地的 refs/remotes/origin/ 下，Git 不会自动刷新这个缓存。不运行 git fetch origin，你就永远“看不见”新分支，git pull 也只会对当前分支已知的上游起作用。
-
git fetch origin只更新远程跟踪分支指针（如origin/main、origin/dev），不碰工作区、不改本地分支，安全可逆 -
git pull=git fetch+git merge，但它只对当前检出分支生效，且依赖已有追踪关系；没设 upstream 的分支直接报错There is no tracking information - 想查远程到底新加了啥分支？运行
git ls-remote --heads origin（查远程真实状态）或git branch -r（查你本地缓存了哪些origin/*）
如何让本地分支关联上刚 fetch 到的新远程分支
比如 git fetch origin 后，git branch -r 显示出了 origin/feat/api-v2，但本地没有 feat/api-v2 分支——这时不能靠 git pull，得手动建立连接。
GitHub 仓库备份技能 - 将 OpenClaw 工作空间自动或手动备份至 GitHub 私有仓库。支持自动定时备份和手动交互式配置，引导完成 Token 配置、仓库创建、首次备份及定时任务设置。用途：(1) 首次设置 (2) 日常备份。
- 创建并切换到新本地分支，同时设置追踪：
git switch -c feat/api-v2 --track origin/feat/api-v2（推荐，Git 2.23+） - 老版本 Git 用：
git checkout -b feat/api-v2 origin/feat/api-v2 - 验证是否成功：运行
git branch -vv，应看到类似feat/api-v2 abc123 [origin/feat/api-v2] add payment webhook - 此后再进该分支，
git pull就能直接拉了；或者继续用git fetch origin && git merge origin/feat/api-v2，更可控
git fetch --prune origin 清理过期远程引用的必要性
别人删掉了 origin/old-experiment，你的 git branch -r 还显示它，甚至 git checkout old-experiment 会失败——这不是 bug，是本地还存着已失效的远程指针。
- 清理命令：
git fetch --prune origin（等价于git remote prune origin），它会删除所有在远程已不存在的origin/*引用 - 日常建议加到 fetch 流程里：
git fetch --prune origin，避免后续误操作（比如脚本遍历git branch -r结果时出错） - 注意：
--prune不影响本地分支，只清理refs/remotes/origin/下的陈旧记录
为什么别信「一键同步所有本地分支」的脚本
网上所谓 for branch in $(git branch --format="%(refname:short)"); do git checkout $branch && git pull; done 类脚本，在真实协作中极易中断或误操作。
- 遇到未暂存修改的分支，
git checkout直接失败，脚本停在半路，后面分支全没更新 - 某个分支 merge 冲突卡住，后续分支完全跳过，你以为“全同步了”，其实只有前几个动了
- 变量名写错（比如
$brach），可能把mainreset 成origin/dev，数据就丢了 - 真正安全的做法：先
git fetch --prune origin，再逐个确认每个本地分支是否需要reset --hard（丢弃本地未 push 提交）还是merge（保留变更），手动处理
远程分支动态不是“自动广播”来的，git fetch 是唯一可靠的信息入口；而关联、清理、更新这三步，每一步都绕不开人对当前分支状态的判断——自动化省不了这个脑力活。
