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 会自己补全成同名推同名。理解了这个语法几个平时觉得很神奇的操作就变得顺理成章写法实际含义使用场景git push origin main本地 main 推到远程同名 main日常最常用git push origin dev:feature/dev本地 dev 推到远程 feature/dev本地命名随意远程要规范git push origin :feature/dev冒号左边为空等于删除远程分支清理已合并分支git push origin dev:dev前面加号表示允许非快进更新明确知道要覆盖时才用git push origin HEAD把当前 HEAD 推到远程同名分支不想写具体分支名时方便有一点必须点明冒号左边为空表示删除右边为空表示本地分支会被推到远程同名分支。我在实际工作中见过不止一个人写错方向本意是删除远程分支结果把本地分支推了上去虽然结果通常无害但当时那份惊吓是真的。还有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 statusGit 都知道默认该跟谁打交道。如果没绑定你会遇到这句非常经典的报错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 首次推送与日常推送的命令差异把链路走一遍先用表格把命令对照清楚阶段命令说明建立远程连接git remote add origin 地址clone 的场景可跳过提交本地改动git add -A git commit -m ...push 只能推已提交的内容首次推送并绑定git push -u origin 分支名之后可省略参数日常推送git push依赖上游配置不绑定只推一次git push origin 分支名推送关系不留痕推所有本地分支git push --all origin一次性把全部分支推上去推标签git push origin 标签名标签不随分支自动推送这里有两个特别容易误解的地方。第一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 true2.4 推送前我会过一遍的自检清单这套清单不是仪式感而是真真切切帮我省过事的流程。每次推送到共享分支尤其是 main、develop 这种大家共用的之前我会花十秒钟跑一遍git status—— 有没有忘记添加、忘记提交的内容有没有意外的删除。git log --oneline origin/分支..HEAD—— 这次要推上去的到底是哪几个提交有没有夹带不该出现的文件。git fetch origin git status -sb—— 看看远程是不是已经往前走了避免推到一半被拒。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它可以给某个远程仓库预置一组默认 refspecgit 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 认证失败与权限不足的几种表现认证相关的报错有很多变体但基本可以归到下面几类报错特征常见原因处理方向提示输入用户名密码输了仍失败密码方式不再被支持改用访问令牌或密钥方式Permission denied (publickey)密钥没生成或没添加到托管平台检查本地密钥与平台配置remote: Permission to xxx denied账号对目标仓库没有写权限找仓库管理员加权限推送成功但显示成别人的名字提交身份配置不对检查user.name与user.email反复弹认证窗口凭据没有缓存配置凭据缓存机制排查顺序我一般是这样先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 保护分支与走合并请求时的推送姿势现在的托管平台基本都有保护分支能力禁止直接推送、必须走合并请求、必须通过检查、必须有人审核。这套机制最大的价值是它不依赖人的自觉。在保护分支生效的环境里正确的推送姿势是从主干拉出功能分支git switch -c feature/xxx在功能分支上正常提交推送功能分支git push -u origin feature/xxx到平台上发起合并请求根据评审意见继续在同一个分支上追加提交并推送合并后删除远程功能分支第 5 步有个小细节值得注意追加提交后合并请求会自动更新不需要关闭重新开。这也是为什么在功能分支上追加提交比amend更省事——amend改写了哈希推送时要强推如果平台记录了旧提交的评审意见强推之后评审上下文会变得混乱。工具层面也提一句。图形化客户端能直观展示分支和推送状态对新手理解分支模型帮助很大但遇到被拒绝、需要变基、需要清理历史这类场景命令行给出的信息量大得多错误提示也更完整。我的建议是两个都会用理解机制时用命令行日常查看状态时用图形工具不要只依赖其中一种。6. 几个我反复踩过、也反复用到的细节6.1 分支名大小写与重命名的坑前面提过大小写问题这里补一个更隐蔽的场景。有些文件系统天生不区分大小写所以你把文件名从Readme.md改成README.mdGit 可能认为什么都没变。要强制记录这种改名需要用临时名字绕一下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-name6.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 -sbpshf这个别名我特意配成全称而不是简写目的就是每次用它时都清楚自己在做危险操作不会因为手快而误触。可视化工具的定位也要说清楚。它擅长的是看——看分支图、看某次提交改了哪些文件、看文件逐行是谁改的。它不擅长的是解——遇到推送被拒、需要变基、需要清理历史图形界面里能做的选择往往很有限而且容易让人在不清楚后果的情况下点确认。所以我个人的分工是提交、查看、比较用图形工具推送、拉取、变基、改史用命令行。6.3 推错了之后的挽回操作最后说一种最不想遇到但确实会发生的情况推错了东西或者推错了分支。如果推错了分支但内容没大问题先别慌也别急着删。正确的顺序是确认新分支上多出来的提交是哪些确认目标分支有没有受影响然后决定是删除新分支还是把提交挪过去。如果推错了内容比如敏感信息、大文件处理路径是先修正当前内容并推送让最新状态是干净的再评估是否需要清理历史。清理历史需要重写提交、强推并通知所有协作者重新同步切忌单方面操作。如果只是多推了一个提交并且这个提交在公共分支上、还没有别人拉过最稳的做法不是reset加强推而是补一个反向提交把改动撤销。虽然历史里多了一条记录但所有人的本地状态都不需要额外处理这是协作成本最低的方案。如果必须强推执行前一定先做两件事git fetch origin git log --oneline origin/main..HEAD # 看清自己有什么 git log --oneline HEAD..origin/main # 看清自己会覆盖什么第二条命令尤其关键它列的每一个提交都是可能被抹掉的工作。看完再动手能避免绝大多数的手一抖同事的活儿没了。真出了事也别绝望本地git reflog在短时间内还能找回引用变化但能不能找回来取决于有没有人及时操作越早发现希望越大。我个人的体会是关于推送的所有麻烦九成以上都能用推之前先 fetch 一次这一条习惯规避。它只花一两秒却能让你的本地快照始终新鲜让所有判断都建立在准确信息之上。剩下的那一成靠的是共享分支不强推、功能分支勤同步、推完顺手核一下这三条底线。