git fetch是安全同步的第一步，只下载远程更新而不修改本地分支；git pull则是fetch加merge的组合命令，易产生冗余合并提交。
本地分支和远程分支不一致，不是“出问题了”，而是 Git 分布式特性的正常状态。关键在于：先看清差异，再选对同步方式，否则 git push 会失败，git pull 可能引入不必要的合并提交，甚至覆盖他人代码。
git fetch 是同步前必须做的第一步
所有安全同步都始于 git fetch —— 它只下载远程分支的最新提交记录，不碰你本地工作区或当前分支指针。跳过这步直接 git pull 或 git merge，等于蒙眼开车。
-
git fetch origin：拉取所有远程分支更新（推荐日常使用） -
git fetch origin main：只拉取main分支的更新，节省带宽 - 执行后，
origin/main这个“远程追踪分支”就更新了，但你的本地main分支仍不动 - 用
git log --oneline main..origin/main能清楚看到远程多了哪些提交
git pull 和 git fetch + git merge 的区别在哪
git pull origin main 看似方便，其实是 git fetch origin main + git merge origin/main 的组合。问题在于：它强制走 merge 流程，一定会产生一个 merge commit，哪怕只是快进（fast-forward）。
Lovefromio Github
下载
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
- 如果你希望历史干净线性（比如 PR 提交记录要可读），就别依赖
git pull -
git fetch origin main && git merge origin/main更透明，你能分步确认、检查差异、甚至 abort - 当本地有未推送提交时，
git merge origin/main会创建合并提交；而git rebase origin/main则把你的提交“挪到”远程最新提交之后，避免 merge commit
rebase 同步时遇到冲突，怎么不中断流程
变基（git rebase）不是“不能有冲突”，而是冲突发生时 Git 会暂停，并等你处理。关键是别慌，按顺序操作就能继续。
- 冲突文件里会出现
和 <code>>>>>>> commit-id标记，手动编辑保留正确逻辑 - 保存后，用
git add标记为已解决（不是git commit） - 运行
git rebase --continue继续后续提交的变基 - 如果中途想放弃，
git rebase --abort会完全回退到变基前状态，不留痕迹 - 注意：
git rebase改写了本地提交历史，若已推过，后续git push需加--force-with-lease，且确保没人基于你旧提交继续开发
远程分支被删了，本地还留着怎么办
团队协作中，有人删掉远程 feature/login，你的 git branch -a 仍显示 remotes/origin/feature/login，这不是 bug，是 Git 默认不自动清理“过期追踪分支”。
- 用
git remote show origin查看远程真实分支列表，确认哪些已被删除 - 执行
git fetch --prune（或简写git fetch -p），Git 会主动清理本地残留的remotes/origin/xxx - 如果只想清理某一分支，
git branch -d -r origin/feature/login手动删掉对应远程追踪分支 - 这个动作不删本地同名分支（如
feature/login），只删origin/feature/login这个引用
真正容易被忽略的，不是命令本身，而是每次同步前下意识运行一次 git fetch 并用 git diff main origin/main 快速扫一眼差异——这10秒能避开80%的误操作。历史改写、强制推送、合并爆炸，往往都始于一次没看清楚的“直接 pull”。
