必须先拉最新主干再merge最后push：因本地main落后远程，git拒绝non-fast-forward推送以防覆盖他人提交；漏掉git pull origin main是生产环境合并失败最常见原因。

必须先拉最新主干，再 merge，最后 push —— 三步缺一不可，漏掉 git pull origin main 是生产环境合并失败最常见原因。

为什么 git merge 后 push 失败报 “non-fast-forward”

这不是权限问题，而是你本地 main 分支落后于远程。Git 拒绝覆盖别人已推送的提交。现象是：git status 显示 “Your branch is ahead of 'origin/main' by 1 commit”，但 git push origin main 直接失败。

• 根本原因：合并前没执行 git pull origin main，导致你的本地 main 还停留在旧提交上
• 验证方式：运行 git log --oneline -n 3 origin/main 和 git log --oneline -n 3 main，对比 HEAD 是否一致
• 修复动作：先 git pull origin main，再 git merge feature/login（可能触发新冲突）
• 别用 git push --force 强推 —— 会丢弃他人提交，生产环境严禁

git merge feature/x 与 git merge --squash feature/x 的实际区别

不是“要不要压缩提交”的风格问题，而是影响后续协作的关键设计选择。

Cnb Cool Git

CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。

下载

• git merge feature/x：保留整个分支所有提交历史，生成一个 merge commit。适合长期迭代的功能分支，方便回溯每轮修改
• git merge --squash feature/x：把 feature/x 所有改动暂存为一次变更，不自动提交；必须手动 git commit -m "feat: xxx"。适合一次性修复或小功能，主线历史干净
• 注意：--squash 后 git branch -d feature/x 会报 “branch not fully merged”，这是正常行为，不是错误
• 如果 feature/x 后续还要继续开发，千万别用 --squash，否则再次 merge 会重复应用已 squash 过的改动

合并冲突时，编辑文件的底线规则

冲突标记（、<code>=======、>>>>> feature/x）不是注释，是 Git 的解析锚点 —— 删一半留一半会导致后续操作失败。

• 必须整块删除，包括所有三行标记，只保留你最终决定保留的代码
• 改完后必须 git add <file></file>，否则 git commit 会拒绝（Git 仍认为该文件处于冲突状态）
• 不要用 IDE 的“accept theirs / accept ours”一键解决后就直接 commit —— 先 git status 确认所有冲突文件都已 added，再 commit
• 冲突解决后建议快速验证：跑一遍关键单元测试，或至少 git diff --cached 看下暂存区内容是否符合预期

真正容易被忽略的点是：git pull origin main 不只是“同步代码”，它决定了 merge 的基线版本。生产环境里，哪怕只差一个提交，也可能让本该自动 fast-forward 的合并变成带冲突的三方合并 —— 这个细节，比选 merge 还是 rebase 更影响交付稳定性。