Git 推送失败问题解决指南

当执行 git push -u origin master 遇到类似 [rejected] master -> master (fetch first) 或 failed to push some refs 的错误时，本质是本地分支与远程分支版本不一致（远程有本地没有的更新），Git 为防止覆盖远程变更而拒绝推送。以下是完整的解决方案及细节说明：

一、核心原因分析

远程仓库的 master 分支有新的提交（可能是其他人推送的），而你的本地 master 分支还停留在旧版本，两者存在 “版本差”。此时直接推送会导致远程历史被覆盖，因此 Git 拒绝操作，并提示 “先拉取（fetch）远程更新”。

二、完整解决方案（推荐流程）

1. 拉取远程更新并整合本地提交（推荐 `rebase` 方式）

使用 git pull --rebase 能以线性历史的方式整合远程更新和本地提交，保持提交记录整洁：

# 拉取远程master分支的最新更新，并以rebase方式整合本地提交
git pull --rebase origin master

执行逻辑：
- 先将本地未推送的提交 “暂存” 起来（临时保存）；
- 拉取远程 master 的最新代码，使本地分支与远程同步；
- 再将暂存的本地提交按顺序重新应用到同步后的代码上。
若遇到冲突（rebase 过程中）：
- Git 会提示 Automatic merge failed; fix conflicts and then commit the result.，并标记冲突文件（文件中会出现 <<<<<<< HEAD、=======、>>>>>>> 分支名 标记）；
- 手动编辑冲突文件，解决冲突（保留正确代码，删除冲突标记）；
- 标记冲突已解决：git add <冲突文件路径>（如 git add src/index.js）；
- 继续完成 rebase：git rebase --continue（若想放弃 rebase，执行 git rebase --abort）；
- 重复上述步骤，直到所有冲突解决，rebase 完成。

2. 推送本地分支到远程

整合完成后，本地分支已与远程同步，此时可正常推送：

# 推送本地master到远程，并建立关联（-u仅首次需要，后续直接git push）
git push -u origin master

三、备选方案（标准合并方式，不改写历史）

如果不希望改写提交历史（rebase 会修改历史），可使用 git pull 直接合并（会生成一个 “合并提交”）：

# 拉取远程master并合并到本地（自动创建合并提交）
git pull origin master

若遇到冲突（合并过程中）：
- 同样会提示冲突文件，手动编辑解决冲突；
- 标记冲突已解决：git add <冲突文件路径>；
- 完成合并提交：git commit -m "合并远程master更新，解决冲突"（若 pull 时未自动提交，需手动执行）；
- 推送合并结果：git push origin master（首次推送仍需 -u）。

四、关键注意事项

多人协作必知：推送前先拉取（pull 或 pull --rebase）是基本习惯，可大幅减少冲突。
rebase vs merge：
- rebase：提交历史线性整洁，适合个人开发或团队约定使用，但会改写历史（不要对已推送到远程的提交执行 rebase）。
- merge：保留完整历史（包含合并记录），但历史会有分叉，适合需要明确记录合并过程的场景。
冲突解决原则：
- 解决冲突时需仔细核对代码逻辑，确保合并后功能正常（必要时与相关开发者沟通）。
- 冲突文件中的标记含义：
  - <<<<<<< HEAD：本地当前分支的代码；
  - =======：分隔线；
  - >>>>>>> 分支名：远程分支（或待合并分支）的代码。
首次推送的 -u 参数：-u 是 --set-upstream 的缩写，用于建立本地分支与远程分支的关联，后续推送同一分支可直接用 git push。