尧图网站建设 
Git push 出现 non-fast-forward通常需要检查本地与目标分支的历史关系。本文用本地裸仓库和两份工作副本复现分叉展示 fetch、检查、merge、push 的处理路径。实验不连接真实团队仓库也不使用强制推送。文章目录1. 先确认是不是这类错误2. 先看工作区、分支和远端3. fetch 之后再判断落后还是分叉4. 本文验证的路径merge 后普通推送5. 出现冲突先解决文件内容6. 修好后的检查清单1. 先确认是不是这类错误! [rejected] main - main (non-fast-forward) error: failed to push some refs第二行只是总括信息。真正应定位的是括号里的原因non-fast-forward 与认证失败、网络连接失败、受保护分支拒绝不是同一种问题。典型场景是你和同事从同一个提交开始工作同事先推送你随后也产生了本地提交。此时两边分叉直接用本地分支替换目标分支可能丢掉远端历史Git 因而拒绝普通推送。GitHub 官方排查说明2. 先看工作区、分支和远端gitstatus-sbgitbranch --show-currentgitremote-v确认自己在正确仓库和分支上。未提交修改先单独处理并备份再做同步不要为了获得“干净状态”直接 reset --hard。下面用 main 和 origin 举例其他项目替换成实际名称。分离 HEAD、远端名不同或目标分支不同不能原样照抄。在 VS Code 按 CtrlShiftG 打开 Source Control。图中左侧 Changes/Staged Changes 用于检查工作区和暂存内容顶部仓库行显示分支和同步提示右侧 Diff 用于检查实际修改。截图中的 main 后面带有修改提示因此不能只看分支名称就认定工作区干净。图源Microsoft / VS Code 官方文档© Microsoft Corporation文档按 CC BY 3.0 US 提供见 仓库许可。原图未修改框线来自原图。3. fetch 之后再判断落后还是分叉gitfetch origingitrev-list --left-right--countHEAD...origin/maingitlog--oneline--graph--decorate--all-n20提交计数的左边是 HEAD 独有提交数右边是 origin/main 独有提交数。这里比较的是 fetch 后的远端跟踪引用不先 fetch就可能依据旧信息作判断。输出形态含义处理方向0 0两边相同检查是否推错目标或有服务器规则N 0本地领先普通推送期间远端仍可能变化0 N本地落后合并更新可检查是否能够快进N M两边均有独有提交按团队规则 merge 或 rebase同步提示有参考价值提交关系才是排查依据。不要把所有“推送失败”都处理成 pull 一次。4. 本文验证的路径merge 后普通推送适用于工作区已处理好、团队允许合并提交、需要保留现有双方历史的场景。可先创建一个尚未使用的本地备份分支名gitbranch backup-before-syncgitmerge origin/maingitpush origin main若备份分支已存在换一个新的名称不要覆盖。merge 可能打开提交信息编辑器也可能因冲突暂停只有合并完成且相关检查通过后再推送。需要线性历史的团队应遵循自己的 rebase 规则不把两种策略混用。本次使用 Git 2.53.0.windows.3两份副本分别修改不同文件推送前计数为1 1普通 push 返回 non-fast-forwardmerge 保留双方历史普通 push 成功后再核对远端跟踪引用计数为0 0并用 merge-base 验证双方原提交都是合并结果的祖先。这个实验验证的是“无内容冲突的分叉合并”不代表所有真实仓库都能自动合并。Git 快进与推送规则见 git push 官方文档。5. 出现冲突先解决文件内容用git status找到冲突文件逐个比较双方意图。去掉冲突标记、检查实际功能再将已确认的文件加入暂存并完成合并gitaddpath/to/resolved-filegitcommit路径是示例占位请替换成实际解决的文件。不能为了让界面变绿直接选择“全部使用 ours/theirs”。本轮实验没有制造内容冲突以上是按 Git 工作流给出的操作指引审核时应在自己的教学副本中验证。若决定取消正在进行的合并可以查看当前状态后使用git merge --abort合并开始前保留工作区变更避免恢复不完整。git merge 官方文档6. 修好后的检查清单工作区状态符合预期双方提交仍在历史中目标分支与远端名称正确项目相关检查通过最后 fetch 并核对差异。推送前别人再次提交时可能需要重复检查这不是前一次修复失效。不要将--force当成日常同步按钮。历史重写需要单独讨论权限、协作与引用状态本文的修复路径不依赖它。 Git push 被 non-fast-forward 拒绝：先查分叉，再合并推送
Git push 出现 non-fast-forward通常需要检查本地与目标分支的历史关系。本文用本地裸仓库和两份工作副本复现分叉展示 fetch、检查、merge、push 的处理路径。实验不连接真实团队仓库也不使用强制推送。文章目录1. 先确认是不是这类错误2. 先看工作区、分支和远端3. fetch 之后再判断落后还是分叉4. 本文验证的路径merge 后普通推送5. 出现冲突先解决文件内容6. 修好后的检查清单1. 先确认是不是这类错误! [rejected] main - main (non-fast-forward) error: failed to push some refs第二行只是总括信息。真正应定位的是括号里的原因non-fast-forward 与认证失败、网络连接失败、受保护分支拒绝不是同一种问题。典型场景是你和同事从同一个提交开始工作同事先推送你随后也产生了本地提交。此时两边分叉直接用本地分支替换目标分支可能丢掉远端历史Git 因而拒绝普通推送。GitHub 官方排查说明2. 先看工作区、分支和远端gitstatus-sbgitbranch --show-currentgitremote-v确认自己在正确仓库和分支上。未提交修改先单独处理并备份再做同步不要为了获得“干净状态”直接 reset --hard。下面用 main 和 origin 举例其他项目替换成实际名称。分离 HEAD、远端名不同或目标分支不同不能原样照抄。在 VS Code 按 CtrlShiftG 打开 Source Control。图中左侧 Changes/Staged Changes 用于检查工作区和暂存内容顶部仓库行显示分支和同步提示右侧 Diff 用于检查实际修改。截图中的 main 后面带有修改提示因此不能只看分支名称就认定工作区干净。图源Microsoft / VS Code 官方文档© Microsoft Corporation文档按 CC BY 3.0 US 提供见 仓库许可。原图未修改框线来自原图。3. fetch 之后再判断落后还是分叉gitfetch origingitrev-list --left-right--countHEAD...origin/maingitlog--oneline--graph--decorate--all-n20提交计数的左边是 HEAD 独有提交数右边是 origin/main 独有提交数。这里比较的是 fetch 后的远端跟踪引用不先 fetch就可能依据旧信息作判断。输出形态含义处理方向0 0两边相同检查是否推错目标或有服务器规则N 0本地领先普通推送期间远端仍可能变化0 N本地落后合并更新可检查是否能够快进N M两边均有独有提交按团队规则 merge 或 rebase同步提示有参考价值提交关系才是排查依据。不要把所有“推送失败”都处理成 pull 一次。4. 本文验证的路径merge 后普通推送适用于工作区已处理好、团队允许合并提交、需要保留现有双方历史的场景。可先创建一个尚未使用的本地备份分支名gitbranch backup-before-syncgitmerge origin/maingitpush origin main若备份分支已存在换一个新的名称不要覆盖。merge 可能打开提交信息编辑器也可能因冲突暂停只有合并完成且相关检查通过后再推送。需要线性历史的团队应遵循自己的 rebase 规则不把两种策略混用。本次使用 Git 2.53.0.windows.3两份副本分别修改不同文件推送前计数为1 1普通 push 返回 non-fast-forwardmerge 保留双方历史普通 push 成功后再核对远端跟踪引用计数为0 0并用 merge-base 验证双方原提交都是合并结果的祖先。这个实验验证的是“无内容冲突的分叉合并”不代表所有真实仓库都能自动合并。Git 快进与推送规则见 git push 官方文档。5. 出现冲突先解决文件内容用git status找到冲突文件逐个比较双方意图。去掉冲突标记、检查实际功能再将已确认的文件加入暂存并完成合并gitaddpath/to/resolved-filegitcommit路径是示例占位请替换成实际解决的文件。不能为了让界面变绿直接选择“全部使用 ours/theirs”。本轮实验没有制造内容冲突以上是按 Git 工作流给出的操作指引审核时应在自己的教学副本中验证。若决定取消正在进行的合并可以查看当前状态后使用git merge --abort合并开始前保留工作区变更避免恢复不完整。git merge 官方文档6. 修好后的检查清单工作区状态符合预期双方提交仍在历史中目标分支与远端名称正确项目相关检查通过最后 fetch 并核对差异。推送前别人再次提交时可能需要重复检查这不是前一次修复失效。不要将--force当成日常同步按钮。历史重写需要单独讨论权限、协作与引用状态本文的修复路径不依赖它。