Git push被拒因远程有本地缺失提交，本质是本地HEAD不在远程引用链上，属非快进保护；需先fetch确认状态，再pull/rebase或--force-with-lease谨慎处理。
git push 被拒：remote contains work you do not have locally
这是 Git 最典型的「引用哈希不一致」报错，本质是本地分支的 HEAD 指向的提交，不在远程分支当前引用链上。Git 拒绝覆盖远程历史，防止误删他人提交。
常见诱因包括：同事刚 push 了新提交；你本地做了 rebase 或 reset；远程分支被强制推送（git push --force）过。
- 别急着
git pull—— 如果本地有未提交修改，pull可能直接触发冲突甚至覆盖你的改动 - 先用
git fetch origin看清远程最新状态，确认origin/main（或对应远程追踪分支）是否已更新 - 再执行
git status -sb，对比本地分支和origin/main的 ahead/behind 数值，明确差异方向
本地已 rebase，但远程分支仍指向旧提交
你本地执行了 git rebase origin/main，但没推送到远程，此时本地分支哈希已变，而远程还停留在旧位置。下次 git push 就会失败。
这不是错误，是 Git 的保护机制 —— 它不允许非快进（non-fast-forward）推送，除非显式允许。
- 若确定 rebase 后逻辑正确，且团队允许线性历史，用
git push --force-with-lease origin main（比--force安全，不会覆盖他人新推送） - 若不确定或协作中需保留原始提交痕迹，改用
git merge origin/main拉取远程变更，生成 merge 提交 - 注意：
git push --force会彻底重写远程历史，他人再git pull会出错，必须同步通知协作者
远程分支名大小写变更后，本地 push 持续失败
git push 报错 “The upstream branch of your current branch does not match the name of the remote branch”，大概率是远程分支改了大小写（比如 feature/s1 → feature/S1），而本地分支仍跟踪旧名。
git branch -r 不可信，它可能缓存旧名或受 core.ignorecase 干扰。
- 用
git ls-remote --heads origin | grep -i s1查远程真实分支名（输出带大写 S 就是大写） - 确认后，删掉旧本地分支：
git branch -d feature/s1 - 新建并跟踪正确大小写的分支：
git checkout -b feature/S1 origin/feature/S1 - 或重命名现有分支：
git branch -m feature/s1 feature/S1，再运行git branch --set-upstream-to=origin/feature/S1
fetch 后 origin/main 更新了，但本地 main 没动
git fetch 只更新远程追踪分支（如 origin/main），不会动你的本地分支（main）。很多人以为 fetch 就等于同步完成，结果 git merge origin/main 或 git rebase origin/main 时才发现本地分支早已落后多步。
这个设计是 Git 安全性的核心：所有变更都分阶段可控，绝不自动修改你的工作区。
- 日常开发中，
git fetch origin应作为每次git push前的固定动作 - 想一步拉取并整合，用
git pull --rebase origin main（推荐）或git pull --ff-only origin main（仅允许快进，避免意外 merge） - 切记：
git pull默认是fetch + merge，会生成 merge 提交；而git pull --rebase是fetch + rebase，保持历史线性
最易被忽略的是：远程分支重命名或大小写变更后，本地不会自动感知，git pull 仍可能成功（因它只看 upstream 配置是否存在），但 git push 必然失败 —— 这种“半同步”状态最容易引发协作混乱。
