git push 被拒绝主因是远程分支有本地缺失的提交，触发非快进保护；需先 git pull（或 --rebase）同步，冲突解决后 add/commit 再 push；--force-with-lease 仅限私有分支且需 fetch 后谨慎使用。
为什么 git push 会直接报 rejected
根本不是权限或网络问题，而是 Git 检测到远程分支的最新提交（比如 a1b2c3d）不在你的本地分支历史中——它拒绝“非快进（non-fast-forward）”更新，防止你无意覆盖他人工作。典型提示里一定带 fetch first 或 non-fast-forward，并附带 hint：“the remote contains work that you do not have locally”。
先确认是不是远程 URL 或权限问题
别一上来就拉取或强制推送，先排除基础链路异常：
- 运行
git remote get-url origin，检查地址是否拼错（比如误写成git@github.con） - HTTPS 方式推送失败？运行
git ls-remote origin，若提示Authentication failed，说明凭据过期，需更新个人访问令牌（PAT）或重置系统凭据管理器 - SSH 方式？执行
ssh -T git@github.com（或对应平台域名），看是否返回 “Hi username! You've successfully authenticated.” - 如果是企业 GitLab/GitHub 私有仓库，还要确认你对目标分支有
push权限——有些项目对main启用了分支保护，只允许通过 PR 合并
同步远程变更的两种可靠路径
90% 的 rejected 场景，用以下任一方式即可解决，关键看团队协作习惯和本地状态：
-
默认推荐：用
git pull origin main—— 它等价于git fetch origin && git merge origin/main。若出现冲突，手动编辑含和 <code>>>>>> origin/main的文件，删掉标记、保留正确内容，再git add+git commit+git push -
想保持线性历史：用
git pull --rebase origin main—— 它把你的本地提交“重放”到远程最新提交之后。冲突时解决后执行git add 文件名，再git rebase --continue。注意：如果本地已有多个未推送 commit 且依赖彼此，--rebase可能导致逻辑错乱，此时别硬上
什么时候能用 git push --force-with-lease
它不是“万能解药”，而是一个带安全阀的覆盖操作：
- 仅适用于你独占的分支（如
feature/login-v2），且确认没人基于你上次推送的 commit 继续开发 - 它比
--force安全：如果别人在你fetch之后又推了新提交，--force-with-lease会中止并报 “stale info”，不会静默覆盖 - 绝对不要在
main、develop等共享主干分支上使用——哪怕你只是想修正一个 typo，也会让队友的git pull失败、CI 流水线中断、本地历史断裂 - 执行前务必再跑一次
git fetch origin，确保本地引用最新
真正容易被忽略的是：很多人在 git pull 出现冲突后，删掉冲突标记却忘了 git add，或者 git commit 时没写 message，结果 git push 依然失败。Git 不会替你做决定，每一步的状态变更都必须显式确认。
