Git 提交与推送常见报错处理笔记

文章目录

• • 前言
  • [一、提交时被 `ESLint` 拦截](#一、提交时被 ESLint 拦截)
  • • [1.1 报错现象](#1.1 报错现象)
    • [1.2 报错原因](#1.2 报错原因)
    • [1.3 使用场景举例](#1.3 使用场景举例)
    • [1.4 推荐解决方式](#1.4 推荐解决方式)
    • [1.5 临时跳过检查](#1.5 临时跳过检查)
  • [二、推送时报 non-fast-forward](#二、推送时报 non-fast-forward)
  • • [2.1 报错现象](#2.1 报错现象)
    • [2.2 报错原因](#2.2 报错原因)
    • [2.3 使用场景举例](#2.3 使用场景举例)
    • [2.4 推荐解决方式](#2.4 推荐解决方式)
    • [2.5 如果出现冲突](#2.5 如果出现冲突)
    • [2.6 不推荐的方式](#2.6 不推荐的方式)
  • 三、两个问题的区别
  • • [3.1 commit 失败](#3.1 commit 失败)
    • [3.2 push 失败](#3.2 push 失败)
  • 四、常用命令总结
  • • [4.1 正常提交](#4.1 正常提交)
    • [4.2 跳过提交前检查](#4.2 跳过提交前检查)
    • [4.3 推送前同步远程](#4.3 推送前同步远程)
    • [4.4 解决 `rebase` 冲突](#4.4 解决 rebase 冲突)
    • [4.5 放弃 `rebase`](#4.5 放弃 rebase)
  • 总结

前言

在日常开发中，git commit 和 git push 看似简单，但经常会遇到提交失败、推送被拒绝等问题。

本文整理两个常见场景：提交时被 ESLint 拦截，以及推送时出现 non-fast-forward 报错。

一、提交时被 ESLint 拦截

1.1 报错现象

执行提交命令：

git commit -m "邮箱后缀已去除"

出现类似信息：

Running ESLint on web module
eslint --fix [FAILED]
husky - pre-commit script failed

并提示某些文件存在未使用变量：

error Remove this useless assignment to variable "router"
error Remove this useless assignment to variable "docLink"

如图所示：

1.2 报错原因

这不是 Git 本身报错，而是项目配置了提交前检查。

常见流程是：

git commit
  ↓
husky 触发 pre-commit
  ↓
lint-staged 检查暂存文件
  ↓
eslint --fix 检查代码
  ↓
发现错误，阻止提交

也就是说，只要暂存区里的文件存在 ESLint error，提交就会被拦截。

1.3 使用场景举例

例如你修改了用户列表页面，但该文件里原本或本次改动后存在未使用变量：

const router = useRouter()

如果 router 没有被使用，ESLint 就可能报错，导致提交失败。

1.4 推荐解决方式

优先修复 ESLint 报错。

例如删除未使用变量：

// 删除前
const router = useRouter()

// 删除后
// 不再声明 router

然后重新提交：

git add .
git commit -m "邮箱后缀已去除"

1.5 临时跳过检查

如果只是本地临时提交，并且确认代码可以接受，可以跳过 pre-commit：

git commit --no-verify -m "邮箱后缀已去除"

简写：

git commit -n -m "邮箱后缀已去除"

注意：跳过检查不代表问题不存在，后续 CI 或团队检查仍可能失败。

二、推送时报 non-fast-forward

2.1 报错现象

执行：

git push

出现：

! [rejected] current -> current (non-fast-forward)
error: failed to push some refs
hint: Updates were rejected because the tip of your current branch is behind

截图如下：

2.2 报错原因

这个错误表示：远程分支比你本地分支更新。

也就是说，在你提交之前，远程仓库已经有了新的提交。如果你直接推送，可能覆盖远程内容，所以 Git 拒绝了。

可以理解为：

远程分支：A → B → C
本地分支：A → B → D

远程有 C，本地没有；本地有 D，远程没有。此时不能直接 push。

2.3 使用场景举例

常见场景包括：

多人协作时，别人先推送了代码。

你在另一台电脑上推送过代码。

远程仓库有人合并了分支。

本地代码不是基于远程最新版本开发的。

2.4 推荐解决方式

先拉取远程代码，再推送。

推荐使用：

git pull --rebase
git push

--rebase 的作用是：先把远程最新提交拉下来，再把你的本地提交接到最新提交后面。

结果类似：

远程：A → B → C
本地提交：D

rebase 后：A → B → C → D

这样提交历史更清晰。

2.5 如果出现冲突

执行：

git pull --rebase

如果出现冲突，Git 会提示冲突文件。

处理步骤：

git status

查看冲突文件。

手动解决冲突后：

git add 冲突文件
git rebase --continue

最后推送：

git push

2.6 不推荐的方式

不要随便使用强制推送：

git push --force

强制推送可能覆盖远程提交，导致别人代码丢失。

只有在非常确定远程提交可以被覆盖时，才考虑使用。

更安全的强推方式是：

git push --force-with-lease

但多人协作中仍需谨慎。

三、两个问题的区别

3.1 commit 失败

git commit 失败通常发生在本地。

原因可能是：

1. 代码检查失败。

2. 格式校验失败。

3. 测试未通过。

4. 提交信息不符合规范。

本质是：代码还没有成功生成本地提交。

3.2 push 失败

git push 失败发生在本地提交之后。

原因通常是：

1. 远程分支更新了。

2. 本地分支落后远程。

3. 存在提交历史冲突。

本质是：本地提交已有，但不能直接同步到远程。

四、常用命令总结

4.1 正常提交

git add .
git commit -m "提交说明"

4.2 跳过提交前检查

git commit --no-verify -m "提交说明"

4.3 推送前同步远程

git pull --rebase
git push

4.4 解决 rebase 冲突

git status
git add 冲突文件
git rebase --continue
git push

4.5 放弃 rebase

如果 rebase 过程中发现问题，可以取消：

git rebase --abort

总结

git commit 报 ESLint 错误，说明本地提交前检查未通过，优先修复代码问题，必要时可用 --no-verify 临时跳过。

git push 报 non-fast-forward，说明远程分支比本地更新，需要先执行：

git pull --rebase
git push

开发中建议养成习惯：提交前保证代码检查通过，推送前先同步远程分支。这样可以减少冲突，也能避免覆盖他人的代码。