企业官网建设流程全解析

1. 推送之前先弄明白：push 到底在改哪几个东西

很多人第一次接触 git 将本地分支推送到远程分支，是从一句git push origin main开始的。命令敲下去，屏幕上滚出几行计数，然后提示branch 'main' set up to track 'origin/main'，事情就结束了。能跑通当然好，但如果你不知道这条命令背后动了哪些引用、更新了哪些文件，那么一旦推送被拒绝、分支名对不上、或者别人告诉你"你的提交把别人的代码覆盖了"，你就会完全失去排查方向。

我见过太多团队里的同事卡在同一类问题上：本地提交一切正常，git log看着也漂亮，偏偏push就是不成功。反复删仓库、重新clone、重新拷代码，最后问题还在。根源不是命令记错了，而是脑子里缺少一张"引用地图"。这篇内容就是把我这些年关于推送的理解、踩过的坑、以及实际操作里最省事的做法一次讲透，从最基础的引用关系讲到被拒绝之后的完整排查链路，无论你是刚装上 Git 的新手，还是天天用但没系统梳理过的人，都能从里面找到能直接用的东西。

1.1 本地分支、远程跟踪分支、远程仓库分支是三个不同的东西

这是理解推送的第一道门槛，也是最容易被含糊过去的地方。我们平时说的"远程分支"，其实是两个完全不同的概念被混在了一起。

• 本地分支：类似main、dev、feature/login，它是你工作目录里真实存在、可以切换、可以提交的引用，本质是一个指向某次提交的指针，存放在.git/refs/heads/下。
• 远程跟踪分支：类似origin/main、origin/dev，它同样存在你本地，也在.git目录里，在refs/remotes/origin/下。它的作用是记录"上一次和远程通信时，远程那个分支指向哪儿"。它是一张快照，不是实时数据。
• 远程仓库上的分支：真正存在服务器上的那个引用，你本地无法直接读改，只能通过网络命令去更新它。

搞清楚这三者的分工，很多"诡异现象"立刻就不诡异了。比如你在网页上看远程仓库已经有人推了新提交，但本地git log origin/main还是旧的——这不是 Git 出错，而是你的远程跟踪分支没有刷新，需要git fetch把它拉下来。再比如有人问"我怎么知道自己和远程差了几个提交"，答案不是去看服务器，而是比较本地分支和远程跟踪分支的差异：

git fetch origin git log --oneline HEAD..origin/main # 远程有、我没有的提交 git log --oneline origin/main..HEAD # 我有、远程没有的提交（即将被推上去的）

第二行命令尤其有用，它列出来的东西就是push真正会发送的内容。养成推送前先跑一遍的习惯，能挡掉相当一部分低级事故。

而push这个动作做的事情可以拆成两半：第一，把本地对象（提交、树、文件内容）打包传给远程；第二，请求远程把某个 ref 从旧值更新为新值。如果这个更新不是"快进"（fast-forward），远程就会拒绝——这就是后面所有被拒报错的共同根源。

1.2 refspec 才是 push 真正的参数

git push后面那一串看着像"分支名"的东西，其实有个正式名字叫refspec（引用规格）。它的完整语法是：

[+]<源引用>:<目标引用>

比如git push origin main:main，冒号左边是你本地的引用，右边是你要在远程创建或更新的引用名。平时我们写的git push origin main只是省略了冒号的简写，Git 会自己补全成"同名推同名"。

理解了这个语法，几个平时觉得很神奇的操作就变得顺理成章：

有一点必须点明：冒号左边为空表示删除，右边为空表示本地分支会被推到远程同名分支。我在实际工作中见过不止一个人写错方向，本意是删除远程分支，结果把本地分支推了上去，虽然结果通常无害，但当时那份惊吓是真的。

还有HEAD这个写法值得多说一句。它是一个符号引用，指向你当前检出的分支。git push origin HEAD会自动解析成"当前分支名"，所以你在任何分支上都能用同一条命令推送当前工作，不用每次去git branch --show-current确认名字。配合冒号语法，git push origin HEAD:refs/heads/main还能实现"不管我在哪个本地分支，都推到远程 main"，这在做发布分支合并时特别顺手。

1.3 为什么第一次推送要 -u，它到底省了什么

-u是--set-upstream的缩写，作用是给本地分支绑定一个上游分支。绑定之后，你在这个分支上直接敲git push、git pull、git fetch、git status，Git 都知道默认该跟谁打交道。

如果没绑定，你会遇到这句非常经典的报错：

fatal: The current branch dev has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin dev

我自己习惯把这件事分成两种态度。对于长期存在的主干分支（main、develop 之类），第一次推送时老老实实加上-u，之后一辈子都不用再写远程名和分支名。对于临时性的功能分支，尤其是几天就删掉的，我反而倾向于每次都写全git push origin feature/xxx，因为临时分支的上游绑定意义不大，反而容易出现"我以为在推 A，其实推到了 B"的错觉。

想查看某个分支的上游关系，用：

git branch -vv

输出里[origin/dev]前面那段就是上游信息，后面还会顺带告诉你"领先几个提交、落后几个提交"，比git status给的信息更紧凑。如果绑错了想改，有三种处理方式：

git branch --unset-upstream # 直接解绑 git branch -u origin/other-branch # 重新绑定到别的上游 git push -u origin other-branch # 边推边改成别的上游

注意：解绑上游不会删除任何提交，也不会影响远程仓库，它只是清掉本地那个"默认跟谁同步"的配置项，纯本地行为，放心操作。

顺便说个容易被忽略的点：上游配置保存在.git/config里，属于本地仓库私有信息，不会被推送到远程，也不会跟着clone走。所以新同事clone下来之后，每个人还是各自-u一次。

2. 从零把本地分支推上去的完整链路

2.1 初始化之后第一件事：确认分支名

不管你是git init新建的仓库，还是clone下来的现有工程，推送之前都应该先确认自己脚下的分支叫什么。看起来很简单，但这一个动作能挡掉一大类"推错分支"的事故。

git branch --show-current # 只输出当前分支名，适合脚本里用 git status -sb # 首行就是分支名和同步状态 git branch -a # 列出所有本地分支和远程跟踪分支

git init之后，默认分支名取决于你的 Git 版本和本地配置。较新版本通常用main，老版本沿用master。这个默认值可以通过配置改掉，建议在装好 Git 之后一次性设定，避免同一个团队里有人main有人master造成分支分裂：

git config --global init.defaultBranch main

我在做代码评审的时候遇到过一次很典型的混乱：甲同学本地默认分支是master，乙同学是main，两人各自push，远程仓库上凭空多出了两个内容几乎一样的分支，后面的合并、保护分支配置、CI 触发条件全乱了，花了半天才收拾干净。统一默认分支名这件事，成本几乎为零，收益却是实打实的。

2.2 关联远程仓库：add remote 与 clone 的两条路

本地仓库和远程仓库建立联系，只有两种途径。

第一种是git clone，一步到位，远程地址、origin名字、远程跟踪分支全部自动配好，你什么都不用管。这是绝大多数日常场景的起点。

第二种是先有本地目录，再手动挂上远程：

git remote add origin <远程仓库地址> git remote -v # 确认地址挂对了，尤其要看清 fetch 和 push 两行

这里有个坑值得单独说：git remote -v的输出是两行——一行 fetch、一行 push。某些团队的远程仓库是不对称的（从 A 地址拉取、往 B 地址推送），这时候一定要确认 push 那一行的地址是你真正想推过去的地方。如果配错了，用下面这两条命令改：

git remote set-url origin <新地址> # 同时改 fetch 和 push git remote set-url --push origin <推送地址> # 只改 push 地址

另一种常见情况是你手上有个从别处拷来的目录，可能带着旧的.git目录和旧的远程配置。这时候git remote -v会暴露出上一个开发者的仓库地址。如果不清掉，你的推送可能直接进到别人的仓库里。处理办法很明确：

git remote remove origin git remote add origin <正确的地址>

我个人的习惯是，接手任何一份来路不明的代码目录时，先看三样东西：git remote -v、git branch -vv、git config --get user.email。这三条命令五秒钟能跑完，但能避免把代码提交到错误的人名下、推到错误的仓库里。

2.3 首次推送与日常推送的命令差异

把链路走一遍，先用表格把命令对照清楚：

这里有两个特别容易误解的地方。

第一，push推的是提交，不是工作区文件。你没commit的改动根本不在推送范围内。所以如果推送后发现"我要改的东西怎么没上去"，第一反应应该是查git status看看有没有未提交内容，而不是怀疑网络。

第二，标签不会跟着分支一起走。打了 tag 之后必须显式推送：

git push origin v1.2.0 # 推单个标签 git push origin --tags # 推所有本地标签 git push --follow-tags # 推分支的同时，把可达的注解标签一起推上去

--follow-tags是我最推荐的一个选项，它只会推"能被当前推送的提交引用到的注解标签"，不会把本地那些临时试验用的轻量标签一起轰上去。如果嫌每次手打麻烦，可以直接写进配置：

git config --global push.followTags true

2.4 推送前我会过一遍的自检清单

这套清单不是仪式感，而是真真切切帮我省过事的流程。每次推送到共享分支（尤其是 main、develop 这种大家共用的）之前，我会花十秒钟跑一遍：

1. git status—— 有没有忘记添加、忘记提交的内容，有没有意外的删除。
2. git log --oneline origin/<分支>..HEAD—— 这次要推上去的到底是哪几个提交，有没有夹带不该出现的文件。
3. git fetch origin && git status -sb—— 看看远程是不是已经往前走了，避免推到一半被拒。
4. git config --get user.name—— 换个环境开发时，确认提交身份没串。

第 2 条尤其重要。有一次我为了调试本地环境临时改了几行配置，提交到了一个功能分支里，自己都忘了。幸好推送前看了下提交列表，发现多了一个不该有的提交，git reset --soft回退后重新整理，才没有把调试痕迹带进主仓库。

3. 本地分支名和远程分支名对不上时怎么办

3.1 冒号语法 src:dst 的正确读法

前面提了 refspec 的语法，这里展开讲怎么用。把它读成"从 src 推到 dst"就够了，左边是本地已有的，右边是远程想要的。方向记不住的话，可以这样想：命令是从左往右执行的，所以左边是先存在的。

git push origin dev:dev # 等价于 git push origin dev git push origin dev:feature/dev # 本地 dev 推到远程 feature/dev git push origin main:release/v1 # 本地 main 推到远程 release/v1

需要注意的是，冒号右边如果是远程不存在的分支，Git 会自动创建。所以你写错了名字，很可能不是报错，而是安静地在远程多建了一个分支。这也是为什么我强烈建议：推送后立刻用git branch -a或网页端确认一下目标分支真的更新了，而不是看到命令返回成功就以为万事大吉。

还有一个细节：如果冒号右边的名字已经存在且是非快进，远程会拒绝；但如果两边名字都写错、正好创建了一个全新分支，那就会静默成功。这种"错误被静默接受"的情况是最难发现的，只能靠主动核对。

3.2 把本地 dev 推到远程 feature/dev

实际工作里这种需求比想象的常见。可能因为远程仓库的分支命名有规范（比如所有功能分支必须放在feature/前缀下），也可能因为你要把本地的临时分支上传给同事review。

最直接的做法：

git push -u origin dev:feature/dev

加上-u之后，本地dev的上游就变成了origin/feature/dev，后续在dev上直接git push就会推到feature/dev。这一点有时候会让人困惑——本地叫 dev，远程叫 feature/dev，上游却是 feature/dev。git status -sb的输出能帮你消除困惑：

## dev...origin/feature/dev [ahead 2]

ahead 2表示本地领先远程 2 个提交，一目了然。

如果你希望本地分支名也规范起来，其实更好的做法是先重命名本地分支再推：

git branch -m feature/dev # 重命名当前分支 git push -u origin feature/dev

但重命名有个前提：如果这个分支已经推过一次并绑定了上游，重命名后上游不会跟着改，需要重新设。我在项目里切换命名规范时就踩过这个，重命名完git push报 no upstream，当时一脸茫然，后来才反应过来是.git/config里的绑定还指着旧名字。

3.3 删除远程分支、推送标签、一次推多个分支

删除远程分支是推送操作里最容易被误操作的一项，因为它复用了同一个命令。两种写法都行：

git push origin --delete feature/dev # 语义清晰，推荐 git push origin :feature/dev # 老写法，效果相同

我个人无条件推荐第一种。理由很简单：冒号写法一旦手滑把冒号位置写偏，可能变成一次莫名其妙的推送。而--delete只要命令正确就一定是在删东西，心理负担小很多。

删除前值得确认两件事：分支是不是已经合并进主线了（git branch --merged能帮你检查本地分支），以及有没有别人的工作还挂在这个分支上。远程分支删掉之后，如果同事本地还留着对应的分支，他下次push会把它重新创建出来——这是很多人不知道的"删了又回来"现象。

一次推多个分支也很简单：

git push origin dev main feature/a # 一次推三个分支 git push --all origin # 推所有本地分支

--all要谨慎使用。如果你的本地有一堆试验性质的临时分支，--all会把它们一股脑推到远程，把仓库弄得非常凌乱。

3.4 用 push.default 和 remote.origin.push 固化习惯

Git 提供了两个配置项来减少重复输入，理解它们能让你的日常命令更简短也更安全。

第一个是push.default，它决定"只写git push时默认推什么"：

git config --global push.default simple # 推荐：只推当前分支，且要求上下游同名 git config --global push.default current # 推当前分支到远程同名分支，不管上游 git config --global push.default upstream # 推当前分支到它的上游 git config --global push.default nothing # 必须显式写好 refspec 才动作

simple是大多数版本的默认值，也是最安全的选择。它的核心约束是"本地名和远程名必须一致"，这就从机制上排除了"我以为在推 main 结果推到别的分支"的可能。nothing看似麻烦，但在对安全性要求高的环境里很有用——它逼着你每次都想清楚推什么。

第二个是remote.origin.push，它可以给某个远程仓库预置一组默认 refspec：

git config remote.origin.push refs/heads/dev:refs/heads/dev

配好之后，在这个仓库里直接git push，就只会推 dev 这一个分支，其余一律不动。这在那种"多分支仓库但只允许推一个分支"的受限环境里特别好用。

提示：修改 push.default 属于全局行为，会影响你机器上的所有仓库。如果只希望某个仓库特殊处理，把--global去掉，在对应仓库目录里执行即可。

4. 推送被拒之后：几类典型报错的排查链路

4.1 non-fast-forward 被拒：原因不止"别人提交了"

报错长这样：

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

字面意思是"你的分支落后于远程对应分支"，但要真正解决它，得先判断是哪种情况造成的落后。我把常见原因分成三类：

第一类，正常的并发协作。同事比你早一步推了提交，你的本地快照过期了，远程已经有了新的提交。这种情况最单纯，按提示同步再推就行。

第二类，历史被改写过。你或者别人在这个分支上做过rebase、commit --amend、reset之类的操作，导致提交历史不再是原来的线性延伸。这时候即使提交内容没冲突，Git 也会认为不是快进。

第三类，分支被换了来源。比如有人把远程分支重置回某个旧提交，或者从别的分支强推过来。这种情况往往最危险，因为稍不注意就会把别人的工作覆盖掉。

判断方法也很直接，先看一眼差异：

git fetch origin git log --oneline HEAD..origin/main # 远程独有的提交 git log --oneline origin/main..HEAD # 本地独有的提交

如果两边都有独有提交，说明是分叉了，需要合并或变基；如果远程独有的提交里有你不认识的内容，那就要去问一下是谁推的，别急着动手。

4.2 --force 与 --force-with-lease 的取舍

解决非快进最粗暴的办法是加--force。但我要说清楚它的代价：--force只检查你本地怎么想，不检查远程现在是什么。如果在你决定强推的这几分钟里，同事刚好推了一个提交上去，你的强推会直接把它抹掉，而且远程的引用历史里看不出任何痕迹。

--force-with-lease就是为这个场景设计的。它在强推之前会先检查"远程分支当前指向的位置，是否和我本地的远程跟踪分支记录一致"。如果一致，说明这段时间没人推过，允许覆盖；如果不一致，说明有人动了，拒绝执行。

git push --force-with-lease origin main

我个人的使用原则是：任何情况下都优先用--force-with-lease，除非有非常明确的理由必须无条件覆盖。这不是谨慎过头，而是历史教训。有人在公共分支上--force过一次，结果另一个同事当天早上的三个提交直接消失了，只能靠reflog一点点找回来。

不过在共享的主干分支上，即使有--force-with-lease也不该强推。公共分支的正确处理方式永远是同步、解决冲突、正常推送，强推留给只属于你自己的功能分支。如果团队用托管平台，干脆把主干分支设为保护分支，从机制上禁止强推，比靠自觉可靠得多。

4.3 本地看不到远程分支：先 fetch 再判断

有一类情况比报错更让人困惑：命令没报任何错，但你发现远程分支上少了自己的提交，或者想推送的目标分支在git branch -a里根本看不到。

原因通常是本地还没有对应的远程跟踪分支。git branch -a列出的远程分支，全部来自本地缓存的快照，没fetch过就不会出现。

git fetch origin # 更新所有远程跟踪分支 git fetch origin feature/dev # 只更新指定分支 git fetch --prune origin # 同时清掉远程已删除的分支快照

--prune这个参数值得单独记住。远程分支被删掉之后，本地的origin/xxx跟踪分支不会自动消失，git branch -a里还会显示出来，容易造成"分支还在"的错觉。加--prune就干净了。嫌每次打麻烦，可以写成配置：

git config --global fetch.prune true

有人在清理后看到一堆"幽灵分支"，以为是仓库出了问题，实际上只是快照没刷新。

4.4 认证失败与权限不足的几种表现

认证相关的报错有很多变体，但基本可以归到下面几类：

排查顺序我一般是这样：先git remote -v确认地址没错，再确认这个地址对应的账号确实有写权限，最后才考虑凭据缓存的问题。很多人一上来就折腾凭据缓存，结果发现根本原因是账号权限被撤了。

提交身份这件事也值得强调。push走的是认证身份，commit记录的是配置身份，两者是独立的两件事。所以你完全可能"用 A 账号推送了带有 B 署名的提交"。推送前用git log -1 --format='%an <%ae>'看一眼当前的署名，是每个新环境配好之后应该做的第一件事。

4.5 大文件、超时、大小写导致的推送异常

还有几种不太常见但很磨人的情况。

推送体积过大导致中断。常见于误提交了编译产物、数据集、安装包。这时候不要只想着加大传输缓冲，正确做法是把这些文件从历史里清出去，或者给仓库配上大文件存储机制。只调缓冲治标不治本，下一次换个文件还是会卡住。

网络不稳导致中途失败。Git 推送本身有一定的重试机制，大仓库遇到连接中断时可以尝试分次推送，比如先推一个较小的分支把公共对象传上去，再推大分支，剩余对象的传输量会明显减少。

文件大小写与换行符差异。跨系统协作时特别容易出问题。同一个文件名只差大小写，在某些系统上被视为两个文件，在另一些系统上被视为同一个。团队里出现"我这儿明明改了，你那儿没变化"的情况，可以先检查：

git config --get core.ignorecase git config --get core.autocrlf

换行符的建议是：跨平台协作的仓库里放一个.gitattributes文件统一声明，别依赖每个人本地配置。因为本地配置是私有的，无法随仓库分发，指望所有人配对是不现实的。

5. 团队协作里，推送这件事的边界感

5.1 推之前先同步：rebase 与 merge 的选择

关于推送被拒之后的处理，最常见的两种做法是合并和变基。

git pull默认行为取决于你的配置和版本，可能是 merge 也可能需要你自己指定。我习惯把拉取和合并拆成两步，这样每一步都在自己掌控之中：

git fetch origin git rebase origin/main # 或 git merge origin/main

两者在推送场景下的区别很实际：

• merge：产生一个合并提交，历史是分叉再汇合的树形结构。优点是操作简单、不改变已有提交、对已经推出去的提交完全安全。
• rebase：把你本地的提交一个个挪到最新基础上，历史是一条直线。优点是清爽，缺点是它改写了提交的哈希值。如果这些提交已经推送到公共分支，rebase 之后再推必然被拒，然后你就得强推，接着别人就遭殃。

所以我的经验规则很清晰：只在自己独占的功能分支上 rebase，共享分支上一律 merge。至于功能分支什么时候适合 rebase，判断标准也很简单——这个分支有没有别人在用。只有你自己在用，随便折腾；只要有第二个人拉过这个分支，就当共享分支处理。

5.2 哪些东西不该被推上去

push只是投递动作，真正决定仓库健康的是你推了什么。下面这几类东西，我几乎每次代码评审都会见到有人误推：

• 本地环境配置：数据库密码、API 密钥、本地路径这类东西。尤其是密钥，一旦推到远程，即使立刻删掉也还留在历史里，得彻底清理历史才算安全。
• 编译产物和依赖目录：体积大、每次构建都会变、合并时冲突频繁，除了撑大仓库没有任何好处。
• 个人编辑器与系统文件：随人员不同而不同，放在仓库里只会互相干扰。
• 临时调试代码：日志打印、写死的测试数据、被注释掉的验证逻辑。

判断标准可以归纳成一句话：这个文件是不是"任何人拿到仓库后都需要且内容一致"的东西。是，就该进仓库；不是，就写进忽略规则。

至于已经推上去的敏感内容，处理方式是删掉文件后再清理历史，让那个提交从历史里消失。这一步操作风险较高，务必先备份、先确认分支上没有别人的未合并工作，操作完立刻通知协作者重新同步。这类操作会让所有人的本地引用对不上，不通知的话，别人下一次推送就会把旧内容重新带回来。

5.3 保护分支与走合并请求时的推送姿势

现在的托管平台基本都有保护分支能力：禁止直接推送、必须走合并请求、必须通过检查、必须有人审核。这套机制最大的价值是它不依赖人的自觉。

在保护分支生效的环境里，正确的推送姿势是：

1. 从主干拉出功能分支：git switch -c feature/xxx
2. 在功能分支上正常提交
3. 推送功能分支：git push -u origin feature/xxx
4. 到平台上发起合并请求
5. 根据评审意见继续在同一个分支上追加提交并推送
6. 合并后删除远程功能分支

第 5 步有个小细节值得注意：追加提交后，合并请求会自动更新，不需要关闭重新开。这也是为什么在功能分支上追加提交比amend更省事——amend改写了哈希，推送时要强推，如果平台记录了旧提交的评审意见，强推之后评审上下文会变得混乱。

工具层面也提一句。图形化客户端能直观展示分支和推送状态，对新手理解分支模型帮助很大；但遇到被拒绝、需要变基、需要清理历史这类场景，命令行给出的信息量大得多，错误提示也更完整。我的建议是两个都会用，理解机制时用命令行，日常查看状态时用图形工具，不要只依赖其中一种。

6. 几个我反复踩过、也反复用到的细节

6.1 分支名大小写与重命名的坑

前面提过大小写问题，这里补一个更隐蔽的场景。有些文件系统天生不区分大小写，所以你把文件名从Readme.md改成README.md，Git 可能认为什么都没变。要强制记录这种改名，需要用临时名字绕一下：

git mv Readme.md readme_tmp.md git mv readme_tmp.md README.md

分支名同理，Feature/xxx和feature/xxx在某些环境下被视为同一个分支，在另一些环境下是两个。所以团队里最好从一开始就约定统一的命名规范，全小写加短横线或斜杠，这是最省事的选择。

另外重命名分支之后，记得两件事：检查上游绑定是否还正确，以及通知已经拉过这个分支的同事改名并重新绑定。远程分支本身不会因为你本地重命名就跟着改名，需要先推新名字、再删旧名字：

git push -u origin new-name git push origin --delete old-name

6.2 别名、快捷键和可视化工具怎么配合

日常推送相关的操作，我配了几个别名，效果比想象中好：

git config --global alias.psh 'push' git config --global alias.pshu 'push -u' git config --global alias.pshf 'push --force-with-lease' git config --global alias.sb 'status -sb'

pshf这个别名我特意配成全称而不是简写，目的就是每次用它时都清楚自己在做危险操作，不会因为手快而误触。

可视化工具的定位也要说清楚。它擅长的是"看"——看分支图、看某次提交改了哪些文件、看文件逐行是谁改的。它不擅长的是"解"——遇到推送被拒、需要变基、需要清理历史，图形界面里能做的选择往往很有限，而且容易让人在不清楚后果的情况下点确认。所以我个人的分工是：提交、查看、比较用图形工具，推送、拉取、变基、改史用命令行。

6.3 推错了之后的挽回操作

最后说一种最不想遇到但确实会发生的情况：推错了东西，或者推错了分支。

如果推错了分支但内容没大问题，先别慌，也别急着删。正确的顺序是：确认新分支上多出来的提交是哪些，确认目标分支有没有受影响，然后决定是删除新分支还是把提交挪过去。

如果推错了内容（比如敏感信息、大文件），处理路径是：先修正当前内容并推送，让最新状态是干净的；再评估是否需要清理历史。清理历史需要重写提交、强推，并通知所有协作者重新同步，切忌单方面操作。

如果只是多推了一个提交，并且这个提交在公共分支上、还没有别人拉过，最稳的做法不是reset加强推，而是补一个反向提交把改动撤销。虽然历史里多了一条记录，但所有人的本地状态都不需要额外处理，这是协作成本最低的方案。

如果必须强推，执行前一定先做两件事：

git fetch origin git log --oneline origin/main..HEAD # 看清自己有什么 git log --oneline HEAD..origin/main # 看清自己会覆盖什么

第二条命令尤其关键，它列的每一个提交都是可能被抹掉的工作。看完再动手，能避免绝大多数的"手一抖，同事的活儿没了"。真出了事也别绝望，本地git reflog在短时间内还能找回引用变化，但能不能找回来取决于有没有人及时操作，越早发现希望越大。

我个人的体会是，关于推送的所有麻烦，九成以上都能用"推之前先 fetch 一次"这一条习惯规避。它只花一两秒，却能让你的本地快照始终新鲜，让所有判断都建立在准确信息之上。剩下的那一成，靠的是"共享分支不强推、功能分支勤同步、推完顺手核一下"这三条底线。